https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #35 from Greg Chandler ---
I have been unable to track this down at all...
I know it's in the driver, but past that all I can find is what is contained in
the messages on this post.
I've attempted to compile older versions of gcc to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #34 from Greg Chandler ---
With this set of debugs in gcc.cc:execute
/* Run each piped subprocess. */
fprintf (stdout, "Run each piped subprocess\n");
fprintf (stdout, "progname: %s\ntemp_filename: %s\n", progname, temp_filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #33 from Greg Chandler ---
for (n_commands = 1, i = 0; argbuf.iterate (i, &arg); i++)
fprintf (stdout, "%d: %s\n", i, argbuf[0]);
With the following inside the following if: if (arg && strcmp (arg, "|") == 0)
fprintf (stdo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #32 from Greg Chandler ---
Starting to get some progress
I added a print statement in gcc.cc to see what is being executed:
-> 3298 /*HERE*/
-> 3299 for (n_commands = 1, i = 0; argbuf.iterate (i, &arg); i++)
-> 3300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #30 from Greg Chandler ---
It's not the preprocessor:
root@bigbang:/tmp# gcc -E 1.c
root@bigbang:/tmp#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #31 from Greg Chandler ---
This hangs:
root@bigbang:/tmp# gcc -S 1.c
>From ps -faux:
root 391 0.0 0.1 4832 3912 ttyS0Ss 03:28 0:00 -bash
root 432 0.4 0.1 6616 2512 ttyS0S+ 03:57 0:00 \_ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #29 from Greg Chandler ---
I tried recompiling the native again with the absolute minimum, with debugging
to help try to track this down:
../configure \
--disable-analyzer \
--disable-bootstrap \
--disable-cet \
--disable-de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #28 from Greg Chandler ---
Everywhere I look at this problem, something doesn't look right, so I took the
drastic step of rebuilding everything. Beause nothing was matching up. Some
things had tls, some didn't, some had ld as gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #27 from Greg Chandler ---
root@bigbang:/tmp# which as
/usr/bin/as
root@bigbang:/tmp# as -v
GNU assembler version 2.44 (alpha-linux-gnu) using BFD version version
2.44-slack151
^C
root@bigbang:/tmp# as 1.s
root@bigbang:/tmp# ls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #26 from Greg Chandler ---
root@bigbang:/tmp# /usr/libexec/gcc/alpha-linux-gnu/14.2.0/cc1 /tmp/1.c
__bswap_16 __bswap_32 __bswap_64 __uint16_identity __uint32_identity
__uint64_identity main
Analyzing compilation unit
Performing int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #25 from Greg Chandler ---
ctrl-d at that read yielded this:
read(0, "", 8192) = 0
close(0)= 0
times({tms_utime=12 /* 0.012 s */, tms_stime=11 /* 0.011 s */, tms_cutime=0,
tms_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #24 from Greg Chandler ---
I took another look at the strack trace, comparing it to the cross-compiler on
the build system.
Build system:
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/include",
{st_mode=S_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #23 from Greg Chandler ---
Well, it was a no-go, so I rebuilt again with --enable-checking=all
root@bigbang:/tmp# cat /tmp/1.c
#include
#include
int main ()
{
}
root@bigbang:/tmp# gcc /tmp/1.c -wrapper gdb
GN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #22 from Greg Chandler ---
Well, I guess the next thing I needed to do was chug my morning cup of cherry
coke to wake up... Since I was too tired to catch it last night, and clearly
not paying attention this morning. The linker err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #21 from Greg Chandler ---
As I typed out that last message, it dawned on me that libssp is the likely
cause of the stack protection stuff... (sigh)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #20 from Greg Chandler ---
After a marathon of table-flipping and much ado, I was able to get all the
dependcies I needed for gdb to work. So that was the good news..
The bad news is that with gdb I am still staring at this process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #19 from Greg Chandler ---
Mostly because I was in the mode of, well let me fix this one thing first, then
one after another for that. It likely would have saved me a ton of time if I
had just removed it in the first place.
I woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #18 from Sam James ---
As I said, I don't see that at all on my alpha crosses. But why not just patch
out that warning for now instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #17 from Greg Chandler ---
So it turns out the libiberty code in gdb is identical to gcc, so the configure
patch was needed there as well, and did not have to be modified.
I did however have to modify 10 more configure scripts to st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #16 from Greg Chandler ---
It's entirely possible I spent days chasing down the wrong thing, but I wanted
to make sure I'm not missing something much farther up stream... I don't think
the configure stuff is a distro patch problem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #15 from Sam James ---
I think that may be barking up the wrong tree. We had issues like that on HPPA
and we ended up removing the warning, but I've also never seen anyone report
that on alpha/hppa before confusing configure tests (t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #14 from Greg Chandler ---
Created attachment 61591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61591&action=edit
This patch is likely to be superceeded by another, but fixes grep for errors
when warnings are transposed to e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #13 from Greg Chandler ---
Created attachment 61590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61590&action=edit
Ignores warnings that are routed to stderr, causing normal checks to fail
This removes any false positives du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #12 from Greg Chandler ---
Well Patching a couple of the configure scripts fixed a long standing issue
of needing to patch code to find the headers and yeilds a clean compile.
However, the resultant native, on the native platfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #11 from Greg Chandler ---
Actually as I pointed out in a prior update, it works fine as a native...
So the cross is the one that complains about the missing main..
I'm still not sure if that is a bug, or something that is supposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #10 from Greg Chandler ---
Ok, I was wrong, it wasn't the defines
/tmp/gcc-14.2.0/gcc.build.lnx/libiberty# cat 1.c
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #9 from Greg Chandler ---
I've done a lot of digging through the config script and am seeing some absurd
behaviour... The first of the "not detected" files is sys/file.h, and the
conftest.c created for that is this:
/tmp/gcc-14.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #8 from Greg Chandler ---
I've been digging deeper on this, and am starting to wonder if there is
something else going on behind the scenes in the build.
For example:
# grep limits.h /tmp/log-alpha
checking for limits.h... no
chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #7 from Greg Chandler ---
Iterestingly the -plugin in the stack trace shouldn't be there
So trying the no-lto example, the trace behaves the same up to that point, then
switches to this:
access("/usr/lib/gcc/alpha-linux-gnu/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #6 from Greg Chandler ---
I need to pour over this a bit too, but here is the stack trace for gcc:
fstat64(3, {st_mode=S_IFREG|0644, st_size=15611, ...}) = 0
mmap(NULL, 15611, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2034000
close(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #5 from Greg Chandler ---
I've also confirmed that this extends to the g++ binary as well and not just
gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #4 from Greg Chandler ---
I'm not sure if the -plugin error was a red-herring, I just tried this:
root@bigbang:/tmp# gcc -fno-lto 1.c
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-06-02
Status|UNCONFIRM
33 matches
Mail list logo
