gcc generates prolog without rsp decrementing, i.e. allocates locals and parameters in free stack without privatising this stack
Hi,
I use gcc:
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,java,ada
--enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp
--disable-libssp --enable-java-awt=gtk --enable-gtk-cairo
--disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
and trying to compile program:
void plus (long * a, long * b)
{
long aa = 10;
long bb =10;
*a += *b + aa + bb;
}
int main (){
long a = 1;
long b = 2;
long *aa = a;
long *bb = b;
plus(aa,bb);
}
##
[EMAIL PROTECTED] gc]$ gcc -S main.c
But code produced for plus function is incorrect:
.file main.c
.text
.globl plus
.type plus, @function
plus:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
## As you can see here it allocates parameters
and autos into stack minus shifts, that is free stack space. I.e. it
didn.t reservation.
movq%rdi, -24(%rbp)
movq%rsi, -32(%rbp)
movq$10, -16(%rbp)
movq$10, -8(%rbp)
movq-24(%rbp), %rax
movq(%rax), %rdx
movq-32(%rbp), %rax
movq(%rax), %rax
addq-16(%rbp), %rax
addq-8(%rbp), %rax
addq%rax, %rdx
movq-24(%rbp), %rax
movq%rdx, (%rax)
leave
ret
.LFE2:
.size plus, .-plus
.globl main
.type main, @function
main:
.LFB3:
pushq %rbp
.LCFI2:
movq%rsp, %rbp
.LCFI3:
# Here it does all correct . firstly reserve
stack frame and then allocates autos and parameters there.
subq$32, %rsp
.LCFI4:
movq$1, -24(%rbp)
movq$2, -32(%rbp)
leaq-24(%rbp), %rax
movq%rax, -16(%rbp)
leaq-32(%rbp), %rax
movq%rax, -8(%rbp)
movq-8(%rbp), %rsi
movq-16(%rbp), %rdi
callplus
leave
ret:
The difference between functions is that main calls other function and
.plus. does not.
In my project I have kernel code that has a function w/o calls
(memcpy) and it is compiled also incorrectly.
And problem is that when *dst = *src executed . pagefault appeared,
this pagefault works on the same stack and rewrites free space, i.e.
rewrites locals of memcpy function.
That results to crash on next read from src.
So probably somebody knows how to solve this problem? I.ve explored
gcc flags and didn.t find anything to solve it.
I.ve also tried another gcc version :
[EMAIL PROTECTED] gc]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
Result is the same.
Thank you in advance,
Denis.
gcc says undefined symbols, nm finds those symbols in the .so
*, int) /mylibpath/libtibhawkamicpp.so:6980 W AmiStatus type_info function /mylibpath/libtibhawkamicpp.so:9818 B AmiStatus type_info node /mylibpath/libtibhawkamicpp.so:8110 V AmiStatus virtual table Any ideas ? Thanks in advance David Denis tel: +33 (0) 147 627 736 mailto: [EMAIL PROTECTED] - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
[Bug bootstrap/55699] New: gmp-5.1.0 no longer supports --host=none-...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55699 Bug #: 55699 Summary: gmp-5.1.0 no longer supports --host=none-... Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@denis-excoffier.org Created attachment 28971 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28971 use gmp-5.1.0-RC2 (and later) embedded in source directory Building gcc-4.7.2 with gmp embedded in source directory no longer does not work with gmp-5.1.0 (gmp-5.0.5 works perfectly), and the following message is produced: the none host is obsolete, use --disable-assembly Presumably, this is for all (recent) GCC versions (and including the 4.8 snapshots) and all platforms, when you embed gmp in your source directory. The attached patch solves this. Hope this helps.
[Bug bootstrap/55699] gmp-5.1.0 no longer supports --host=none-...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55699 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added Attachment #28971|0 |1 is obsolete|| --- Comment #1 from Denis Excoffier g...@denis-excoffier.org 2012-12-15 07:10:12 UTC --- Created attachment 28973 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28973 same patch, under text/plain
[Bug bootstrap/55699] gmp-5.1.0 no longer supports --host=none-...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55699 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Denis Excoffier g...@denis-excoffier.org 2012-12-19 21:09:40 UTC --- In plain gmp-5.1.0 (ftp://gmplib.org/pub/gmp-5.1.0) the ERROR was downgraded into a WARNING, so the patch is no longer necessary. Nevertheless, in my opinion, it should still be applied.
[Bug bootstrap/47016] bootstrap on darwin needs much more disk space than expected to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47016 --- Comment #4 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Dominique d'Humieres from comment #3) Any reason to keep this PR open? From my side, no.
[Bug fortran/56255] New: permissions on http://gcc.gnu.org/gcc-4.8/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56255 Bug #: 56255 Summary: permissions on http://gcc.gnu.org/gcc-4.8/ Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: denis-bz...@t-online.de The top link 4.8 releases on http://gcc.gnu.org/wiki/GFortran#GCC4.8 - http://gcc.gnu.org/gcc-4.8/ but forbidden, You don't have permission to access /gcc-4.8 from firefox 3.6
[Bug bootstrap/56258] New: Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 Bug #: 56258 Summary: Please upgrade doc/*.texi to the latest texinfo package(s) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@denis-excoffier.org Bootstrap fails if the last texinfo (currently 4.13.96) is used (this was also the case with at least 4.13.94 and 4.13.95). It seems that messages like: .../install.texi:3133: warning: @anchor should not appear in @heading or .../gcc.texi:88: warning: @tex should only appear at a line beginning make the building of doc/gcc.info to fail. Prepending - in front of the building rule in gcc/Makefile solves the issue, but gcc.info does not get installed (of course). Plain texinfo-4.13 is OK. I tried with gcc-4.8-20130203 under x86_64-apple-darwin12.2.0 but i suppose this is platform independent. Please upgrade the *.texi files in order to be able to cope with the most recent (even alpha) texinfo releases. This is also applicable to the soon-to-be-released GCC 4.7.3. Also, perhaps texinfo should be listed in install/prerequisites.html. Regards, Denis Excoffier.
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 --- Comment #11 from Denis Excoffier g...@denis-excoffier.org 2013-03-10 08:06:54 UTC --- Please to find someone able to apply the above patches on branches 4.6 and 4.7?
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 --- Comment #16 from Denis Excoffier g...@denis-excoffier.org 2013-03-24 07:06:40 UTC --- Bootstrap of gcc-4.7-20130323 works perfectly. Thanks.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #50 from Denis Excoffier g...@denis-excoffier.org --- gcc-4.9.1-RC-20140710 bootstraps perfectly. Thank you.
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #9 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Richard Henderson from comment #8) Thank you.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #27 from Denis Excoffier g...@denis-excoffier.org --- I (OP) suppose we can WONTFIX that one. Thanks.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #29 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Iain Sandoe from comment #28) Well, there is a fix - which is to update /usr/lib/libgcc_s.dylib to a non-buggy version. I had understood that it was desirable not to replace libgcc_s.dylib. Personally, i use the sed command (shown in comment #17) to create my own libgcc_s.1.dylib, i install it with GCC in /usr/local (or equivalent) and try to always link with it (and usually succeed since i don't use any libraries that are already linked with /usr/lib/libgcc_s.dylib). For security matters, that's like replacing, however. In any case, that bug is not NEW any more.
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #7 from Denis Excoffier g...@denis-excoffier.org --- The bug is no longer present in GCC 4.8.2 (tested today under Cygwin 1.7.27 XP 32bits). Please someone to update the WAITING field into RESOLVED (or WORKSFORME etc.).
[Bug bootstrap/60830] New: ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Bug ID: 60830
Summary: ICE on bootstrapping on cygwin
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@denis-excoffier.org
Installed gcc-4.9.0-RC-20140411 on darwin (Mavericks) with no problem. But:
On Cygwin 1.7.29-2 (+ latests patches), platform=i686-pc-cygwin (Windows XP
SP3, 32 bits), bootstrap stops with:
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
configure: error: in `/tmp/lcl/tmp/gcc/obj/i686-pc-cygwin/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage2-target-libgcc] Error 1
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
Indeed, inside /tmp/lcl/tmp/obj/gcc:
% echo int main() { return 0; } foo.c
% cc1 -quiet -o foo.c foo.c
foo.c:1:1: internal compiler error: Aborted
int main() { return 0; }
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
%
The foo.o seems ok. After some investigation, it seems that cc1 receives an
unexpected SIGABRT signal, after the end of main(), and strace confirms the
kill:
% strace -o /tmp/1 cc1 -quiet -o foo.o foo.c
(same messages as above)
% cat /tmp/1
...
344 4823227 [main] cc1 3768 close: 0 = close(3)
2019 4825246 [main] cc1 3768 set_signal_mask: setmask 0, newmask FFFEFEDK,
mask_bits 0
23 4825269 [main] cc1 3768 kill0: kill (3768, 6)
22 4825291 [main] cc1 3768 sig_send: sendsig 0x784, pid 3768, signal 6,
its_me 1
...
%
On the other hand, if foo.c is erroneous, all seems ok:
% echo it main() { return 0; } foo.c
foo.c:1:1: error: unknown type name 'it'
it main() { return 0; }
^
foo.c:1: confused by earlier errors, bailing out
%
I don't know what to do next.
[Bug bootstrap/60830] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added Target||i686-pc-cygwin Host||i686-pc-cygwin Build||i686-pc-cygwin --- Comment #1 from Denis Excoffier g...@denis-excoffier.org --- Typos: - 1st cc1 command should read cc1 -quiet -o foo.o foo.c instead of cc1 -quiet -o foo.c foo.c - the newmask in strace output is FFFEFEDF and not FFFEFEDK - the cc1 command is missing when foo.c is erroneous: cc1 -quiet -o foo.o foo.c Also, tke kill (, 6) is also present when foo.c is erroneous.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #5 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32591action=edit top level config.log
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #6 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32592 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32592action=edit i686-pc-cygwin/libgcc/config.log
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #7 from Denis Excoffier g...@denis-excoffier.org --- Here are the config.log found at top level and the config.log at i686-pc-cygwin/libgcc level (see attachments). What do you need more specifically? I have to say that i use gmp-6.0.0a, mpfr-3.1.2 (without patches), and mpc-1.0.2, all of them untarred in the source tree. All of them work well for building GCC 4.8.2.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #9 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Jakub Jelinek from comment #8) I guess for start, it would be nice to see backtrace from the debugger about where the segfault and/or abort happened. See attachment 3.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #10 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32595 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32595action=edit gdb session catching signal SIGABRT
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #13 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32600action=edit gdb session stepping until the end
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #14 from Denis Excoffier g...@denis-excoffier.org --- I'm now using plain cygwin-1.7.29-2, the cygwin1.dbg now matches with cygwin1.dll. I've alto tried to recompile without -O2. I'm not so familiar with gdb, i've produced a session where i break at __call_exitprocs (in cygwin1.dll), that shows that the destructors are not called more than once. But i now obtain 2 SEGV. Hope this helps. See attachment 32600.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #19 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32602 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32602action=edit discover __DTOR_LIST__
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #20 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Kai Tietz from comment #12) In general it would be of interest to learn what destructors (by whom) are present in the list called by do_global_dtors (__DTOR_LIST__) I've rebuilt everything, under plain cygwin-1.7.29-2, with BOOT_CFLAGS=-g instead of -g -O2. I carefully didn't rebuilt anything after the failure in i686-pc-cygwin/libgcc like before and cc1 seems to work, BUT xgcc still does not work (with the same symptoms). xgcc --version (or -dumpspecs) shows something on stdout, but when piped into wc, there is no output... Strange. The __DTOR_LIST__ contains a single item: deregister_frame_dtor (see attachment 32602). Also the specs file is not built (is built empty, see in attachment the -dumpspecs parameter), this is probably the cause of the xgcc: error: unrecognized command line option 'X' (with X=--version, or -mtune=generic, or -march=pentiumpro) when the -B/tmp/lcl/tmp/gcc/obj/gcc/ option is used.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #21 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Kai Tietz from comment #17) Just as side-note, I tried to reproduce your reported issue and did a personal build of cygwin's gcc. It worked fine in stage2. I couldn't reproduce the reported ICE on stage2. Which brings me to the question if you are using additional patches/fixes, etc Did you use 32bits? Did you use a recent cygwin version? There has been some movement recently (2014-03-28) in dtors.cc, although i believe that only 64bits is impacted.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #24 from Denis Excoffier g...@denis-excoffier.org --- Well, i suppose it can be RESOLVED_INVALID. Last night i built successfully with 1.7.28-2. I was using some non-standard configuration for gmp and as soon as this kludge was removed, gcc built perfectly (once...). I have to confirm this with a few other builds, latest cygwin version etc. I'll keep you informed. Hence, my fault. However, i am curious to know how Mikael (see comment #2) was able to obtain the exact very same symptoms (to be honest: nearly). Please could you provide details?
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #26 from Denis Excoffier g...@denis-excoffier.org --- After more investigation, it seems that the culprit can be --disable-sjlj-exceptions. Since the beginning (last Sunday), each time i use it on the command line, the build fails and each time i don't use it, the build succeeds. Please would you mind trying again a cygwin build, but with --disable-sjlj-exceptions this time. Especially for those where the build succeeded. For Mikael (see comment #2), it is more than probable that he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody except by me.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #33 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32651 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32651action=edit bootstrap works at least under i686
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #34 from Denis Excoffier g...@denis-excoffier.org --- The patch under attachment 32651 seems to make bootstrapping behave better, at least for i686.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #36 from Denis Excoffier g...@denis-excoffier.org ---
(In reply to Bernd Edlinger from comment #35)
would not using --disable-sjlj-excaptions cause any problems,
maybe a unwanted ABI-Change?
I don't know really. Cygwin people usually build gcc using
--disable-sjlj-exceptions and the /usr/bin/cyggcc_s-1.dll is never very far.
Without --disable-sjlj-exceptions, you get a ${prefix}/bin/cyggcc_s-sjlj-1.dll,
and i believe that cyggcc_s-1.dll and cyggcc_s-sjlj-1.dll are not supposed to
live together very well.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #38 from Denis Excoffier g...@denis-excoffier.org ---
(In reply to Bernd Edlinger from comment #37)
Regarding your patch:
I've tested it and it works (as far as i can tell): the bootstrap has gone
until the end (installation in ${prefix}). objdump -d crtbegin.o contains ba 00
00 00 00 instead of ba f0 ff ff ff, and the .weak... objects at the beginning
of crtbegin.o are gone. More than that, i've built (with this GCC 4.9) several
usual distributions (for the moment: sed, patch, diffutils, bzip2, make, gawk,
xz, many others to come of course).
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #44 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Kai Tietz from comment #42) Second variant of the patch looks ok to me, if bootstrap works for 32-bit and 64-bit cygwin. Post patch to ML for gcc trunk, and if no further issues are present we can merge patch to 4.9.1 I have no access to a 64bit cygwin, but if the patch works there, shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1? After all, the bootstrap (with --disable-sjlj-exceptions) fails and this cannot be worse with the patch. Also there is no impact on other (non-cygwin) configurations.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #45 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Denis Excoffier from comment #44) shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1? No because 4.9.0 is out.
[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 --- Comment #8 from Denis Excoffier g...@denis-excoffier.org 2011-11-28 07:41:38 UTC --- Created attachment 25928 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25928 preprocessed exclude.c
[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added CC||g...@denis-excoffier.org --- Comment #9 from Denis Excoffier g...@denis-excoffier.org 2011-11-28 07:44:12 UTC --- Under last Cygwin (XP 32bits) and with gcc-4.7-2019, i get the same message with exclude.c (from the rsync-3.0.9 distribution), see attachment (preprocessed). However, i cannot reproduce the minimal test case given under Comment 1. % gcc -O2 -o exclude.o -c exclude.c exclude.c: In function 'get_cvs_excludes': exclude.c:943:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2244 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/51366] New: [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 Bug #: 51366 Summary: [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@denis-excoffier.org Created attachment 25960 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25960 preprocessed exclude.c Under last Cygwin (XP 32bits) and with gcc-4.7-2019, i get this message with exclude.c (directly from the rsync-3.0.9 distribution), see attachment (preprocessed). No problem with other platforms (Darwin PPC or Intel, Ubuntu at least). This might have something to do with #51271. However, i cannot reproduce the minimal test case given under the first comment of that bug report. % gcc -O2 -o exclude.o -c exclude.c exclude.c: In function 'get_cvs_excludes': exclude.c:943:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2244 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 --- Comment #12 from Denis Excoffier g...@denis-excoffier.org 2011-11-30 20:03:47 UTC --- I have transfered my bug into #51366. Sorry for the noise.
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #1 from Denis Excoffier g...@denis-excoffier.org 2011-12-01 09:04:00 UTC --- Configure line was: /tmp/lcl/tmp/gcc/gcc-4.7-2019/configure --prefix=/tmp/lcl/uxl/gcc-4.7-2026 --with-local-prefix=/usr/local/here --enable-languages=c,c++ --disable-sjlj-exceptions
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added Version|4.6.0 |4.7.0 --- Comment #17 from Denis Excoffier g...@denis-excoffier.org 2011-12-11 19:45:48 UTC --- Hello, Here comes gcc-4.7.20111203 with (not unexpectedly) exactly the same symptoms (see Description above). I tried the patches provided in Comments #4 and #5 with no success: 11 out of 13 hunks FAILED -- saving rejects to file gcc/dwarf2out.c.rej 1 out of 3 hunks FAILED -- saving rejects to file gcc/config/darwin.c.rej 1 out of 1 hunk FAILED -- saving rejects to file gcc/config/darwin10.h.rej The two patches have been working successfully for all 4.6.x versions. Can we expect an update of them for GCC 4.7? You must know that i also tried the same as before: sed -e 's|^ifeq (/usr/lib,|ifneq (/usr/lib,|g' libgcc/config/t-slibgcc-darwin and of course it works. Regards, Denis Excoffier. P.S. Am i the only one needing this patch? As far as i am concerned, i can live with the above workaround.
[Bug other/39400] Dist tarball missing file gengtype-lex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39400 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added CC||g...@denis-excoffier.org --- Comment #4 from Denis Excoffier g...@denis-excoffier.org 2011-12-16 17:36:59 UTC --- This is the same for gcc-4.7-20111210, with solaris 2.8. However, with gengtype-lex.c at the right location (and --enable-obsolete), everything builds nicely. That only applies to release tarballs, not snapshots. You need the same developer tools for building from snapshots as for building from SVN checkouts. This is a little bit overemphasis in this case. You don't need anything more than for a release tarball. Please consider adding this file in the snapshot distribution. If definitely not possible, please insert the restriction above inside the documentation, eg in http://gcc.gnu.org/snapshots.html, in addition to the rather terse Any given snapshot may [...] even fail to build. Regards, Denis Excoffier.
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #4 from Denis Excoffier g...@denis-excoffier.org 2011-12-17 21:21:55 UTC --- This patch, committed on the 6th of December (r182056), must be included in the snapshot of last Saturday (r182194). I tried with this gcc-4.7-20111210.tar.bz2, and sorry, the result is the same as before.
[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48135 --- Comment #26 from Denis Excoffier g...@denis-excoffier.org 2011-12-19 07:36:33 UTC --- Just for the record: gcc-4.7-20111210 works (with --enable-obsolete of course).
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366
--- Comment #5 from Denis Excoffier g...@denis-excoffier.org 2011-12-19
15:31:46 UTC ---
Reduced test case is:
% cat exclude.c
int version;
int zz1(char *);
static void zz2(int flags)
{
static int initialized = 0;
char xx[4096];
if (initialized)
return;
initialized = 1;
zz2(flags | (version ? 2 : 0));
zz2(flags);
zz1(xx);
}
void zz3()
{
zz2(0);
}
% gcc -v -O -c exclude.c
Using built-in specs.
COLLECT_GCC=/tmp/lcl/uxl/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-201112
10/bin/../libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /tmp/lcl/tmp/gcc/gcc-4.7-20111210/configure
--prefix=/tmp/lcl/u
xl/gcc-4.7-20111210 --with-local-prefix=/usr/local/here
--enable-languages=c,c++
--disable-sjlj-exceptions
Thread model: single
gcc version 4.7.0 20111210 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O' '-c' '-mtune=generic' '-march=pentiumpro'
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../libexec/g
cc/i686-pc-cygwin/4.7.0/cc1.exe -quiet -v -iprefix
/cygdrive/D/Home/dexcoff1/dex
coff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/
-D__CYGWI
N32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/../include/w32
api -idirafter ../../include/w32api exclude.c -quiet -dumpbase exclude.c
-mtune=
generic -march=pentiumpro -auxbase exclude -O -version -o /tmp/ccK5Dvq6.s
GNU C (GCC) version 4.7.0 20111210 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.0 20111210 (experimental), GMP version
5.0
.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gc
c-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/in
clude
ignoring duplicate directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-
4.7-20111210/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.7.0/include
ignoring nonexistent directory /usr/local/here/include
ignoring duplicate directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-
4.7-20111210/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.7.0/include-fixed
ignoring nonexistent directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gc
c-4.7-20111210/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.7.0/../../../../i68
6-pc-cygwin/include
ignoring nonexistent directory ../../include/w32api
#include ... search starts here:
#include ... search starts here:
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/include
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/include-fixed
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/../../include
/usr/include
/usr/lib/../include/w32api
End of search list.
GNU C (GCC) version 4.7.0 20111210 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.0 20111210 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e4de487ff334f86f04bb7cab20aac91a
exclude.c: In function 'zz2':
exclude.c:14:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2244
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
%
[Bug tree-optimization/51865] New: ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51865
Bug #: 51865
Summary: ICE in insert_vi_for_tree, at
tree-ssa-structalias.c:2642
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@denis-excoffier.org
Under MacOSX (x86_64-apple-darwin11.2.0), the new gcc-4.7-20120114 gives ICE
with the following. There was no problem with the preceding snapshots. I've
still not tested under other platforms.
% cat stc.c
// gcc -O -finline-small-functions -finline-functions -fipa-pta
-fpartial-inlining -c stc.c
#include assert.h
void zz0(void);
static int xx0;
void zz0(void) { assert(xx0 == 0); return; };
void zz1(void) { zz0(); return; };
void zz2(void) { zz0(); return; };
%
% gcc -v -O -finline-small-functions -finline-functions -fipa-pta
-fpartial-inlining -c stc.c
Using built-in specs.
COLLECT_GCC=/tmp/lcl/uxl/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.2.0
Configured with: /tmp/lcl/tmp/gcc/gcc-4.7-20120114/configure
--prefix=/tmp/lcl/uxl/gcc-4.7-20120114 --with-local-prefix=/usr/local/here
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.7.0 20120114 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.2' '-O'
'-finline-small-functions' '-finline-functions' '-fipa-pta'
'-fpartial-inlining' '-c' '-v' '-mtune=core2'
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/cc1
-quiet -v -iprefix
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/
-D__DYNAMIC__ stc.c -fPIC -quiet -dumpbase stc.c -mmacosx-version-min=10.7.2
-mtune=core2 -auxbase stc -O -version -finline-small-functions
-finline-functions -fipa-pta -fpartial-inlining -o /tmp/cct66mxd.s
GNU C (GCC) version 4.7.0 20120114 (experimental) (x86_64-apple-darwin11.2.0)
compiled by GNU C version 4.7.0 20120114 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/../../../../x86_64-apple-darwin11.2.0/include
ignoring duplicate directory
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include
ignoring nonexistent directory /usr/local/here/include
ignoring duplicate directory
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include-fixed
ignoring nonexistent directory
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/../../../../x86_64-apple-darwin11.2.0/include
#include ... search starts here:
#include ... search starts here:
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/x86_64-apple-darwin11.2.0/4.7.0/include-fixed
/Users/denis/darlcl/uxl/gcc-4.7-20120114/bin/../lib/gcc/../../include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C (GCC) version 4.7.0 20120114 (experimental) (x86_64-apple-darwin11.2.0)
compiled by GNU C version 4.7.0 20120114 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0bf7ee2f49f6ea7e3844a6dc703323f3
stc.c:7:1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2642
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #6 from Denis Excoffier g...@denis-excoffier.org 2012-01-18 08:45:36 UTC --- This bug was still present under gcc-4.7-20120107 snapshot, but it does no longer show up under gcc-4.7-20120114 snapshot. I suppose it has been corrected. Thank you.
[Bug tree-optimization/51865] [4.7 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2642
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51865 --- Comment #10 from Denis Excoffier g...@denis-excoffier.org 2012-01-22 10:18:47 UTC --- (In reply to comment #9) Fixed. Confirmed, using gcc-4.7-20120121. Thank you.
[Bug bootstrap/50461] New: mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 Bug #: 50461 Summary: mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@denis-excoffier.org Hi, I bootstrap gcc-4.6.1 by installing the gmp/, mpfr/ and mpc/ folders directly in the GCC source tree as suggested in the installation notes. Yesterday, they created a new mpfr-3.1.0-rc1 as a replacement for mpfc-3.0.1 we used to have before. Now, with this new mpfr, the bootstrap fails at the step: Configuring mpc at stage 1. Solution: Compared to mpfr-3.0.1, the new mpfr-3.1.0-rc1 has an additional src folder. Therefore, the ./configure of GCC has to be modified, eg by replacing (sed syntax): s|$$s/mpfr|/src|g (1 occurrence) and s|$$r/$(HOST_SUBDIR)/mpfr|/src|g (2 occurrences) With this modification, everything works fine. I don't think that the MPFR people will remove the src folder in the next future. I suppose this is for all platforms, in any case at least Linux Ubuntu and Darwin Leopard. Regards, Denis Excoffier.
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #1 from Denis Excoffier g...@denis-excoffier.org 2011-09-22 05:22:47 UTC --- Also with mpfr-3.1.0-rc2.
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #2 from Denis Excoffier g...@denis-excoffier.org 2011-10-04 07:07:20 UTC --- Also with mpfr-3.1.0 and also on Cygwin.
[Bug bootstrap/52039] New: gcc/gimplify.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52039 Bug #: 52039 Summary: gcc/gimplify.o differs Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@denis-excoffier.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* On MacOSX (x86_64-apple-darwin11.2.0), with the last snapshot (gcc-4.7-20120128), i obtain gcc/gimplify.o differs and the bootstrap stops. If i include gcc/gimplify.o within compare_exclusions (in configure), the bootstrap succeeds and all seems OK. The snapshot of last week (gcc-4.7-20120121) was OK. See also PR47016.
[Bug bootstrap/52039] gcc/gimplify.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52039 --- Comment #2 from Denis Excoffier g...@denis-excoffier.org 2012-01-30 11:14:54 UTC --- (In reply to comment #1) How did you configure? Dup of PR51974? .../configure --enable-languages=c,c++ --prefix=... --with-local-prefix=... --disable-multilib I don't use --enable-checking. I use the latest XCode (4.2.1), with the lastest mpfr, mpc and gmp within the source directory. Compared to last week i use gmp-5.0.3 instead of gmp-5.0.2. Only gcc/gimplify.o fails. Also i don't think i'm a dup of PR52041.
[Bug bootstrap/52039] gcc/gimplify.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52039 --- Comment #3 from Denis Excoffier g...@denis-excoffier.org 2012-01-30 20:29:45 UTC --- Tried again, using: - gmp-5.0.2, like last week - make with no -j option Same result (ie gcc/gimplify.o differs). Also, Xcpde 4.2.1 uses: % /usr/bin/gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. %
[Bug bootstrap/52039] gcc/gimplify.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52039 --- Comment #4 from Denis Excoffier g...@denis-excoffier.org 2012-01-30 20:54:37 UTC --- Compared with PR52041, i also have a cltq (or cdqe) missing, but it is missing in stage2 and present in stage3. After all, i'm perhaps a duplicate of PR52041.
[Bug bootstrap/52039] gcc/gimplify.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52039 --- Comment #6 from Denis Excoffier g...@denis-excoffier.org 2012-01-30 23:16:52 UTC --- (In reply to comment #5) Please try http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52041#c17 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52041#c18 patches. Comparison successful ie it works.
[Bug bootstrap/63703] [4.9.2 Regression] cc1: internal compiler error: in init_reg_sets, at reginfo.c:178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added CC||g...@denis-excoffier.org --- Comment #4 from Denis Excoffier g...@denis-excoffier.org --- Me too. Invocation command line is: % /tmp/lcl/tmp/gcc/gcc-4.9.2/configure --prefix=/tmp/lcl/uxl/gcc-4.9.2 --disable-multilib --with-local-prefix=/usr/local/nonexistent --enable-languages=c,c++ And compiler is: % gcc --version powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Near the beginning of config.log, something that could be important: --- /usr/bin/hostinfo = Mach kernel version: Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Kernel configured for a single processor only. 1 processor is physically available. 1 processor is logically available. Processor type: ppc7450 (PowerPC 7450) Processor active: 0 Primary memory available: 1.00 gigabytes Default processor set: 53 tasks, 178 threads, 1 processors -- I commented out the gcc_assert at line 178. It then continues a little, until in powerpc-apple-darwin9.8.0/libstdc++-v3 (still stage 1), with an another ICE (Bus error) in guard.cc:114:28. I also confirm that 4.9.1 compiles (and runs) ok.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #32 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Francois-Xavier Coudert from comment #31) WONTFIX sounds reasonable Okay.
[Bug bootstrap/63703] [4.9.2 Regression] cc1: internal compiler error: in init_reg_sets, at reginfo.c:178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #7 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Francois-Xavier Coudert from comment #6) There is no lldb here, and also no direct 'bt' available. I used gdb with a break point: % cd /tmp/lcl/tmp/gcc/obj % % grep -n 'gcc_assert (sizeof reg_names == sizeof initial_reg_names)' ../gcc-4.9.2/gcc/reginfo.c 178: fprintf(stderr, %s:%u %u %u\n, __FILE__, __LINE__, sizeof reg_names, sizeof initial_reg_names); gcc_assert (sizeof reg_names == sizeof initial_reg_names); % % cat test.c /* nothing */ % % /usr/bin/cc --version powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % % ./gcc/cc1 test.c /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 596 468 cc1: internal compiler error: in init_reg_sets, at reginfo.c:178 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. % % /usr/bin/gdb ./gcc/cc1 GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-apple-darwin...Reading symbols for shared libraries .. done (gdb) break reginfo.c:178 Breakpoint 1 at 0xa4df88: file /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c, line 178. (gdb) run test.c Starting program: /Users/denis/darlcl/tmp/gcc/obj/gcc/cc1 test.c Reading symbols for shared libraries +. done Breakpoint 1, init_reg_sets () at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 178 fprintf(stderr, %s:%u %u %u\n, __FILE__, __LINE__, sizeof reg_names, sizeof initial_reg_names); gcc_assert (sizeof reg_names == sizeof initial_reg_names); (gdb) bt #0 init_reg_sets () at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 #1 0x00b5a074 in general_init (argv0=0xb70c /Users/denis/darlcl/tmp/gcc/obj/gcc/cc1) at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/toplev.c:1169 #2 0x00b5bda0 in toplev_main (argc=2, argv=0xb644) at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/toplev.c:1961 #3 0x010265fc in main (argc=2, argv=0xb644) at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/main.c:36 Current language: auto; currently c++ (gdb) cont Continuing. /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 596 468 cc1: internal compiler error: in init_reg_sets, at reginfo.c:178 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program exited with code 04. (gdb) quit % Hope this helps, Denis Excoffier.
[Bug bootstrap/63703] [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #22 from Denis Excoffier g...@denis-excoffier.org --- I'm also happy with the above patch. Thank you.
[Bug c++/82035] New: GCC picks wrong template method instantiation if there are same name classes in independent compilation units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82035 Bug ID: 82035 Summary: GCC picks wrong template method instantiation if there are same name classes in independent compilation units Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: denis at denivip dot ru Target Milestone: --- Created attachment 42086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42086=edit A minimal set for reproducing the bug If we have two independent compilation units (lets say PointsPusher.cpp and WrongPointsPusher.cpp) and both internally use std::vector push_back method with their own definitions of a class (lets say Point which has different size in these definitions) then during the compilation of the second unit push_back method will be taken from the first unit, leading to incorrect memory allocations and vector size management. Here is an example: PointsPusher defines Point as 3 float values, WrongPointsPusher defines Point as 3 double values. If GCC compiled WrongPointsPusher then during PointsPusher compilation std::vector push_back method will be using incorrect size Point. I assume that gcc simply takes previously cached version of the instantiated template method and uses it in another unit despite different template parameter (different class size). GCC should instantiate template methods with classes of current compilation unit event if there are same name classes in other independent units. This bug is especially annoying for big teams where several developers could use same name classes in their compilation units, and that would lead to weird behaviour. Depending on optimization level (-0) there's different amount of memory reallocations, hence slighlty different behaviour (but always erroneous). I've prepared a minimal set of source files with a makefile, so you could easily see the issue. The bug was noticed in: * gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) * gcc version 6.3.0 20170519 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) In gcc 7.1 it seems to be ok.
[Bug c++/29087] New: More than 35000 switch cases crash cc1plus
the exact version of GCC is 4.1.1
the system type is sparc-sun-solaris2.8
the options given when GCC was configured/built:
--prefix=/tmp/local/unixutil/gcc-4.1.1
--with-local-prefix=/usr/local/myCompanyName
(myCompanyName is not the exact wording)
(also, there is a symlink /tmp/local/unixutil/gcc - gcc-4.1.1)
the complete command line that triggers the bug:
gcc -Wall -o foo.o -c foo.cc
the compiler output (error messages, warnings, etc.):
stdout: nothing
stderr:
gcc: Internal error: Segmentation Fault (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
foo.o: not created
the preprocessed file:
see below; for ease of transmission, the full source is not given;
to have it, replace the Z by the missing 65524 values (in
increasing order)
additional remarks:
1) if the file is renamed foo.c (the C language is triggered instead
of C++), the bug does not show up
2) if the command is installed in a Makefile:
---Makefile--
all:
/tmp/local/unixutil/gcc/bin/gcc -Wall -o foo.o -c foo.cc
-
then the bug does not show up if the GNU make is used, however the bug
still shows up if the /usr/ccs/bin/make is used
---foo.ii
# 1 foo.cc
# 1 built-in
# 1 command line
# 1 foo.cc
void myfunction(unsigned short localChar) {
switch (localChar) {
case 0:
case 1:
case 2:
case 3:
case 4:
case 5:
Z
case 65530:
case 65531:
case 65532:
case 65533:
case 65534:
case 65535:
break;
};
return;
};
-
--
Summary: More than 35000 switch cases crash cc1plus
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087
[Bug c/29826] New: __attribute__ dllimport makes optimization crash on cygwin
the exact version of GCC is 4.1.1
the system type is i686-pc-cygwin
the options given when GCC was configured/built:
--prefix=/tmp/local/unixutil/gcc-4.1.1
--with-local-prefix=/usr/local/myCompanyName
(myCompanyName is not the exact wording)
(also, there is a symlink /tmp/local/unixutil/gcc - gcc-4.1.1)
the complete command line that triggers the bug:
/tmp/local/unixutil/gcc/bin/gcc -O -Wall -Wextra -c zim.c
the compiler output (error messages, warnings, etc.):
stdout: nothing
stderr:
zim.c: In function '':
zim.c:16: error: unrecognizable insn:
(insn 20 19 21 2 (set (reg:SI 66)
(const:SI (plus:SI (mem:SI (symbol_ref:SI (#i.) var_decl
0x194500b0 ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
zim.c:16: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
zim.o: not created
the preprocessed file: see below
additional remarks:
1) if -O is removed, all seems OK
2) if __attribute__((dllimport)) is removed, all seems OK
3) if -Wall or -Wextra is removed, no change (still crash)
---zim.i-
# 1 zim.c
# 1 built-in
# 1 command line
# 1 zim.c
struct {
const char *1;
const char *2;
};
extern __attribute__((dllimport)) struct [];
int ();
int () {
int i;
for (i = 0; i 2; i++) {
([i].2);
};
return(0);
};
-
--
Summary: __attribute__ dllimport makes optimization crash on
cygwin
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug c/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #1 from Denis dot Excoffier at airbus dot com 2006-11-14 11:39 --- To be connected to Bug 29825. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug fortran/20026] New: Weird optimization affects cpu200/178.galgel testing
LAPACK tries to determine behavior of present double pre- precision numbers. One of used methods is based on property that (on IA32) 9.0071992547400992E+015 + 1 will be the same 9.0071992547400992E+015, but 9.0071992547400992E+015 + 2 will be differ. This sample demonstrates that any level of optimization in gfortran version 4.0.0 20050215 breaks this functionality. Due to this feature it's impossible now to use 178.galgel test from cpu2000 testsuite. Please compile following sample (I'll attach them also) with and without option -O1. You'll obtain Good without optimization and Bad with -O1. !!*** REAL*8 A, B, C REAL*8 foo A = 9.0071992547400992E+015 B = 1 C = foo( A, B ) IF( C.EQ.A ) THEN write(*,*) Good ELSE write(*,*) Bad!!! write(*,*) A=,A write(*,*) C=,C END IF END !!** FUNCTION foo( A, B ) REAL*8 foo REAL*8 A, B foo = A + B RETURN END !!* gfortran -v Using built-in specs. Target: i586-suse-linux Configured with: ../src/gcc/configure --enable-threads=posix --prefix=/users/x/work/gcc40/real --disable-checking --enable-libgcj --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 4.0.0 20050215 (experimental -- Summary: Weird optimization affects cpu200/178.galgel testing Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot nagorny at intel dot com CC: gcc-bugs at gcc dot gnu dot org,grigory dot zagorodnev at intel dot com GCC build triplet: i586-suse-linux GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20026
[Bug fortran/20026] Weird optimization affects cpu200/178.galgel testing
--- Additional Comments From denis dot nagorny at intel dot com 2005-02-17 13:28 --- Created an attachment (id=8214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8214action=view) sample for error reproducing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20026
[Bug fortran/20945] New: about 2x perfomance regression in comparision with 3.4.2
fortran 4.0 shows perfomance regression (with -O2 option) in comparison with g77 from 3.4.2 on IA32 with attached test. This test is obtained from cpu2000/mgrid test. It consists of calling of two functions: PSINV and RESID. Instrumental control (gprof) shows that most part of time spends in RESID function. There is one strange thing for me. If I remove call of PSINV function test (compiled by g77) became more slowly then it was before (with this call). gfortran from gcc4.0 behave more predictable. It looks like g77 from gcc 3.4.2 does interprocedure optimization for better cache using which can't do gfortran from gcc4.0 You can reproduce my results with attached test. Timing results: With PSINV call g77 sample.f -O2 -static 0m0.693s 0m0.685s 0m0.008s 0m0.694s 0m0.685s 0m0.009s 0m0.690s 0m0.683s 0m0.007s With PSINV call gfortran sample.f -O2 -static 0m1.293s 0m1.279s 0m0.015s 0m1.320s 0m1.306s 0m0.014s 0m1.303s 0m1.294s 0m0.008s Without PSINV call: g77 sample1.f -O2 -static -o z342s time ./z342s 0m0.902s 0m0.893s 0m0.007s 0m0.930s 0m0.923s 0m0.008s 0m0.894s 0m0.889s 0m0.005s Without PSINV call gfortran sample1.f -O2 -static -o z40s time ./z40s 0m0.758s 0m0.752s 0m0.006s 0m0.762s 0m0.758s 0m0.004s 0m0.759s 0m0.757s 0m0.004s cat /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 7 cpu MHz : 2400.858 cache size : 512 KB -- Summary: about 2x perfomance regression in comparision with 3.4.2 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot nagorny at intel dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i586-suse-linux GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From denis dot nagorny at intel dot com 2005-04-11 13:20 --- Created an attachment (id=8591) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8591action=view) Test for results reproducing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From denis dot nagorny at intel dot com 2005-06-22 14:34 --- Ok. It seems like this issue is mostly fixed now. I incresead NIT counter up to 200 and obtained following results: 3.4.2 ~ 3.4s old 4.0 ~ 6.4s mainline ~ 4.0s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug java/27910] New: building fails due essentially to bad /bin/ksh on darwin
In order to build correctly in libjava and libjava/classpath, i had to:
1) in libjava/classpath/lib/Makefile.gcj, replace $(SHELL) by /bin/sh
2) in libjava/classpath/lib/gen-classlist.sh.in, replace the four occurrences
of while read pkg file with an appropriate awk sentence (eg for the first
one: awk '{ pkg=$1; file=$2; printf(%s %s %s/%s\n, pkg, dir, pkg, file); }'
[EMAIL PROTECTED]@ -)
3) in libjava/Makefile.in, replace cat tmp-ilist | while read f; do with for
f in `cat tmp-ilist`; do
It seems that the read built-in in darwin ksh does not read a line, but 4096
bytes.
--
Summary: building fails due essentially to bad /bin/ksh on darwin
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
GCC build triplet: powerpc-apple-darwin8.2.2
GCC host triplet: powerpc-apple-darwin8.2.2
GCC target triplet: powerpc-apple-darwin8.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #2 from Denis dot Excoffier at airbus dot com 2006-06-06 08:33 --- Oops, i've found an unnoticed CONFIG_SHELL=/bin/ksh around the configure step in my build instructions. Sorry for that. Bug is not confirmed any longer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug preprocessor/39883] New: preprocessor fails with myassertion
-fpreprocessed scannerapi.i -quiet -dumpbase scannerapi.c -mcpu=v9 -auxbase-strip scannerapi.o -version -o scannerapi.s GNU C (GCC) version 4.4.0 (sparc64-sun-solaris2.8) compiled by GNU C version 4.4.0, GMP version 4.3, MPFR version 2.4.1. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9ca553a0ebde423c17b189104de35a45 scannerapi.c: In function 'test_scanner_tokens': scannerapi.c:36: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. - stderr (end) -- Summary: preprocessor fails with myassertion Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Denis dot Excoffier at airbus dot com GCC build triplet: sparc64-sun-solaris2.8 GCC host triplet: sparc64-sun-solaris2.8 GCC target triplet: sparc64-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
[Bug c/40378] New: ICE starting with revision 147980
internal compiler error: in generate_subtree_copies, at tree-sra.c:1702 while building linux kernel starting with gcc 4.5.0 revision 147980 -- Summary: ICE starting with revision 147980 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug c/40378] ICE starting with revision 147980
--- Comment #1 from denis dot onischenko at gmail dot com 2009-06-08 11:57 --- Created an attachment (id=17965) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17965action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug c/40378] ICE starting with revision 147980
--- Comment #2 from denis dot onischenko at gmail dot com 2009-06-08 11:58 --- Created an attachment (id=17966) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17966action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug middle-end/41740] New: assembler error when using -O2 option
assembler error occurs when compiling this file with -O2 option. Without -O2 option the file was compiled without error. Revision 152496 does not yet have this error. Revision of 152600 already has this error. -- Summary: assembler error when using -O2 option Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-cross-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41740] assembler error when using -O2 option
--- Comment #1 from denis dot onischenko at gmail dot com 2009-10-18 12:24 --- Created an attachment (id=18817) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18817action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41740] assembler error when using -O2 option
--- Comment #2 from denis dot onischenko at gmail dot com 2009-10-18 12:24 --- Created an attachment (id=18818) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18818action=view) console output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41740] assembler error when using -O2 option
--- Comment #3 from denis dot onischenko at gmail dot com 2009-10-18 12:26 --- Created an attachment (id=18819) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18819action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41740] assembler error when using -O2 option
--- Comment #4 from denis dot onischenko at gmail dot com 2009-10-18 12:30 --- Revision of 152560 has this error too -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41744] New: ICE: fold check: original tree changed by fold
ICE: fold check: original tree changed by fold error while compiling attached file -- Summary: ICE: fold check: original tree changed by fold Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-cross-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41744
[Bug middle-end/41744] ICE: fold check: original tree changed by fold
--- Comment #1 from denis dot onischenko at gmail dot com 2009-10-18 16:51 --- Created an attachment (id=18820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18820action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41744
[Bug middle-end/41744] ICE: fold check: original tree changed by fold
--- Comment #2 from denis dot onischenko at gmail dot com 2009-10-18 16:52 --- Created an attachment (id=18821) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18821action=view) console output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41744
[Bug tree-optimization/41740] [4.5 Regression] ICE in ipcp_analyze_node, at ipa-cp.c:183
--- Comment #9 from denis dot onischenko at gmail dot com 2009-10-23 21:50 --- In revision 153504 this error is no longer reproduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug bootstrap/41818] New: Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile
/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu4) gcc versions I was tried to build are 4.4.1 and 4.5.0 (rev 153504) -- Summary: Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile
--- Comment #1 from denis dot onischenko at gmail dot com 2009-10-24 20:23 --- I run the configure script as follows: ../src/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc64-unknown-linux-gnu --prefix=$(BUILDDIR)/cross-tools --disable-werror --with-sysroot=$(SYSROOT) --enable-languages=c,c++ --disable-multilib --disable-nls -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
[Bug c++/42137] New: error: expected constructor, destructor, or type conversion before �{� token
error: expected constructor, destructor, or type conversion before { token
when compiling attached file from ppl sources with gcc 4.5.0 rev 154407
--
Summary: error: expected constructor, destructor, or type
conversion before { token
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: denis dot onischenko at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c++/42137] error: expected constructor, destructor, or type conversion before �{� token
--- Comment #1 from denis dot onischenko at gmail dot com 2009-11-21 23:45 --- Created an attachment (id=19077) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19077action=view) preprocessed c++ source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c++/42137] error: expected constructor, destructor, or type conversion before �{� token
--- Comment #2 from denis dot onischenko at gmail dot com 2009-11-21 23:45 --- Created an attachment (id=19078) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19078action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c/42504] New: error: bit-field 'anonymous' width not an integer constant
Error occurs when compiling latest linux kernel with 155464 gcc 4.5.0 revision -- Summary: error: bit-field 'anonymous' width not an integer constant Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-cross-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug c/42504] error: bit-field 'anonymous' width not an integer constant
--- Comment #1 from denis dot onischenko at gmail dot com 2009-12-25 14:52 --- Created an attachment (id=19390) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19390action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug c/42504] error: bit-field 'anonymous' width not an integer constant
--- Comment #2 from denis dot onischenko at gmail dot com 2009-12-25 14:52 --- Created an attachment (id=19391) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19391action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile
--- Comment #6 from denis dot onischenko at gmail dot com 2010-01-06 20:19 --- (In reply to comment #5) Created an attachment (id=19486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19486action=view) [edit] patch to add TARGET_LIB_PATH only when bootstrapping Please try this patch. Thanks. I have successfuly compiled cross compiler with this patch. gcc revision is 19. host is x86_64-unknown-linux-gnu, target is powerpc64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
[Bug c/41388] New: -Wlogical-op produces a surprising message
With the following C fragment, compiled with the option -Wlogical-op,
one obtains:
main.c:1006: warning: logical '' with non-zero constant will always evaluate
as true
This message is surprising because a non-zero constant does not
prevent any global '' expression to return either true or false,
depending on the other operands.
Instead, i could have expected the following messages:
main.c: In function 'main':
main.c:1000: warning: logical '' with zero constant will always evaluate as
false
main.c:1009: warning: logical '||' with non-zero constant will always evaluate
as true
This behavior is consistent through at least GCC 4.3.2 and GCC 4.4.1, and also
through Cygwin-1.7, Solaris2.8 and Solaris2.10 (checked 4 configurations).
Also in C++.
Fragment is:
---
#include stdio.h
//
int main(/*unsigned*/ int const argc, char const *const *const argv) {
//
# line 1000
if (0 (argc != 1) (argc != 2) 0) {
fprintf(stderr, argc=%u\n, argc);
};
if (0 || (argc == 1) || (argc == 2) || 0) {
fprintf(stderr, argc=%u\n, argc);
};
if (1 (argc != 1) (argc != 2) 1) {
fprintf(stderr, argc=%u\n, argc);
};
if (1 || (argc == 1) || (argc == 2) || 1) {
fprintf(stderr, argc=%u\n, argc);
};
return(0);
}
-
--
Summary: -Wlogical-op produces a surprising message
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41388
[Bug middle-end/41625] New: no-ending memory allocation
system hang due to no-ending memory allocation when compiling this code -- Summary: no-ending memory allocation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41625
[Bug middle-end/41625] no-ending memory allocation
--- Comment #1 from denis dot onischenko at gmail dot com 2009-10-07 20:25 --- Created an attachment (id=18743) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18743action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41625
[Bug middle-end/41625] no-ending memory allocation
--- Comment #2 from denis dot onischenko at gmail dot com 2009-10-07 20:27 --- Created an attachment (id=18744) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18744action=view) console output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41625
[Bug c++/42929] New: ICE when compiling PPL
The error occurs when compiling PPL with GCC 4.5.0 revision 156383 -- Summary: ICE when compiling PPL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-cross-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
[Bug c++/42929] ICE when compiling PPL
--- Comment #1 from denis dot onischenko at gmail dot com 2010-02-01 20:28 --- Created an attachment (id=19778) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19778action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
[Bug c++/42929] ICE when compiling PPL
--- Comment #2 from denis dot onischenko at gmail dot com 2010-02-01 20:28 --- Created an attachment (id=19779) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19779action=view) console output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
