[Bug c/20299] New: Wrong alignment for __m128 variable size array
When I compile the following program with gcc 3.3.5 (debian unstable):
#include xmmintrin.h
int main()
{
int i=1;
float f;
__m128 m[i];
float f2;
__m128 n[i];
printf (%x %x\n, m, n);
}
I get:
% ./align
a8ec a8dc
which is wrong, since m and n should be aligned on a 16-byte boundary. If I
declare the arrays with a constant size (instead of i), then the alignment is
right. gcc-3.4.4 works fine. The problem is there regardless of the compile
options I use (e.g. -msse -O2).
--
Summary: Wrong alignment for __m128 variable size array
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jean-marc dot valin at usherbrooke dot ca
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20299
[Bug libfortran/20257] Fortran runtime error: End of record occurs when writing large arrays
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03 10:34 --- Partial fix proposed here: http://gcc.gnu.org/ml/fortran/2005-03/msg00023.html This fixes the bug when writing to files, but there still is the case of preconnected units (stdout, stderr). This will need a little more thinking. Reduced test case for preconnected units: real :: array(1) array(:) = 0 write(*,*) array end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug fortran/19362] ICE in fold_convert, at fold-const.c:1998
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03 10:37 --- Hi, I see this patch hasn't been commited yet, could you please send it again to the mailing-lists? With the new approval rules, maybe it should hopefully get reviewed... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19362
[Bug tree-optimization/20122] Wrong code with gcc 4.0 tree-vectorizer
--- Additional Comments From micis at gmx dot de 2005-03-03 10:44 --- I applied you patch and did a full bootstrap on x86_64. No new regressions. It fixes my problem. Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122
Bug.
It should be NULL pointer assignment, but it is not so.
Kernel version 2.4.10 RedHat Linux.
#include stdio.h
#include errno.h
main(){
int err;
err=read(0,NULL,6);
printf(%d %dn,err,errno);
}
Please, reply part of source code with explaination of
bug. Thanks!
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 12:54 --- I think this is very much related to PR 19199. I almost think when that bug is fixed this one will also be fixed. Your current patch will not fix that PR either. -- What|Removed |Added BugsThisDependsOn||19199 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From schwab at suse dot de 2005-03-03 12:56 --- Also happens on i386. -- What|Removed |Added Severity|normal |critical GCC target triplet|ia64-suse-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-03 12:58 --- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs On Mar 3, 2005, at 2:50 AM, Alexandre Oliva wrote: I'm bootstrapping this on x86_64-linux-gnu, along with the patch for PR c++/20103; it's also passed C++ regression testing. Ok to install if bootstrap and all-languages regression testing passes? I think this is the wrong approach, we should be doing the same for all types (well except for bitfields) and not just addressable types, see PR 19199 for a testcase where we get this wrong and there is a proposed way of fixing this from RTH. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug target/20299] Wrong alignment for __m128 variable size array
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20299
[Bug target/20299] Wrong alignment for __m128 variable size array
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 13:06 --- Fixed in 3.4.0 and above as you noted that it is fixed in 3.4.4. This is not a regression so closing as fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Known to fail||3.2.3 3.3.5 Known to work||3.4.0 4.0.0 4.1.0 Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20299
[Bug libfortran/20257] Fortran runtime error: End of record occurs when writing large arrays
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03 13:08 --- Complete patch is here: http://gcc.gnu.org/ml/fortran/2005-03/msg00024.html Note: this just makes the limit higher (1 Gb), but there still is a limit on the size of things you can write to preconnected units. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From bob dot paddock at gmail dot com 2005-03-03 13:13 --- (In reply to comment #5) Personally see no problem. The quote above has specifically to do with how to write a logical 16-bit timer/counter value into a pair of otherwise distinct 8-bit registers, which controls a specific peripheral function which presumes a specific write sequence to maintainthe logical integrety of that specific timer/counter value; it has nothing to with 16-bit pointers, the sequencing of multi-byte logical data type transactions, or the compiler in general. It is specific to the pointer case because the correct order of operations is generated in all other cases. Due to the limited Flash space of the AVR it is common to have structures of pointers pointing to the hardware registers, so that the same code will work with both Output Compare One, and Output Compare Three for example. The Input Capture and Output Compare registers are truly 16-bits in length, they are not distinct 8-bit registers. They are accessed 8-bits at a time. To access the 16-bit registers 8-bits at a time without use of the hardware latching mechanism would require that interrupts be disabled. In many embedded applications this is unacceptable, hence the hardware is provided to deal with this problem. By not disabling interrupts and not using the hardware latching mechanism the embedded device, be it a Cruse Control or Phase Control System, is going to have outputs that are off by a factor of 256 at apparently random times. If the complier can not be made to generate correct code for this case then the compile should fail. Consider that if the the order of 16-bit operations I/O was wrong in all cases then the GCC would not be usable on the AVR. Asynchronous Hardware/Firmware by Jack Ganssle at http://www.ganssle.com/articles/asynchf.htm goes into the gory details of why this type of failure in a embedded device is down right dangerous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug ada/20300] New: ICE on undefined value of type derived from Character
The following program results in an ICE: procedure Undefined_Derived_Char is type Char is new Character; C : Char; begin case C is when XXX = null; when others = null; end case; end Undefined_Derived_Char; It seems that the checks in Sem_Ch8.Find_Direct_Name.Undefined should take into account that Case_Typ can be a type derived from one of the character types: if Is_Enumeration_Type (Case_Typ) and then Case_Typ /= Standard_Character and then Case_Typ /= Standard_Wide_Character and then Case_Typ /= Standard_Wide_Wide_Character then Maybe Is_Enumeration_Type (Case_Typ) and not Is_Character_Type (Case_Typ) is the correct test? -- Summary: ICE on undefined value of type derived from Character Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fw at deneb dot enyo dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20300
[Bug c++/20295] zero length array accepted
--- Additional Comments From bangerth at dealii dot org 2005-03-03 14:39 --- I think gcc is right, and icc rejects the code with an almost exact same error message. W. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20295
[Bug c++/20295] zero length array accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 14:45 --- (In reply to comment #3) I think gcc is right, and icc rejects the code with an almost exact same error message. But we don't still don't reject the zero sized array which is a bug. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20295
[Bug c++/20295] zero length array accepted
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-03-03 00:26:59 |2005-03-03 14:45:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20295
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From olh at suse dot de 2005-03-03 14:48 --- the breakage appeared between 20041027 and 20041101. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches
--- Additional Comments From joern dot rennecke at st dot com 2005-03-03 14:59 --- Subject: Re: If-conversion can't match equivalent code, and cross-jumping only works for literal matches pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 02:44 --- (In reply to comment #4) The recog.c / recog.h part of the patch has been committed as part of another patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00133.html Yes this also caused a regression on ppc-darwin (it might also be reproducable with ppc-elf and ppc- linux). I've tried ppc-eabisim, but can't reproduce a failure there building gcc or newlib. powerpc-apple-darwin7.4.0 wants lots of include files which I don't have. Could you send me a preprocessed file so that I can test my patch against that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
[Bug c++/20234] ambiguity with friend name injection and using directive
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-03 16:27:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20234
[Bug c++/20234] ambiguity with friend name injection and using directive
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-03 16:28 --- I think NS::C should remain hidden so the declaration: C c; should be OK. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-03 16:27:29 |2005-03-03 16:28:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20234
[Bug c++/20295] zero length array accepted
--- Additional Comments From bangerth at dealii dot org 2005-03-03 17:00 --- That's correct, but that's a dup of PR 16859. W. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20295
[Bug c++/16859] Empty initializer for array of unknown size spuriously accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 17:06 --- I knew I should have looked for this bug. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16859
[Bug target/20301] New: Assembler labels have a leading -
I am compiling a large jar file. /opt/gcc-3.4.3-cvs/bin/gcj -c ../../kernel/kernel.jar --classpath=..:../kernel -o kernel.o /var/tmp//cct7Jptt.s: Assembler messages: /var/tmp//cct7Jptt.s:103992: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:143015: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:169767: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:169775: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:179941: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:208865: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:225045: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:230975: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:231045: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:232434: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:232840: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:234117: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:235266: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:239572: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:240134: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:24: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:243455: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:243858: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:246766: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:264795: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:272843: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:274270: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:276426: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:277635: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:278726: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:279508: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:296087: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:296150: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:296234: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:306372: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:406839: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:436738: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:530831: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:568280: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:582599: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:594217: Error: unknown pseudo-op: `.ll' /var/tmp//cct7Jptt.s:652229: Error: unknown pseudo-op: `.ll' make[2]: *** [kernel.o] Error 1 make[1]: *** [kernel.o] Error 2 make: *** [_SunOS_5.8_sparc] Error 2 The resulting *.s file has labels that contain - which causes as to fail. If I hand remove the - from the .s file it compiles. Here is a snipet of the resulting *.s code with the problem .LLEHE635: restore jmp %o7+8 nop .align 4 .align 4 .LL-1347440721: .word .LL7725 .word .LL7697 .word .LL7726 .word .LL7727 .word .LL7728 .word .LL7729 I looks like the emitter has an int for the label counter instead of a uint. [EMAIL PROTECTED] are]$ gcc -v Using built-in specs. Configured with: ../configure --prefix=/opt/gcc-3.4.3-cvs --with-gnu-as --with-gnu-ld Thread model: posix gcc version 4.0.0 20050120 (experimental) [EMAIL PROTECTED] are]$ gcj -v Using built-in specs. Reading specs from /NetFuel/compilers/solaris-sparc-2.8/gcc-3.4.3-cvs/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../libgcj.spec rename spec lib to liborig Configured with: ../configure --prefix=/opt/gcc-3.4.3-cvs --with-gnu-as --with-gnu-ld Thread model: posix gcc version 4.0.0 20050120 (experimental) -- Summary: Assembler labels have a leading - Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steve at netfuel dot com CC: gcc-bugs at gcc dot gnu dot org 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=20301
[Bug java/20302] New: Problem with sub classes with contructors with exceptions
GCJ does not handle compilation of sub classes with out explicitly defined constructors to override the super class constructors when the constructors throw exceptions. [EMAIL PROTECTED] steve]$ gcj Test.java -c Test.o Test.java: In class 'Test$1': Test.java: In constructor '(Test,java.io.ByteArrayInputStream)': Test.java:9: error: Exception 'java.io.IOException' must be caught, or it must be declared in the 'throws' clause of 'Test$1'. ObjectInputStream in = new ObjectInputStream(is) ^ Test.java:9: error: Exception 'java.io.StreamCorruptedException' must be caught, or it must be declared in the 'throws' clause of 'Test$1'. ObjectInputStream in = new ObjectInputStream(is) ^ 2 errors [EMAIL PROTECTED] steve]$ gcj Test2.java -c Test2.o Test2.java: In class 'Test2': Test2.java: In constructor '()': Test2.java:3: error: Exception 'java.io.IOException' must be caught, or it must be declared in the 'throws' clause of 'Test2'. class Test2 extends ObjectInputStream ^ 1 error -- Summary: Problem with sub classes with contructors with exceptions Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steve at netfuel dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
[Bug java/20302] Problem with sub classes with contructors with exceptions
--- Additional Comments From steve at netfuel dot com 2005-03-03 17:32 --- Created an attachment (id=8317) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8317action=view) Inner class test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
[Bug java/20302] Problem with sub classes with contructors with exceptions
--- Additional Comments From steve at netfuel dot com 2005-03-03 17:33 --- Created an attachment (id=8318) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8318action=view) Straigt sub class test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
[Bug java/20302] Problem with sub classes with contructors with exceptions
-- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
[Bug c/20303] New: Can't push more than 16 nested visibility
When #pragma GCC visibility push(default) #pragma GCC visibility pop are used for header file wrappers, we may have more 16 #pragma GCC visibility push(default) Currently gcc will fail. -- Summary: Can't push more than 16 nested visibility Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug c++/20304] New: Invalid value returned by operator '' when -O is used
Folks, We are reporting this issue both to the GCC people and the libsigc++ people, because the issue could be in either of them or both. On the surface, it looks like a g++ issue, but when you look deeper, libsigc++ might be relying on a behavior that is unspecified by any C++ standard. Input - File test1.cc is attached. Command line g++ -v -save-temps -O -g `pkg-config --cflags --libs gtkmm-2.4` test1.cc -o test1 Where `pkg-config --cflags --libs gtkmm-2.4` expands to: -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/atk-1.0 -Wl,--export-dynamic -lgtkmm-2.4 -lgdkmm-2.4 -latkmm-1.6 -lgtk-x11-2.0 -lpangomm-1.4 -lglibmm-2.4 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Command line output --- o TTY output: Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 3.3.4 /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -E -D__GNUG__=3 -quiet -v -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/atk-1.0 -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API test1.cc -O test1.ii ignoring nonexistent directory /usr/include/freetype2/config ignoring nonexistent directory /usr/i486-slackware-linux/include #include ... search starts here: #include ... search starts here: /usr/include/gtkmm-2.4 /usr/lib/gtkmm-2.4/include /usr/include/glibmm-2.4 /usr/lib/glibmm-2.4/include /usr/include/gdkmm-2.4 /usr/lib/gdkmm-2.4/include /usr/include/pangomm-1.4 /usr/include/atkmm-1.6 /usr/include/gtk-2.0 /usr/include/sigc++-2.0 /usr/lib/sigc++-2.0/include /usr/include/glib-2.0 /usr/lib/glib-2.0/include /usr/lib/gtk-2.0/include /usr/X11R6/include /usr/include/pango-1.0 /usr/include/freetype2 /usr/include/atk-1.0 /usr/lib/qt/include /usr/include/c++/3.3.4 /usr/include/c++/3.3.4/i486-slackware-linux /usr/include/c++/3.3.4/backward /usr/local/include /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include /usr/include End of search list. /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -fpreprocessed test1.ii -quiet -dumpbase test1.cc -auxbase test1 -g -O -version -o test1.s GNU C++ version 3.3.4 (i486-slackware-linux) compiled by GNU C version 3.3.4. GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113063 usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../../i486-slackware-linux/bin/as -V -Qy -o test1.o test1.s GNU assembler version 2.15.92.0.2 (i486-slackware-linux) using BFD version 2.15.92.0.2 20040927 /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test1 /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../crt1.o /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../crti.o /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/crtbegin.o -L/usr/lib/gcc-lib/i486-slackware-linux/3.3.4 -L/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../../i486-slackware-linux/lib -L/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../.. --export-dynamic -lgtkmm-2.4 -lgdkmm-2.4 -latkmm-1.6 -lgtk-x11-2.0 -lpangomm-1.4 -lglibmm-2.4 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 test1.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/crtend.o /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../crtn.o o Pre-processed file output A compressed (bzip2 -9) version of file test1.ii is attached. o Binary output When running the binary, a window pops up on the screen. In that window, there is a button. Click on the button. The binary gets a SEGV. This is the issue. Why it could be a g++ issue --- If you remove -O from the command line, then
[Bug c++/20304] Invalid value returned by operator '' when -O is used
--- Additional Comments From hpreg at vmware dot com 2005-03-03 18:24 --- Created an attachment (id=8319) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8319action=view) The code for the small test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20304
[Bug c++/20304] Invalid value returned by operator '' when -O is used
--- Additional Comments From hpreg at vmware dot com 2005-03-03 18:25 --- Created an attachment (id=8320) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8320action=view) Pre-processed file output (.ii file), compressed with bzip2 (-9) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20304
[Bug middle-end/20301] Assembler labels have a leading -
-- What|Removed |Added Severity|critical|normal Component|target |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20301
[Bug java/20302] Problem with sub classes with contructors with exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 18:42 --- I think this is a dup of another bug, but I am too lazy to find the bug right now. -- What|Removed |Added Severity|critical|normal Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 18:43 --- This is a documented behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From mark at codesourcery dot com 2005-03-03 18:47 --- Subject: Re: [3.4 Regression] const/pure functions result in bad asm ebotcazou at gcc dot gnu dot org wrote: 2. The tree-inliner inlines the call. Since the same tree is referenced twice in the expression, the inlined body is also referenced twice is the expression and, therefore, expanded twice to RTL. However labels are not expanded multiple times but reused, so the second block of RTL ends up referencing the first and all hell breaks loose. It really seems like the C++ front end is doing the right thing, abstractly -- these functions don't have side-effects! So, either the inliner or stabilize reference seems like it needs fixing. Maybe the latter should recognize CALL_EPRs? If it's not possible to fix this, then what we should do is modify build3 to mark CALL_EXPRs as having side-effects. Right now, it makrs them based on the flags for the function, so this problem isn't really C++-specific; it probably effects all languages except those whose front ends set TREE_SIDE_EFFECTS additionally themselves. (Unless C++ is changing out the operands to the CALL_EXPR after its created.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From hjl at lucon dot org 2005-03-03 18:47 --- It makes it less useful for header file wrappers. Supporting the case of N (N16) #pragma GCC visibility push(default) followed by N #pragma GCC visibility pop shouldn't be very hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug c++/16859] Empty initializer for array of unknown size spuriously accepted
--- Additional Comments From pcarlini at suse dot de 2005-03-03 18:47 --- Want to have a look, a fix seems easy... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16859
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Additional Comments From bugzilla at mdaniel dot scdi dot com 2005-03-03 19:03 --- In case anyone is curious, this causes the Mozilla HEAD build to fail [at least with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on two separate occasions, once with nsprpub and once with libmozjs.so. Removing the use of #pragma GCC visibility statements causes the source to build and link as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:11 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html FYI, gcc 3.4 from RH does include this pragma. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 19:06 --- (In reply to comment #2) In case anyone is curious, this causes the Mozilla HEAD build to fail [at least with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on two separate occasions, once with nsprpub and once with libmozjs.so. Removing the use of #pragma GCC visibility statements causes the source to build and link as expected. It cannot be causing a non modified gcc 3.4.3 to fail as 3.4.3 does not include this pragma at all, it is only included with 4.0.0 and above. -- What|Removed |Added CC||bugzilla at mdaniel dot scdi ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug bootstrap/20305] New: Miscompilation of libcpp/macro.c at -O1 and higher
It seems that gcc-4_0-branch GCC (both 20050228 and 20050303) miscompiles libcpp/macro.c if compiled at -O1 and higher. stage1 compiler built that way dies with: /usr/include/bits/stdio.h: In function printf': /usr/include/bits/stdio.h:36: error: syntax error before _restrict__' /usr/include/bits/stdio.h: In function etchar': /usr/include/bits/stdio.h:43: error: syntax error before _restrict__' /usr/include/bits/stdio.h: In function etchar_unlocked': /usr/include/bits/stdio.h:59: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. when compiling crtstuff.c. If libcpp/macro.c is built at -O0 or built with GCC 3.3.4 rather than gcc-4_0-branch, it works just fine. I'll try to locate the problematic routine and distill a testcase. -- Summary: Miscompilation of libcpp/macro.c at -O1 and higher Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: s390x-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Additional Comments From bugzilla at mdaniel dot scdi dot com 2005-03-03 19:19 --- $ gcc --version gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17) I stand corrected, Fedora Core 3 must be back-porting some of that functionality. Should I open a bug with them pointing to this, or is it just water under the bridge now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:19 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00238.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug rtl-optimization/20306] New: [4.0/4.1 Regression] FP complex modes moved via GPRs
The patch for PR rtl-opt/15289, changed the behavior of emit_move_insn_1 to invoke emit_block_move on memory to memory moves for optimal behavior, instead of invoking a movMM pattern on the inner mode. emit_block_move changes the mode to BLKmode masking the original mode. This sequence of decisions results in GCC choosing GPRs to move a value that explicitly is declared floating point in the user code, hurting performance. -- Summary: [4.0/4.1 Regression] FP complex modes moved via GPRs Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,pthaugen at us dot ibm dot com GCC build triplet: powerpc*-*-* GCC host triplet: powerpc*-*-* GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20306
[Bug bootstrap/20305] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 19:23 --- I want to say this is a dup of bug 20282 which is for ppc64-linux. -- What|Removed |Added BugsThisDependsOn||20282 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
-- What|Removed |Added OtherBugsDependingO||20305 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 19:24 --- PR 20305 is the bootstrap failure for s390x and it looks like the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:25 --- RH bug is at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150157 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 19:25 --- It really seems like the C++ front end is doing the right thing, abstractly -- these functions don't have side-effects! So, either the inliner or stabilize reference seems like it needs fixing. Maybe the latter should recognize CALL_EPRs? I agree that the C++ FE is theoritically right, but other FEs appear to already have realized that the implementation constraints trumpet the theory here: on mainline, the C, Java and Fortran 95 FEs set TREE_SIDE_EFFECTS on CALL_EXPRs. I think it is too late to fix the problem in the tree inliner because it would be tricky to detect there whether a CALL_EXPR is mentioned more than once. Special-casing CALL_EXPRs in stabilize_reference could indeed be the solution. We could even be clever and check whether tree inlining is enabled and, if so, whether it has already occurred. Does that sound plausible? If it's not possible to fix this, then what we should do is modify build3 to mark CALL_EXPRs as having side-effects. Right now, it makrs them based on the flags for the function, so this problem isn't really C++-specific; it probably effects all languages except those whose front ends set TREE_SIDE_EFFECTS additionally themselves. (Unless C++ is changing out the operands to the CALL_EXPR after its created.) Right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug rtl-optimization/20306] [4.0/4.1 Regression] FP complex modes moved via GPRs
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-03 19:26 --- Example Fortran code derived from BLAS ZGEMM routine. SUBROUTINE Z ( M, N, C, LDC ) * .. Scalar Arguments .. INTEGERM, N, LDC * .. Array Arguments .. COMPLEX*16 C( LDC, * ) * .. Local Scalars .. INTEGERI, J * .. Parameters .. COMPLEX*16 ZERO PARAMETER( ZERO = ( 0.0D+0, 0.0D+0 ) ) * DO 20, J = 1, N DO 10, I = 1, M C( I, J ) = ZERO 10 CONTINUE 20 CONTINUE * RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20306
[Bug java/20302] Problem with sub classes with contructors with exceptions
--- Additional Comments From steve at netfuel dot com 2005-03-03 19:31 --- I have looked for this bug and did not see one. 15501 is similar but is not the same problem or is a subset of the problems defined in my report. As my bug also affects any Extends with Exceptions defined in the super class constructor. The work around is to add the overrideing constructors and call super(..) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From mark at codesourcery dot com 2005-03-03 19:34 --- Subject: Re: [3.4 Regression] const/pure functions result in bad asm ebotcazou at gcc dot gnu dot org wrote: --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 19:25 --- It really seems like the C++ front end is doing the right thing, abstractly -- these functions don't have side-effects! So, either the inliner or stabilize reference seems like it needs fixing. Maybe the latter should recognize CALL_EPRs? I agree that the C++ FE is theoritically right, but other FEs appear to already have realized that the implementation constraints trumpet the theory here: on mainline, the C, Java and Fortran 95 FEs set TREE_SIDE_EFFECTS on CALL_EXPRs. Interesting. So, we have some checks in gcc/tree.c to try to avoid setting TREE_SIDE_EFFECTS, and then the FEs all set it anyhow. :-( Special-casing CALL_EXPRs in stabilize_reference could indeed be the solution. We could even be clever and check whether tree inlining is enabled and, if so, whether it has already occurred. Does that sound plausible? I don't think I'd try to be that clever. We might want the stabilization to occur even in other cases. In looking at it more closely, it definitely looks like stabilize_reference should deal with CALL_EXPRs. (I guess I was thinking that the problem with the duplicate labels could be avoided in the inliner by generating fresh labels. But, maybe that's not going to work for other reasons.) If it's not possible to fix this, then what we should do is modify build3 to mark CALL_EXPRs as having side-effects. Right now, it makrs them based on the flags for the function, so this problem isn't really C++-specific; it probably effects all languages except those whose front ends set TREE_SIDE_EFFECTS additionally themselves. (Unless C++ is changing out the operands to the CALL_EXPR after its created.) Right. OK, that's the fallback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug rtl-optimization/20306] [4.0/4.1 Regression] FP complex modes moved via GPRs
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20306
[Bug rtl-optimization/20306] [4.0/4.1 Regression] FP complex modes moved via GPRs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:48 ---
Confirmed, C testcase which shows that this is defintely a regression:
void f(double _Complex *f,int len)
{
int i = 0;
for(i = 0 ;i20;i++)
{
*f = 0.0;
f++;
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.0 4.1.0
Known to work||3.3.3
Last reconfirmed|-00-00 00:00:00 |2005-03-03 19:48:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20306
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-03 19:49 --- Subject: Re: AVR assignment of a value through a 16 bit pointer generates out of order code schlie at comcast dot net wrote: --- Additional Comments From schlie at comcast dot net 2005-03-03 19:47 --- (In reply to comment #6) Nope, these are peripheral i/o registers, and like any pheripheral interface may have access sequence requirements which need to be satsifyed within it's driver. These perpheral register's access sequence requirements have nothing to do with the avr's ISA or impled compiler requirments, just simply the conventions which need to be followed That's why this is an enhancement. This is a request to change those access conventions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
-- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 19:52 --- Just a note from 20282, since I think this is the same bug: the breakage appeared between 20041027 and 20041101. -- What|Removed |Added Keywords||build, ice-on-valid-code, ||rejects-valid, wrong-code Summary|Miscompilation of |[4.0/4.1 Regression] |libcpp/macro.c at -O1 and |Miscompilation of |higher |libcpp/macro.c at -O1 and ||higher Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47 --- (In reply to comment #6) Nope, these are peripheral i/o registers, and like any pheripheral interface may have access sequence requirements which need to be satsifyed within it's driver. These perpheral register's access sequence requirements have nothing to do with the avr's ISA or impled compiler requirments, just simply the conventions which need to be followed when attempting to access manipulate dynamically active 16-bit counter values through a pair of 8-bit i/o registers (which happen to be mapped in data address space, which isn't an uncommon, but implies nothing otherwise, other than you shouldn't assume that the compiler need sequence indirect access to arbitrary multi-word/byte transactions data to satisfy a peripheral's interface sequence that's the job of the author of the it's interface driver to guarantee; and by the way, you still need to disable interrupts if an interrupt routine may access the same registers, as all the sequence does is read/write upper 8-bit latched value when ever the lower 8-bit value is accessed, so therefore if you write the high value, get an interupt which writes both, then write the low value, you get the interrupt routines high value, combined with your new low value written, which isn't likely what you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 20:10 --- There are two routines likely miscompiled in libcpp/macro.c: replace_args and cpp_get_token (I removed all static keywords from the file, then did a binary search on which routines cause this). If all of macro.c but these 2 routines are compiled with gcc4 at -O2, but these 2 routines at -O0, crtstuff.c is preprocessed and compiled just fine. cpp_get_token is responsible for the error: syntax error before _restrict__ etc. errors, while if replace_args is compiled with -O2 it causes /usr/include/link.h:54: error: syntax error before `int64_Addr' /usr/include/link.h:64: error: syntax error before `r_ldbase' /usr/include/link.h:77: error: syntax error before `_DYNAMIC' /usr/include/link.h:90: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug libfortran/20278] Performance regression in formatted output vs. g77
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03 20:27 --- Same thing on i686: $ gfortran write-many.f $ time ./a.out real0m5.576s user0m5.508s sys 0m0.038s $ g77 write-many.f $ time ./a.out real0m3.252s user0m3.185s sys 0m0.041s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20278
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 20:51 --- Working on this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-02-23 19:49:11 |2005-03-03 20:51:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 21:12 --- I don't think I'd try to be that clever. We might want the stabilization to occur even in other cases. In looking at it more closely, it definitely looks like stabilize_reference should deal with CALL_EXPRs. But then what's the difference with setting TREE_SIDE_EFFECTS on CALL_EXPRs? Also for 3.4.x some FE don't use tree inlining at all so I don't think they should be penalized because of the C++ FE. (I guess I was thinking that the problem with the duplicate labels could be avoided in the inliner by generating fresh labels. But, maybe that's not going to work for other reasons.) How would you do that exactly? In our present case, the inliner inlines exactly one CALL_EXPR, but it is referenced twice in another tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/20307] New: template resolution is wrong when accessed with namespace prefix
In the program:
--
extern C int puts(const char*);
templatetypename A, typename B
void foo(A a, B b)
{
puts(ERROR: fooA, B);
}
templatetypename X
void bar(X a)
{
#ifdef ERROR
::foo(a, a);
#else
foo(a, a);
#endif
}
templatetypename A
void foo(A a, A b)
{
puts(OK: fooA);
}
int main()
{
int a = 0;
bar(a);
}
---
When foo template is accessed without namespace qualifier from within bar
template, GCC selects correct second variant of template variant.
If I put namespace qualifier gcc chooses the first variant.
This bug appeared with gcc 3.4 and exists in 3.4.1-3.4.3.
I didn't check newer versions.
There was no this bug in gcc 2.95-3.3.3.
Intel, Sun, and MS compilers all choose correct second variant of foo.
--
Summary: template resolution is wrong when accessed with
namespace prefix
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vasilche at ncbi dot nlm dot nih dot gov
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 3.4.0-3.4.3
GCC host triplet: Linux widget1 2.4.23-P4-4G #8 SMP Tue Dec 16 16:34:15
EST 2003 i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20307
[Bug rtl-optimization/19683] MIPS wrong-code for 64-bit multiply.
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-03 21:19 --- Thanks Richard, The patch applies cleanly against 3.4.3 (with an offset of something like 9 lines). I found no regressions with a top level make -k check for an i686-linux - mipsel-linux cross compiler with the patch applied to 3.4.3. I have been using the patch for about a week now on 3.4.3 with no problems found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19683
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From mark at codesourcery dot com 2005-03-03 21:19 --- Subject: Re: [3.4 Regression] const/pure functions result in bad asm ebotcazou at gcc dot gnu dot org wrote: --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 21:12 --- I don't think I'd try to be that clever. We might want the stabilization to occur even in other cases. In looking at it more closely, it definitely looks like stabilize_reference should deal with CALL_EXPRs. But then what's the difference with setting TREE_SIDE_EFFECTS on CALL_EXPRs? Also for 3.4.x some FE don't use tree inlining at all so I don't think they should be penalized because of the C++ FE. There are other places where TREE_SIDE_EFFECTS matters. (Like, do we have to emit this expression at all, if its result is not used?) The counter to your argument is that I don't see why the C++ front end should be penalized because other front ends have a workaround for what seems to be a bug in the middle end. The stated purpose for stabilize_reference is to make it possible to use an expression more than once. If CALL_EXPRs can't be used more than once (which your research would seem to prove), then it seems like stabilize_reference should handle that. (I guess I was thinking that the problem with the duplicate labels could be avoided in the inliner by generating fresh labels. But, maybe that's not going to work for other reasons.) How would you do that exactly? In our present case, the inliner inlines exactly one CALL_EXPR, but it is referenced twice in another tree. OK, I'm confused, then -- I think that either we have to fix this problem in stabilize_reference (which seems better to me) or always set TREE_SIDE_EFFECTS on CALL_EXPRs in build3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:36 --- BTW I will also propose a patch to make -fno-second-underscore the default, once this is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug c++/20308] New: lost parser
In the attached code, the parser gets confused by a use of operator in the body of a function template. If the operator is changed (to or == for example) the code compiles. I've not been able to figure out why it thinks it's in a constant expression. Changing the variable names involved doesn't make a difference, so it doesn't see to be a consequence of name clashes. Ivan -- Summary: lost parser Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
[Bug c++/20308] lost parser
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:47 --- Created an attachment (id=8321) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8321action=view) Compiler output (-v -save-temps) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
[Bug c++/20308] lost parser
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:48 --- Created an attachment (id=8322) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8322action=view) Source code (-save-temps) (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-03-03 21:49 --- Subject: Re: COMPLEX function returns incompatible with g77 On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote: BTW I will also propose a patch to make -fno-second-underscore the default, once this is fixed. I'm confused...shouldn't it be one or the other? i.e. either make -ff2c -fsecond-underscore the default, compatible with g77, *or* make -fno-f2c -fno-second-underscore the default, incompatible with g77 but free of f2c cruft. I would vote for the former, simply because compatibility with g77 by default has huge practical advantages for library distributors that seem (to me) to outweigh the aesthetic benefits of removing f2c cruft. (Making -fno-second-underscore the default does have the non-aesthetic practical advantage of better compatibility with non-GNU compilers, but the GNU project has traditionally placed a higher priority on compatibility with free software than with non-free software.) Steven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug libgcj/20292] new test case PR16923 fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03 21:59 --- Subject: Bug 20292 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-03 21:59:23 Modified files: libjava: ChangeLog libjava/testsuite/libjava.jni: jni.exp Log message: 2005-03-02 Thomas Fitzsimmons [EMAIL PROTECTED] PR libgcj/20292 * testsuite/libjava.jni/jni.exp (gcj_jni_invocation_compile_c_to_binary): Add -I. -I.. to compile flags. (gcj_jni_invocation_test_one): Add -L../.libs to cxx flags. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391r2=1.3391.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/jni.exp.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.18r2=1.18.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20292
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:59 --- This is weird. I just came across code (written by me) that should ensure the right behavior here. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-03 21:59:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 22:02 --- There are other places where TREE_SIDE_EFFECTS matters. (Like, do we have to emit this expression at all, if its result is not used?) OK. The counter to your argument is that I don't see why the C++ front end should be penalized because other front ends have a workaround for what seems to be a bug in the middle end. Agreed. But I also think that the FEs that don't use tree inlining cannot even remotely be affected by the problem, so certainly shouldn't be penalized either. The stated purpose for stabilize_reference is to make it possible to use an expression more than once. If CALL_EXPRs can't be used more than once (which your research would seem to prove), then it seems like stabilize_reference should handle that. Sure, but I think CALL_EXPRs without TREE_SIDE_EFFECTS can be reused more than once, once tree inlining is done, if they happen not to have been inlined. At least we don't have counter-examples yet. OK, I'm confused, then -- I think that either we have to fix this problem in stabilize_reference (which seems better to me) or always set TREE_SIDE_EFFECTS on CALL_EXPRs in build3. stabilize_reference is fine with me. We now only have to settle on the granularity of the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:06 --- I agree with you that -ff2c should imply -fsecond-underscore. I don't agree that the advantages of -ff2c outweigh the disadvantages of -fno-f2c so far that -fno-f2c should be the default. If we don't switch to -fno-f2c as default now, it will never happen in the foreseeable future. One practical problem with gfortran and -ff2c is the following: gfortran's library uses the -fno-f2c calling convention, so using -ff2c with my patch so-far will break use of complex functions as actual arguments. The restriction from the quote from g77's documentation applies the exactly opposite way. I haven't yet looked into how much of an effort fixing this would be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:08 --- Found the bug. Fixing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-03-03 21:59:57 |2005-03-03 22:08:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:17 --- Hm, there seems to be some confusion between when to use sym and when sym-result for a function. My fix won't make it worse, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug libgcj/20292] new test case PR16923 fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03 22:17 --- Subject: Bug 20292 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-03 22:17:26 Modified files: libjava: ChangeLog libjava/testsuite/libjava.jni: jni.exp Log message: 2005-03-03 Thomas Fitzsimmons [EMAIL PROTECTED] PR libgcj/20292 * testsuite/libjava.jni/jni.exp (gcj_jni_invocation_compile_c_to_binary): Add -I. -I.. to compile flags. (gcj_jni_invocation_test_one): Add -L../.libs to cxx flags. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3393r2=1.3394 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/jni.exp.diff?cvsroot=gccr1=1.18r2=1.19 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20292
[Bug libgcj/20292] new test case PR16923 fails
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:18 --- Fixed on mainline and gcc-4_0-branch. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20292
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-03-03 22:21 --- Hi, in order to completely resolve this issue, IIUC, one would have to sacrifice the post-increment addressing modes. In case of the X-Register, forcing the high-byte first rule allways would result in much less efficient code. For this reason, I think that enforcing the high-byte first rule always is not a good solution. There has been the suggestion to 1.) distinguish between pointer variables that are marked volatile and pointer variables that are not declared volatile and 2.) disable all post increment operations for such variables. In my opinion, this would not really be a clean solution, since IIUC, volatile uint16_t pointer is meant to be used for a pointer that, e.g. could be altered by an IRQ function, and the key-word volatile not meant to be used for classifying the variable the pointer is refering to. In fact, in the specific case no one would require the pointer no to be hold in a register variable. I also disagree that accessing IO-Memory by use of pointers is a very common case. Possibly it is a useful solution if one does not know at compile time which register will actually be in use. But I'd like to suggest, that this is sufficiently infrequently used to justify to require that sw developers use a special solution for this case, like the following: In order to enforce the byte-ordering, one could define an inline-asm instruction like #define WRITE_WORD_TO_MEMORY_MSB_FIRST(pointer_to_iom,value_to_be_stored) \ asm volatile (/* Storing %A1:%B1 to the memory address %A0:%B0 is pointing to, high byte first */\n\t \ st z+1,%B1 \n\t \ st z,%A1 \n\t \ : \ : z (pointer_to_iom), \ r (value_to_be_stored) ); \ Such an inline directive could be defined in one of the header files of avr-libc. Anybody that *really* could not avoid to access IOM-Space by pointers then would have the opportunity to make use of this makro. Summing up, my suggestion is not to change the compiler in order to avoid code-size and performace regressions. Instead, I consider it to be best to clearly document the issue and to provide a suitable macro definition in one of the avr-libc headers. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug libgcj/20251] [4.0 regression] libgcj configured with --enable-gtk-cairo fails on installation
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:22 --- What platform are you on? Can you paste the exact configure and make lines that cause the build failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
[Bug libgcj/20251] [4.0 regression] libgcj configured with --enable-gtk-cairo fails on installation
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:28 --- Also, was this a clean rebuild? In other words, did you start with an empty build directory and empty prefix before configuring and building? If not, I suggest you try that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
[Bug libgcj/20251] [4.0 regression] libgcj configured with --enable-gtk-cairo fails on installation
--- Additional Comments From doko at debian dot org 2005-03-03 22:38 --- The complete build logs can be found at http://buildd.debian.org/build.php?pkg=gcc-snapshot check for the 2005027 logs for i.e. powerpc and ia64. the build starts with a clean environment. I rechecked with an unpatched build from the branch. ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --enable-nls --enable-threads=posix --without-included-gettext --disable-werror --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --enable-checking=release powerpc-linux-gnu [...] LIBART_CONFIG=libart2-config \ /usr/bin/make -C /build/buildd/gcc-snapshot-20050227/build bootstrap-lean \ CC=gnatgcc \ CFLAGS=-g -O2 \ BOOT_CFLAGS=-O2 \ LDFLAGS= \ infodir=/usr/lib/gcc-snapshot/share/info \ mandir=/usr/lib/gcc-snapshot/share/man; \ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 22:39 --- The replace_args miscompilation seems to matter e.g. on: typedef int Elf64_Dyn; #define ElfW(type) _ElfW (Elf, 64, type) #define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) #define _ElfW_1(e,w,t) e##w##t ElfW(Dyn) x; which when preprocessed with miscompiled replace_args prints 64_Dyn x; for the last line and Elf64_Dyn x; when replace_args is built with -O0. There are 3 calls to replace_args and the 3rd one seems to be the one that matters, but I haven't found any obvious differences in the debugger yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-03 22:43 --- Subject: Re: pointer function with RESULT specified returns pointer to ptr rather than *ptr I have become convinced that graphical/diagrammatic rendering of some of the structures that we are using would be quite helpful. I'll have a think about how to do it - I have a notion that a tree structure with access macros on the connections might be a good mnemonic; cf our exchange of a few minutes ago. Paul - Original Message - From: tobi at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 03, 2005 11:17 PM Subject: [Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr --- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:17 --- Hm, there seems to be some confusion between when to use sym and when sym-result for a function. My fix won't make it worse, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From j dot gnu at uriah dot heep dot sax dot de 2005-03-03 22:49 --- (In reply to comment #9) There has been the suggestion to 1.) distinguish between pointer variables that are marked volatile and pointer variables that are not declared volatile and 2.) disable all post increment operations for such variables. In my opinion, this would not really be a clean solution, since IIUC, volatile uint16_t pointer is meant to be used for a pointer that, e.g. could be altered by an IRQ function, and the key-word volatile not meant to be used for classifying the variable the pointer is refering to. In fact, in the specific case no one would require the pointer no to be hold in a register variable. (It should be noted that this suggestion originally came from Marek Michalkiewicz, one of the original developers who ported GCC to the AVR.) While you're technically right on this, the point was that for a pointer variable marked volatile, sacrificing the post-increment addressing mode would not hurt at all, as by qualifying it volatile one already essentially gave up any and all expectations about getting the most effective code generated for it. OTOH, access to all IO resources is always done through volatile-qualified pointers, so this solution still appears to be the most logical one. Either way, I agree the behaviour should be documented. This is not to say the suggested macro doesn't have a valid point, too. But the wording of Björn's reply sounded a bit too dramatic in my opinion, in particular to those GCC developers who aren't familiar with the AVR. To me, Marek's suggestion (which is even supported by his patch that is known to work for many people) still sounds like the best compromise. Btw., it's not only accessing timer registers. Atmel requires the high-byte first access for a few other 16-bit IO registers as well (IIRC e.g the ADC registers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug libgcj/20292] new test case PR16923 fails
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20292
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:54 --- In this particular case (sym vs sym-result) the right thing IMO would be to either *always* create a sym-result variable, which takes on all the functions attributes, or to *always* copy the attributes of the result variable to the function's symbol. This should happen once the function has been completely resolved. I believe that the latter option could be more difficult for the exact reasons that the standard requires the use of RESULT in certain cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 22:55 --- *** Bug 20307 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||vasilche at ncbi dot nlm dot ||nih dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From joseph at codesourcery dot com 2005-03-03 22:58 --- Subject: Re: Can't push more than 16 nested visibility On Thu, 3 Mar 2005, pinskia at gcc dot gnu dot org wrote: This is a documented behavior. Arbitrary limits are still generally undesirable, even when documented. Some limits are very unlikely to be reached by real programs, even computer-generated ones, and genuinely motivated by efficiency. For example, the C front end only supports 268435455 (= 2^28 - 1) nested scopes. If there were a real use for more scopes, or for a very few programs to exceed other such limits motivated by efficiency concerns, we could add a --enable-huge-programs configure option to increase those limits at some performance cost to almost all normal programs. Another limit in a similar situation is the limit of USHRT_MAX parameters to a preprocessor macro. In this case, the limit is reached by real code and I very much doubt (without profiling information to show to the contrary) that there would be any measurable performance difference with using VEC, so we should just do that and get rid of the limit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From giovannibajo at libero dot it 2005-03-03 23:00 --- (In reply to comment #4) I strongly agree with everything in JSM's post. There is simply no reason for keeping such a stupid limit, and even less for manually optimizing conditions to enhance the limit. Using a VEC is more than enough for this case. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-03 23:00:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug c++/20307] template resolution is wrong when accessed with namespace prefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 22:54 --- Nope, qualified names bind right away, see PR 11828. And from the standard: From [temp.dep.candidate]: For a function call that depends on a template parameter, if the function name is an unqualified-id but not a template-id, the candidate functions are found using the usual lookup rules (3.4.1, 3.4.2) *** This bug has been marked as a duplicate of 11828 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20307
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
-- What|Removed |Added CC||bernie at develer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From olh at suse dot de 2005-03-03 23:17 ---
After this patch, gcc could not boostrap itself anymore:
TZ=UTC cvs diff -pu -D '20041031 09:00' -D '20041031 10:00' gcc/
I'm testing this patch currently on mainline:
Index: gcc/ChangeLog.12
===
RCS file: /tmp/gcc-cvs/gcc/gcc/ChangeLog.12,v
retrieving revision 2.2
diff -u -p -p -u -r2.2 ChangeLog.12
--- gcc/ChangeLog.1218 Jan 2005 13:42:43 - 2.2
+++ gcc/ChangeLog.123 Mar 2005 22:57:01 -
@@ -6837,12 +6837,6 @@
* c-common.c: Fix a comment typo.
-2004-10-31 Jason Merrill [EMAIL PROTECTED]
-
- PR middle-end/17526
- * tree-gimple.c (is_gimple_mem_rhs): Also require a val for
- aggregate types that are not BLKmode.
-
2004-10-30 Ziemowit Laski [EMAIL PROTECTED]
* c-common.h (objc_lookup_ivar): Add second parameter to
Index: gcc/tree-gimple.c
===
RCS file: /tmp/gcc-cvs/gcc/gcc/tree-gimple.c,v
retrieving revision 2.35
diff -u -p -p -u -r2.35 tree-gimple.c
--- gcc/tree-gimple.c 14 Dec 2004 13:41:52 - 2.35
+++ gcc/tree-gimple.c 3 Mar 2005 22:57:25 -
@@ -111,12 +111,9 @@ is_gimple_reg_rhs (tree t)
bool
is_gimple_mem_rhs (tree t)
{
- /* If we're dealing with a renamable type, either source or dest must be
- a renamed variable. Also force a temporary if the type doesn't need
- to be stored in memory, since it's cheap and prevents erroneous
- tailcalls (PR 17526). */
- if (is_gimple_reg_type (TREE_TYPE (t))
- || TYPE_MODE (TREE_TYPE (t)) != BLKmode)
+ /* If we're dealing with a renamable type, either source or dest
+ must be a renamed variable. */
+ if (is_gimple_reg_type (TREE_TYPE (t)))
return is_gimple_val (t);
else
return is_gimple_formal_tmp_rhs (t);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-03 23:24 --- Subject: Re: pointer function with RESULT specified returns pointer to ptr rather than *ptr Is this connected with functions that return character pointers being so completely screwed up? - Original Message - From: tobi at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 03, 2005 11:54 PM Subject: [Bug fortran/19673] pointer function with RESULT specified returns pointer to ptr rather than *ptr --- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:54 --- In this particular case (sym vs sym-result) the right thing IMO would be to either *always* create a sym-result variable, which takes on all the functions attributes, or to *always* copy the attributes of the result variable to the function's symbol. This should happen once the function has been completely resolved. I believe that the latter option could be more difficult for the exact reasons that the standard requires the use of RESULT in certain cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug c++/20308] parser thinks something is a start of a template-id when it is just less than
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:25 ---
Hmm, this is the reduced testcase (but I don't know if this is invalid as
Comeau also rejects it but I think
it is valid):
templatetypename int nick(int e);
templateint struct operation{int nick;};
templateint s
bool alphaMnemonic(const operations o1, const operations o2)
{
return o1.nick o2.nick;
}
If nick was not a template or not declated we accept it, if alphaMnemonic is
not a template we accept it.
I think we have a name lookup problem really. if we want o1.nick as a template
we need the template
keyword. This is not a regression if this is valid code, I really think it is.
ICC 8.0 accepts it.
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||rejects-valid
Known to fail||3.3.3 3.4.0 4.0.0 2.95.3
||3.2.3
Last reconfirmed|-00-00 00:00:00 |2005-03-03 23:25:22
date||
Summary|lost parser |parser thinks something is a
||start of a template-id when
||it is just less than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
[Bug libgcj/20251] [4.0 regression] libgcj configured with --enable-gtk-cairo fails on installation
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 23:26 --- What do you mean installing into a temporary location? What does the make install line look like? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
[Bug bootstrap/20305] [4.0/4.1 Regression] Miscompilation of libcpp/macro.c at -O1 and higher
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 23:30 --- Adding olh, so he does not miss the updates from this side since both bugs really the same bug. -- What|Removed |Added CC||olh at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From olh at suse dot de 2005-03-03 23:31 --- the change above allowed a bootstrap of gcc-4.0.0-20050228 with itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug bootstrap/20282] [4.0/4.1 Regression] gcc4 can not bootstrap itself anymore
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 23:32 --- Adding Jakub to the CC so he does not miss the updates from this bug since this and PR 20305 look to be the one and same bug really. Also note olh, has identified the patch which caused it for PPC64, Jakub, you might want to see if reverting the patch which olh found, also fixes the s390x problem. -- What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
[Bug middle-end/17526] [4.0 Regression] libcpp is miscompiled with -fno-pcc-struct-return -O2
--- Additional Comments From olh at suse dot de 2005-03-03 23:52 --- can these errors still be reproduced with current gcc 4.0 branch? the applied patch causes regressions: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
