[Bug target/23782] -Os +22%: gcc-3.4.4 does it in 230 bytes, gcc-4.0.2-pre in 281 bytes
--- Comment #2 from pluto at agmk dot net 2008-01-27 09:48 --- (In reply to comment #1) Can someone provide numbers for 4.1, 4.2 and 4.3? 4.1.2 (-Os -march=i486) textdata bss dec hex filename 281 0 0 281 119 tmp.o 4.2.2 20071010: textdata bss dec hex filename 287 0 0 287 11f tmp.o 4.3.0 20071029: textdata bss dec hex filename 266 0 0 266 10a tmp.o -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
--- Comment #3 from mariobonino at ubuntu-it dot org 2008-01-27 10:09 --- That error was received on a Ubuntu build machine so I don't have information about memory. However, I tried to build the package on my computer and I received the same error. I have 2GB RAM and gcc-4.2.2-7ubuntu1 installed. To get this I simply run make from the sources directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
[Bug c++/34988] New: gcc-4.3 (20080118 snapshot) crashes while building libstdc++ (locale_facets_nonio.tcc)
I'm trying to build gcc 4.3 on a PS3 with a ppc linux (yellow dog linux 5.1, gcc 4.1.1, binutils 2.18). I get the following error: /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc/xgcc -v -save-temps -shared-libgc c -B/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc -nostdinc++ -L/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/src -L/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/src/.libs -B/home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/bin/ -B/home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/lib/ -isystem /home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/include -isystem /home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/sys-include -m32 -msoft-float -fPIC -mstrict-align -I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/include/ppc64-ps3gobo-linux-gnu -I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/include -I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -m32 -msoft-float -fPIC -mstrict-align -c /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/./libstdc++-v3/src/locale-inst.cc -fPIC -DPIC -o .libs/locale-inst.o Reading specs from /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc/specs Target: ppc64-ps3gobo-linux-gnu Configured with: /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/./configure linux gnu Thread model: posix gcc version 4.3.0 20080118 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-B/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc' '-nostdinc++' '-L/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/src' '-L/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/src/.libs' '-B/home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/bin/' '-B/home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/lib/' '-isystem' '/home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/include' '-isystem' '/home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/sys-include' '-msoft-float' '-I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/include/ppc64-ps3gobo-linux-gnu' '-I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/include' '-I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/libstdc++-v3/libsupc++' '-fno-implicit-templates' '-Wall' '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-fdiagnostics-show-location=once' '-ffunction-sections' '-fdata-sections' '-g' '-O2' '-D_GNU_SOURCE' '-m32' '-msoft-float' '-mstrict-align' '-c' '-fPIC' '-DPIC' '-o' '.libs/locale-inst.o' '-mcpu=cell' /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc/cc1plus -E -quiet -nostdinc++ -v -I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/include/ppc64-ps3gobo-linux-gnu -I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/ppc64-ps3gobo-linux-gnu/32/nof/libstdc++-v3/include -I/home/gobo/Files/Compile/Sources/gcc-4.3-20080118/libstdc++-v3/libsupc++ -imultilib 32/nof -iprefix /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/gcc/../lib/gcc/ppc64-ps3gobo-linux-gnu/4.3.0/ -isystem /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc/include -isystem /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/./gcc/include-fixed -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D_GNU_SOURCE -DPIC -isystem /home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/include -isystem /home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/sys-include /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/./libstdc++-v3/src/locale-inst.cc -msoft-float -m32 -msoft-float -mstrict-align -mcpu=cell -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -fworking-directory -O2 -fpch-preprocess -o locale-inst.ii ignoring nonexistent directory /home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/include ignoring nonexistent directory /home/gobo/Programs/GCC/4.3_20080118/ppc64-ps3gobo-linux-gnu/sys-include ignoring nonexistent directory /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/gcc/../lib/gcc/ppc64-ps3gobo-linux-gnu/4.3.0/include ignoring nonexistent directory /home/gobo/Files/Compile/Sources/gcc-4.3-20080118/_build/gcc/../lib/gcc/ppc64-ps3gobo-linux-gnu/4.3.0/include-fixed ignoring nonexistent directory
[Bug c++/34988] gcc-4.3 (20080118 snapshot) crashes while building libstdc++ (locale_facets_nonio.tcc)
--- Comment #1 from giamby at infinito dot it 2008-01-27 10:26 --- Created an attachment (id=15027) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15027action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34988
[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type
--- Comment #12 from dominiq at lps dot ens dot fr 2008-01-27 10:32 --- It seems that this patch breaks the original test case of pr33998: pr33998.f90: In function 'my_string': pr33998.f90:7: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:842 but not the reduced ones of comment #1. Sould I reopen pr33998? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
[Bug fortran/34975] [4.3 Regression] Bogus error with USEing modules
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-27 10:34 --- I note that the pigeon carrying my reply to #3 got lost; my subsequent message must therefore be a bit mysterious. Changing the name of the symtree of an unwanted symbol from 'foo' to 'hidden.foo' is completely screwing up walking the symtree and causing duplicate symbols to be generated. I tried to do this when I wrote the patch but simply did not think about the problems that dummy arguments would cause. I have used delete_symtree to partially cure this problem. I need now to mend part of the mechanism introduced by the original patch. It's nearly there:) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-26 13:25:22 |2008-01-27 10:34:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34975
[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type
--- Comment #13 from dominiq at lps dot ens dot fr 2008-01-27 10:41 --- Following comment #12, I also see an ICE for pr34897: pr34897.f90: In function 'my_string': pr34897.f90:1: warning: Function does not return a value pr34897.f90:4: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:842 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type
--- Comment #14 from dominiq at lps dot ens dot fr 2008-01-27 11:26 --- Note that I am not sure to blame the right patch. What I can tell for sure is that pr33998.f90 started to fail between the 19th (working, rev. 131656) and the 20th (ICE, rev. 131679), and pr34897.f90 between the 20th (working, rev. 131679) and the 21st (ICE, rev. 131700). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
[Bug c++/26099] support for type traits is not available
--- Comment #12 from pcarlini at suse dot de 2008-01-27 11:44 --- Yes, I noticed. Frankly, I'm not really worried because of the nature of the tests: the checks can give different answers depending on whether the compiler is able or not to figure out that a given function cannot throw. For some reason (which I agree would be interesting to understand in better detail), -fpic/PIC makes makes more difficult for the compiler to assess that a function cannot really throw. I'm not sure about the best way to fix that: we could just zap those specific tests which have such instability, or condition the result on -fpic/PIC via macros, or something better. I would probably be tempted to go the first route, for 4.3.0., at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug target/23782] -Os +22%: gcc-3.4.4 does it in 230 bytes, gcc-4.0.2-pre in 281 bytes
--- Comment #3 from pluto at agmk dot net 2008-01-27 11:46 --- 4.3.0 20080127: textdata bss dec hex filename 281 0 0 281 119 tmp.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-27 12:22 --- We still need preprocessed souce (you get that from passing -save-temps) of the affected file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type
--- Comment #15 from dominiq at lps dot ens dot fr 2008-01-27 12:02 --- Note that I am not sure to blame the right patch. I was correct, pr33998.f90 started to fail after rev. 131676 and pr34897.f90 after rev. 131679. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
[Bug c++/26099] support for type traits is not available
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-27 12:48 --- If a function isn't marked nothrow and the function can be overridden by a shared library (that is, it doesn't bind locally), the compiler cannot derive such property from its body. (I didn't look at the tests, but usually marking the affected functions nothrow or making them bind locally works around this problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
--- Comment #5 from mariobonino at ubuntu-it dot org 2008-01-27 12:56 --- I don't know if this is ok but I've got this. http://pastebin.ubuntu.com/3935/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
[Bug middle-end/34882] g++: Internal error: Killed (program cc1plus)
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-27 12:50 --- The initialize_command_download() exposes the usual memory-hungriness of GCC with repetitive C++ initializers. We have plenty of bugreports with testcases for this, closing as invalid. And yes, 32MB + 200MB swap will never make you happy with C++ and gcc. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34882
[Bug tree-optimization/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #13 from roebel at ircam dot fr 2008-01-27 12:35 --- Hi, I run the tests with g++ 422 and it seems to me the issue is closed. Compilation without the salias-max-implicit-fields flag is nor producing any substantial increase in run time any more and with and without this parameter the hand optimized and compiler template version of the code have very similar run time. I would be really happy with this, if gcc422 would produce correct code in all my projects. I tried it already a while ago and found a problem with std::set where the optimized version of the program simply did and up with duplicate entries in the set (while gcc 4.1.2 has no problems with the very same code)!!! Besides that show stopper we had other problems with code using sse/sse2 intrinsics producing wrong results when optimization was enabled. All this may have changed in gcc4.3. I will give it another trial. Thanks -- roebel at ircam dot fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug target/23782] -Os +22%: gcc-3.4.4 does it in 230 bytes, gcc-4.0.2-pre in 281 bytes
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-27 12:45 --- Ok, someone needs to analyze this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-01-27 12:45:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
[Bug middle-end/23782] SRA pessimizes passing structures by value at -Os (+22% code size)
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-27 13:27 ---
I think this is another variant of PR28831. For the simplified testcase
typedef struct {
unsigned short x, y;/* x should be the easyest to read */
} coord;
void setpixel (coord xy, unsigned color);
void plotHline (coord xy, unsigned short xend, unsigned color);
extern inline void
UI_plotHline (coord xy, unsigned short xend, unsigned color)
{
plotHline (xy, xend, color);
}
extern inline void
UI_setpixel (coord xy, unsigned color)
{
setpixel (xy, color);
}
void drawbutton (coordupperleft, coord lowerright,
unsigned upperleftcolor, unsigned lowerrightrcolor,
unsigned fillcolor, unsigned drawbackground)
{
UI_setpixel (upperleft, upperleftcolor);
if (drawbackground)
UI_plotHline (((coord) { .x = upperleft.x, .y = upperleft.y }),
lowerright.x, fillcolor);
UI_setpixel (lowerright, lowerrightrcolor);
}
We end up doing extra stack temporaried for the first call exanding from:
bb 2:
upperleft$x = upperleft.x;
upperleft$y = upperleft.y;
lowerright$x = lowerright.x;
lowerright$y = lowerright.y;
xy.y = upperleft$y;
xy.x = upperleft$x;
setpixel (xy, upperleftcolor);
In our case SRA inhibits re-use of struct temporaries as
we no longer see the simple copies.
And indeed with -fno-tree-sra the size goes down to that of GCC 3.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28831
Component|target |middle-end
Known to fail||4.3.0
Known to work||3.4.6
Summary|-Os +22%: gcc-3.4.4 does it |SRA pessimizes passing
|in 230 bytes, gcc-4.0.2-pre |structures by value at -Os
|in 281 bytes|(+22% code size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
[patch, libfortran] Fix PR 34980
Hello world,
this fixes PR 34980, a 4.3 regression.
In the PR, there is a comment from Tobias B. with an alternate approach.
I was already into testing my patch when I read that comment, which is
why I didn't pursue that approach further. I have to admit that I feel
better about adding something that's obviously (to me) correct to a
library function than to do this in the front end.
Regression-tested on i686-pc-linux-gnu. OK for trunk?
Thomas
2008-01-27 Thomas Koenig [EMAIL PROTECTED]
PR libfortran/34980
* m4/shape.m4: If return array is empty, return early.
* generated/shape_i4.c: Regenerated.
* generated/shape_i8.c: Regenerated.
* generated/shape_i16.c: Regenerated.
2008-01-27 Thomas Koenig [EMAIL PROTECTED]
PR libfortran/34980
* gfortran.dg/shape_3.f90: New test.
Index: m4/shape.m4
===
--- m4/shape.m4 (revision 131874)
+++ m4/shape.m4 (working copy)
@@ -49,6 +49,9 @@ shape_'rtype_kind` ('rtype` * const rest
stride = ret-dim[0].stride;
+ if (ret-dim[0].ubound ret-dim[0].lbound)
+return;
+
for (n = 0; n GFC_DESCRIPTOR_RANK (array); n++)
{
ret-data[n * stride] =
! { dg-do run }
! PR 34980 - we got a segfault for calling shape
!with a scalar.
program main
integer :: n
n = 5
open(10,status=scratch)
write (10,*) shape(n)
close(10,status=delete)
end
[Bug target/23782] SRA pessimizes passing structures by value at -Os (+22% code size)
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 13:45 --- Copyprop for aggregates would also help here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
[Bug c++/26099] support for type traits is not available
--- Comment #14 from pcarlini at suse dot de 2008-01-27 13:34 --- (In reply to comment #13) If a function isn't marked nothrow and the function can be overridden by a shared library (that is, it doesn't bind locally), the compiler cannot derive such property from its body. Thanks for the details. (I didn't look at the tests, but usually marking the affected functions nothrow or making them bind locally works around this problem). Well, the functions in those specific tests aren't marked no throw on purpose (we do have other tests for the no throw variants), because I was exactly testing that in some specific cases the C++ front-end is able to figure out by itself that the function doesn't really throw. All in all I'm now thinking that it's good to have such tests, we should only conditionalize the result of the tests on -fpic/PIC, I suppose we do have a macro for that?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug target/23782] SRA pessimizes passing structures by value at -Os (+22% code size)
--- Comment #6 from aldot at gcc dot gnu dot org 2008-01-27 13:36 --- $ for i in 2.95 3.3 3.4 4.1 4.3.orig-HEAD 4.3-HEAD;do echo # GCC $(gcc-$i --version | sed 1q);gcc-$i -Os -c -o pr.o.gcc-$i pr23782.c;done # GCC 2.95.4 pr23782.c:8: warning: `fastcall' attribute directive ignored # GCC gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-15) pr23782.c:8: warning: `fastcall' attribute directive ignored # GCC gcc-3.4 (GCC) 3.4.6 (Debian 3.4.6-5) # GCC gcc-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) # GCC gcc-4.3.orig-HEAD (GCC) 4.3.0 20080112 (experimental) # GCC gcc-4.3-HEAD (GCC) 4.3.0 20080126 (experimental) $ size *.o.* textdata bss dec hex filename 266 0 0 266 10a pr.o.gcc-2.95 202 0 0 202 ca pr.o.gcc-3.3 230 0 0 230 e6 pr.o.gcc-3.4 284 0 0 284 11c pr.o.gcc-4.1 281 0 0 281 119 pr.o.gcc-4.3-HEAD 281 0 0 281 119 pr.o.gcc-4.3.orig-HEAD the same with -fomit-frame-pointer is even worse for 4.x: $ for i in 2.95 3.3 3.4 4.1 4.3.orig-HEAD 4.3-HEAD;do echo # GCC $(gcc-$i --version | sed 1q);gcc-$i -Os -fomit-frame-pointer -c -o pr.o.gcc-$i pr23782.c;done # GCC 2.95.4 pr23782.c:8: warning: `fastcall' attribute directive ignored # GCC gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-15) pr23782.c:8: warning: `fastcall' attribute directive ignored # GCC gcc-3.4 (GCC) 3.4.6 (Debian 3.4.6-5) # GCC gcc-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) # GCC gcc-4.3.orig-HEAD (GCC) 4.3.0 20080112 (experimental) # GCC gcc-4.3-HEAD (GCC) 4.3.0 20080126 (experimental) $ size *.o.* textdata bss dec hex filename 271 0 0 271 10f pr.o.gcc-2.95 199 0 0 199 c7 pr.o.gcc-3.3 239 0 0 239 ef pr.o.gcc-3.4 313 0 0 313 139 pr.o.gcc-4.1 315 0 0 315 13b pr.o.gcc-4.3-HEAD 315 0 0 315 13b pr.o.gcc-4.3.orig-HEAD -- aldot at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #6 from hubicka at ucw dot cz 2008-01-27 13:54 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
cgraph_local_info still behaves as expected returning NULL when info is
not computed yet. Unfortunately check to simply ignore it when not
available has been added to ix86_function_regparm that makes this bug
lead to wrong code. (revision 123146)
There are two occurences where we can ix86_function_regparm. First one
is for compatibility checking, I would just declare it invalid - we
don't want the type comatiblity to depend on backend decision and I
think it is perfectly sane to reject any types specifying different
REGPARM values or where one specify and other doesn't.
I am testing attached patch and will commit it if passes.
Other case is from gimplifier, I am looking into it. This definitly has
to go or we need to drop the feature :(
Honza
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 131882)
+++ config/i386/i386.c (working copy)
@@ -3148,6 +3148,7 @@ ix86_comp_type_attributes (const_tree ty
{
/* Check for mismatch of non-default calling convention. */
const char *const rtdstr = TARGET_RTD ? cdecl : stdcall;
+ tree attr1, attr2;
if (TREE_CODE (type1) != FUNCTION_TYPE
TREE_CODE (type1) != METHOD_TYPE)
@@ -3155,11 +3156,27 @@ ix86_comp_type_attributes (const_tree ty
/* Check for mismatched fastcall/regparm types. */
if ((!lookup_attribute (fastcall, TYPE_ATTRIBUTES (type1))
- != !lookup_attribute (fastcall, TYPE_ATTRIBUTES (type2)))
- || (ix86_function_regparm (type1, NULL)
- != ix86_function_regparm (type2, NULL)))
+ != !lookup_attribute (fastcall, TYPE_ATTRIBUTES (type2
return 0;
+ /* We don't want to use ix86_function_regparm here: it's decision depends
+ on middle end information, like localness of functions. Here we only
want
+ to know if types are declared compatible. */
+ attr1 = lookup_attribute (regparm, TYPE_ATTRIBUTES (type1));
+ attr2 = lookup_attribute (regparm, TYPE_ATTRIBUTES (type2));
+
+ if ((attr1 != NULL_TREE) != (attr2 != NULL_TREE))
+return 0;
+
+ if (attr1)
+{
+ int val1 = TREE_INT_CST_LOW (TREE_VALUE (TREE_VALUE (attr1)));
+ int val2 = TREE_INT_CST_LOW (TREE_VALUE (TREE_VALUE (attr2)));
+
+ if (val1 != val2)
+ return 0;
+}
+
/* Check for mismatched sseregparm types. */
if (!lookup_attribute (sseregparm, TYPE_ATTRIBUTES (type1))
!= !lookup_attribute (sseregparm, TYPE_ATTRIBUTES (type2)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 14:14 ---
One important structure copy propagation that SRA is not able to handle is
struct X { int i; int j; };
void foo(struct X);
inline void wrap(struct X w) { foo(w); }
void bar(struct X x) { wrap(x); }
where a copy from the parameter x in bar to the temporary used as parameter
to the call to foo remains (because both cannot be decomposed by SRA as
they need to live in memory):
bar (x)
{
int x$j;
int x$i;
struct X w;
bb 2:
x$i_8 = x.i;
x$j_9 = x.j;
w.j = x$j_9;
w.i = x$i_8;
foo (w) [tail call];
return;
}
In this case expansion works anyway because the call to foo is marked as
tail-call before SRA comes along.
SRA heuristics also doesn't work very well here, as it is clearly not
profitable to do element-copy here; in fact it probably makes structure
copy-prop more difficult to implement.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|23782 |
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 14:19 --- One more reason to gimplify unit-at-a-time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34711] [4.3 Regression] g++.dg/tree-ssa/ivopts-1.C fails for power and arm
--- Comment #4 from steven at gcc dot gnu dot org 2008-01-27 15:05 --- Fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
[Bug target/34711] [4.3 Regression] g++.dg/tree-ssa/ivopts-1.C fails for power and arm
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-27 15:35 --- The patch fixes the problem for me on ppc (tested in crosscompiler) and on amd64, I did not check the other architectures (arm, hppa, mips) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360
--- Comment #32 from steven at gcc dot gnu dot org 2008-01-27 15:35 --- I have re-tested Zdenek's patch on arm-unknown-elf. 128 files are smaller with the patch, and 126 files are larger. The total size increase with the patch is 324 bytes on 3601910 bytes total size (or 0.01%) with r131735. Neglecting all size increases, the total win with the patch is -2552 bytes, which is still less than one tenth of a percent. The biggest win is for lib/zlib_inflate/inffast from the package linux-2.4.23-pre3-testplatform. The size decrease is 112 bytes with the patch, or -9.84%. The biggest loser is jidctred from jpeg-6b with 100 bytes for +7.08%, but in bytes the loser is src/nrrd/axis from teem-1.6.0-src with 184 bytes or 4.05%. It would be interesting to investigate the inffast improvement. But the overall gain or loss with this patch makes it seem this isn't worth perusing too much further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug fortran/34990] New: [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
I have wrongly reported this regression under PR34848: pr33998.f90 started to
fail after rev. 131676 and pr34897.f90 after rev. 131679. These ICEs occurs now
for the original test cases:
[ibook-dhum] f90/bug% cat pr33998.f90
module test
implicit none
contains
function my_string(x)
integer i
real, intent(in) :: x(:)
character(0) h4(1:minval([(1,i=1,0)],1))
character(0) sv1(size(x,1):size(h4))
character(0) sv2(2*lbound(sv1,1):size(h4))
character(lbound(sv2,1)-3) my_string
do i = 1, len(my_string)
my_string(i:i) = achar(modulo(i-1,10)+iachar('0'))
end do
end function my_string
end module test
program len_test
use test
implicit none
real x(7)
write(*,*) my_string(x)
end program len_test
[ibook-dhum] f90/bug% cat pr34897.f90
function my_string(x)
integer i
real, intent(in) :: x(:)
character(0) h4(1:minval([(1,i=1,0)],1)) ! If range is 1,0 bombs out.
character(0) sv1(size(x,1):size(h4))
character(0) sv2(2*lbound(sv1,1):size(h4))
character(lbound(sv2,1)-3) my_string
end function my_string
end
In both cases the ICEs are:
[ibook-dhum] f90/bug% gfc pr33998.f90
pr33998.f90: In function 'my_string':
pr33998.f90:7: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:842
...
[ibook-dhum] f90/bug% gfc pr34897.f90
pr34897.f90: In function 'my_string':
pr34897.f90:1: warning: Function does not return a value
pr34897.f90:4: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:842
...
--
Summary: [4.3 Regression] ICE in gfc_typenode_for_spec, at
fortran/trans-types.c:842
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc/i686-apple-darwin9
GCC host triplet: powerpc/i686-apple-darwin9
GCC target triplet: powerpc/i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug c/34989] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-27 17:24 --- Created an attachment (id=15028) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15028action=view) file 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug middle-end/34989] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-27 17:24 --- Created an attachment (id=15029) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15029action=view) file2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug middle-end/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-27 17:26 --- Works fine with gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) And did work with trunk until recently (at least end of december, IIRC) -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.1.2 Summary|ICE in in |[4.3 Regression] ICE in in |get_addr_dereference_operand|get_addr_dereference_operand |s, at tree-ssa- |s, at tree-ssa- |operands.c:1698 |operands.c:1698 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug c/34989] New: ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698
/there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -Os -pipe -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fno-branch-count-reg -fno-builtin -fstack-protector -fstack-protector-all -mtune=pentium4 -march=pentium4 -Wstack-protector --combine -funit-at-a-time -Wno-error -std=gnu99 -o busybox_unstripped syslogd.i xregcomp.i xregcomp.i: In function 'syslogd_main': xregcomp.i:9926: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1698 Please submit a full bug report, $ /there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -v Using built-in specs. Target: i686-linux-uclibc Configured with: /there.pentium4/toolchain_build_i686/gcc-4.3.0/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i686-linux-uclibc --enable-languages=c,fortran --with-sysroot=/there.pentium4/build_i686/staging_dir --with-build-time-tools=/there.pentium4/build_i686/staging_dir/usr/i686-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/there.pentium4/toolchain_build_i686/gmp --with-mpfr=/there.pentium4/toolchain_build_i686/mpfr --disable-nls --enable-threads --disable-multilib --with-arch=pentium4 --with-tune=pentium4 --disable-libgomp Thread model: posix gcc version 4.3.0 20080127 (experimental) (GCC) -- Summary: ICE in in get_addr_dereference_operands, at tree-ssa- operands.c:1698 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #19 from ubizjak at gmail dot com 2008-01-27 17:52 --- The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771. -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||34771 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #20 from ubizjak at gmail dot com 2008-01-27 17:53 --- (In reply to comment #19) The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771. Oops, PR 34711. -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn|34771 |34711 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug middle-end/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-27 17:40 --- Reducing, the order for the files matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug middle-end/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698 with IMA
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-27 18:00 --- Yet another IMA bug. P2. Does 4.2 work? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.3 Regression] ICE in in |[4.3 Regression] ICE in in |get_addr_dereference_operand|get_addr_dereference_operand |s, at tree-ssa- |s, at tree-ssa- |operands.c:1698 |operands.c:1698 with IMA Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug middle-end/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698 with IMA
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-27 18:05 ---
First file:
extern struct globals *const ptr_to_globals;
struct globals { };
int syslogd_main(int argc, char **argv)
{
(*(struct globals**)ptr_to_globals) = 0;
}
- CUT -
Second file:
extern struct globals *const ptr_to_globals;
CUT -
-O2 is enough to reproduce this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-27 18:05:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #8 from hubicka at ucw dot cz 2008-01-27 18:10 --- Subject: Re: [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher One more reason to gimplify unit-at-a-time... Yep, on the other hand there is probably not much need to get that amount of architectural detail so easy. I am looking into what makes the compilation to diverge. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug middle-end/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698 with IMA
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-27 18:10 --- original and reduced testcases work with 4.2: $ gcc-4.2 -O2 -c -o bazoo.o one.i two.i -combine ; echo $? 0 $ gcc-4.2 -O2 -c -o bazoo.o syslogd.i xregcomp.i -combine ; echo $? 0 $ gcc-4.2 --version | sed 1q gcc-4.2 (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.2 |4.1.2 4.2.3 Priority|P2 |P3 Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug middle-end/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698 with IMA
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug tree-optimization/34989] [4.3 Regression] ICE in in get_addr_dereference_operands, at tree-ssa-operands.c:1698 with IMA
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-27 18:16 --- (gdb) p debug_generic_expr (stmt) *(struct globals * *) ptr_to_globals = 0B Well that is obviously not valid gimple. tree-ssa-forwprop.c is causing it: #10 0x00550bff in mark_symbols_for_renaming (stmt=0x43497060) at /Users/apinski/src/local/gcc/gcc/tree-dfa.c:827 #11 0x00646f45 in tidy_after_forward_propagate_addr (stmt=0x43497060) at /Users/apinski/src/local/gcc/gcc/tree-ssa-forwprop.c:468 #12 0x00648069 in forward_propagate_addr_expr_1 (name=0x4348dfc0, def_rhs=0x43497000, use_stmt=0x43497060, single_use_p=1 '\001') at /Users/apinski/src/local/gcc/gcc/tree-ssa-forwprop.c:566 #13 0x006495b2 in forward_propagate_addr_expr (name=0x4348dfc0, rhs=0x43497000) at /Users/apinski/src/local/gcc/gcc/tree-ssa-forwprop.c:709 #14 0x0064dce6 in tree_ssa_forward_propagate_single_use_vars () at /Users/apinski/src/local/gcc/gcc/tree-ssa-forwprop.c:971 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-27 18:19 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot ||org, tkoenig at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-27 18:19:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug c/34873] varasm.c:3387: warning: right shift count = width of type
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-27 18:35 --- right.. thus closing. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Version|4.1.2 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34873
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-27 18:37 --- Reverting with the following clears this bug: Index: array.c === --- array.c (revision 131876) +++ array.c (working copy) @@ -1025,7 +1025,6 @@ gfc_check_constructor_type (gfc_expr *e) cons_state = CONS_START; gfc_clear_ts (constructor_ts); - gfc_clear_ts (e-ts); t = check_constructor_type (e-value.constructor); if (t == SUCCESS e-ts.type == BT_UNKNOWN) I suspect we just need to do this clearing conditioned on somthing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug c/32102] -Wall stomps on -Wstrict-overflow
--- Comment #16 from manu at gcc dot gnu dot org 2008-01-27 18:37 --- Subject: Bug 32102 Author: manu Date: Sun Jan 27 18:36:59 2008 New Revision: 131887 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131887 Log: 2008-01-27 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR 32102 * flags.h (warn_strict_aliasing): Remove. (warn_strict_overflow): Remove. * opts.c (warn_strict_aliasing): Remove. (warn_strict_overflow): Remove. * c-opts.c (c_common_handle_option): -Wall only sets -Wstrict-aliasing or -Wstrict-overflow if they are uninitialized. (c_common_post_options): Give default values to -Wstrict-aliasing and -Wstrict-overflow if they are uninitialized. * common.opt (Wstrict-aliasing): Specify Var and Init. (Wstrict-overflow): Likewise. testsuite/ * gcc.dg/Wstrict-overflow-21.c: New. * g++.dg/warn/Wstrict-aliasing-8.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-8.C branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/Wstrict-overflow-21.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/c-opts.c branches/gcc-4_2-branch/gcc/common.opt branches/gcc-4_2-branch/gcc/flags.h branches/gcc-4_2-branch/gcc/opts.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 18:47 --- Fixed in the above revision. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug c++/26099] support for type traits is not available
--- Comment #17 from pcarlini at suse dot de 2008-01-27 18:54 --- Hi Kaveh. One problem I can see is that we are dealing with special member functions, like constructors and assignment operators. Can you see anything wrong with the straightforward implementation of idea per the attached patchlet? If it looks ok to you, it would be matter of doing the same for the other 2 files... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #16 from pcarlini at suse dot de 2008-01-27 18:51 --- Created an attachment (id=15030) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15030action=view) Draft idea for the -fpic/-fPIC fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c/32102] -Wall stomps on -Wstrict-overflow
--- Comment #17 from manu at gcc dot gnu dot org 2008-01-27 18:39 --- Fixed in GCC 4.2.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.3.0 |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
[Bug c++/26099] support for type traits is not available
--- Comment #15 from ghazi at gcc dot gnu dot org 2008-01-27 18:39 --- All in all I'm now thinking that it's good to have such tests, we should only conditionalize the result of the tests on -fpic/PIC, I suppose we do have a macro for that?!? How about binding locally when pic? E.g.: #ifdef __PIC__ static #endif function_foo() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug fortran/34910] [4.2/4.3 Regression] ICE on invalid assignments in doubly-contained functions
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-27 19:21 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-27 19:21:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #9 from hubicka at ucw dot cz 2008-01-27 19:24 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
However the failure here is not early calling of cgraph_local_info (it
is ugly, but harmless, we are just looking for target promoting rules
that we don't change).
The problem is good old type system broken scenario: the forward
declaration has no prorotype and thus might be vararg and thus it is not
regparmized, however the definition is correct. When expanding the call
we use type of the call, so the wrong type.
I am testing the attached patch. My type merging code fixes this too and
obvioiusly we should work harder on maybe_vaarg rule for local
functions, this should make lot of difference on KR code (I wonder if
any is still around in usual distro)
Honza
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 131882)
--- config/i386/i386.c (working copy)
*** init_cumulative_args (CUMULATIVE_ARGS *c
*** 3432,3437
--- 3449,3455
rtx libname, /* SYMBOL_REF of library name or 0 */
tree fndecl)
{
+ struct cgraph_local_info *i = fndecl ? cgraph_local_info (fndecl) : NULL;
memset (cum, 0, sizeof (*cum));
/* Set up the number of registers to use for passing arguments. */
*** init_cumulative_args (CUMULATIVE_ARGS *c
*** 3442,3447
--- 3460,3474
cum-mmx_nregs = MMX_REGPARM_MAX;
cum-warn_sse = true;
cum-warn_mmx = true;
+
+ /* Because type might mismatch in between caller and callee, we need to
+ use actual type of function for local calls.
+ FIXME: cgraph_analyze can be told to actually record if function uses
+ va_start so for local functions maybe_vaarg can be made aggressive
+ helping KR code.
+ FIXME: once typesytem is fixed, we won't need this code anymore. */
+ if (i i-local)
+ fntype = TREE_TYPE (fndecl);
cum-maybe_vaarg = (fntype
? (!prototype_p (fntype) || stdarg_p (fntype))
: !libname);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #5 from debian-gcc at lists dot debian dot org 2008-01-27 19:27 --- the fix was checked in on the trunk only; please reopen the report -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:39 --- Subject: Bug 34990 Author: jvdelisle Date: Sun Jan 27 19:38:59 2008 New Revision: 131890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131890 Log: 2008-01-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/34990 * array.c (gfc_check_constructor_type): Revert clearing the expression. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug c++/26099] support for type traits is not available
--- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-27 19:54 --- (In reply to comment #17) Hi Kaveh. One problem I can see is that we are dealing with special member functions, like constructors and assignment operators Ah, I guess you can't make those static. Can you see anything wrong with the straightforward implementation of idea per the attached patchlet? If it looks ok to you, it would be matter of doing the same for the other 2 files... It looks like you reversed the checks for the problematic cases when you see __PIC__. I wonder whether this will work on darwin which still binds locally for pic code. http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00495.html The regtester might barf on this change, I don't have darwin to check. If it does, maybe instead you simply nuke the problematic cases when you see __PIC__. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:56 --- Fixed on trunk -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:33 --- I get no regressions with the fix in comment #2. I will just commit it as obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #10 from bero at arklinux dot org 2008-01-27 19:36 --- this should make lot of difference on KR code (I wonder if any is still around in usual distro) Some parts of xorg still follow KR conventions, few parts of teTeX have KR code in them, cdrtools is fully KR (I fixed that in the dvdrtools fork, not sure if any of the other cdrtools forks in circulation copied that) -- other than that, I'm not aware of any commonly used KR bits and pieces in a modern system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug fortran/34990] [4.3 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:842
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-27 19:51 --- Subject: Bug 34990 Author: jvdelisle Date: Sun Jan 27 19:50:16 2008 New Revision: 131891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131891 Log: 2008-01-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/34990 * gfortran.dg/array_constructor_22.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_22.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
[Bug c++/26099] support for type traits is not available
--- Comment #19 from ghazi at gcc dot gnu dot org 2008-01-27 20:09 --- (In reply to comment #18) If it does, maybe instead you simply nuke the problematic cases when you see __PIC__. Another option that might work is to add -fpie when we see __PIC__. That should work on darwin etc as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #20 from pcarlini at suse dot de 2008-01-27 20:40 --- Hi Kaveh. I just checked darwin and indeed, we have an issue there, which, AFAICS, is not worked around with -fpie. I say, let's just skip the test when __PIC__ is defined, and be done with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #22 from pcarlini at suse dot de 2008-01-27 20:49 --- Created an attachment (id=15031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15031action=view) New draft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #21 from pcarlini at suse dot de 2008-01-27 20:47 --- Since you are already set for this extended kind of testing, can you run the new patch? Thanks a lot in advance! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #23 from ghazi at gcc dot gnu dot org 2008-01-27 21:09 --- (In reply to comment #20) Hi Kaveh. I just checked darwin and indeed, we have an issue there, which, AFAICS, is not worked around with -fpie. Hmm, did you mean darwin failed with (your patch + -fpie) or just with -fpie and the original tests? I meant for just using -fpie on darwin with no other changes. I have tested a patch that fixes the tests on x86-linux-gnu using -fpie. If it works on darwin, then great. Otherwise I'll go with your option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #24 from ghazi at gcc dot gnu dot org 2008-01-27 21:10 ---
Patch which works on i686-unknown-linux-gnu:
2008-01-27 Kaveh R. Ghazi [EMAIL PROTECTED]
* g++.dg/ext/has_nothrow_assign.C: Add -fpie when __PIC__.
* g++.dg/ext/has_nothrow_constructor.C: Likewise.
* g++.dg/ext/has_nothrow_copy.C: Likewise.
diff -rup orig/egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_assign.C
egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_assign.C
--- orig/egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_assign.C
2007-12-31 19:13:13.0 +0100
+++ egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_assign.C
2008-01-27 21:17:32.0 +0100
@@ -1,4 +1,5 @@
// { dg-do run }
+// { dg-options -fpie { target { ! nonpic } } }
#include cassert
struct A
diff -rup
orig/egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_constructor.C
egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_const
ructor.C
--- orig/egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_constructor.C
2007-12-31 19:13:14.0 +0100
+++ egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_constructor.C
2008-01-27 21:17:48.0 +0100
@@ -1,4 +1,5 @@
// { dg-do run }
+// { dg-options -fpie { target { ! nonpic } } }
#include cassert
struct A
diff -rup orig/egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_copy.C
egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_copy.C
--- orig/egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_copy.C
2007-12-31 19:13:14.0 +0100
+++ egcc-SVN20080126/gcc/testsuite/g++.dg/ext/has_nothrow_copy.C
2008-01-27 21:17:54.0 +0100
@@ -1,4 +1,5 @@
// { dg-do run }
+// { dg-options -fpie { target { ! nonpic } } }
#include cassert
struct A
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 21:32 --- Right, sorry. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug c++/26099] support for type traits is not available
--- Comment #25 from ghazi at gcc dot gnu dot org 2008-01-27 21:17 --- (In reply to comment #22) Created an attachment (id=15031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15031action=view) [edit] New draft I tried your latest draft and it fails for has_nothrow_assign.C because of a typo. The third #ifndef has no macro so I get: has_nothrow_assign.C:149: error: no macro name given in #ifndef directive When I fix that it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #26 from pcarlini at suse dot de 2008-01-27 21:35 --- (In reply to comment #23) I meant for just using -fpie on darwin with no other changes. The problem I see, on darwin, is that -fpie cannot be passed to the driver, because eventually, the linker rejects -pie. Is that a know issue, dealt with automatically by the testing infrastructure? In that case, your patch is great, otherwise, or if things are going to be tricky, I say let's just go with mine (sorry about the typo) and spare time for something else ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #27 from ghazi at gcc dot gnu dot org 2008-01-27 22:03 ---
(In reply to comment #26)
(In reply to comment #23)
I meant for just using -fpie on darwin with no other changes.
The problem I see, on darwin, is that -fpie cannot be passed to the driver,
because eventually, the linker rejects -pie. Is that a know issue, dealt with
automatically by the testing infrastructure? In that case, your patch is
great,
Hmm, there are a couple of other tests using -fpie on darwin:
./g++.dg/parse/attr-externally-visible-1.C:/* { dg-options -O3 -fwhole-program
-fpie { target *-*-darwin* } } */
./g++.dg/other/first-global.C:/* { dg-options -fpie { target *-*-darwin* } }
*/
./gcc.dg/pie-link.c:/* { dg-options -fpie } */
On closer inspection, the first two are compile-only, so the linker isn't
invoked. The latter is only run on darwin[912], which I assume means darwin9
or later (10, 11, 12, 20, 21, 22, ...).
otherwise, or if things are going to be tricky, I say let's just go with mine
(sorry about the typo) and spare time for something else ;)
So I guess you're using an older version of darwin that doesn't know about pie.
In that case I guess your patch (with the typo fixed) is the best option.
Will you be installing it?
Thanks,
--Kaveh
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #28 from pcarlini at suse dot de 2008-01-27 22:27 --- (In reply to comment #27) So I guess you're using an older version of darwin that doesn't know about pie. I'm testing on Darwin 8.11, that is the last Tiger, still pretty common... In that case I guess your patch (with the typo fixed) is the best option. Will you be installing it? Sure. Many thanks for your help! Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug fortran/34975] [4.3 Regression] Bogus error with USEing modules
--- Comment #7 from pault at gcc dot gnu dot org 2008-01-27 22:27 --- Created an attachment (id=15033) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15033action=view) A patch for this regression I have just put this on to bootstrap and regtest whilst I sleep. Since it changes nothing in the basic mechanism I believe that it will be OK. In fact, I already tested gfortran.dg/use*.f90 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34975
[Bug c++/34992] New: compiler produces wrong code when optimizing
Hello, for some time now I had problems with one of my projects with compilers gcc 4.2.1 and above. For obscure reasons my testsuite did not run correctly when I did compile with optimization enabled. I now tracked the problem down to a very strange bug that I can reproduce with a test case that I will attach. The problem I encounter is the fact that inserting duplicated values into a std::set will end up with a set holding these values more than once. This happens only with optimization enabled. I was able to prevent the problem in the test case by means of just moving the function that would create the error further away from the position where the function is called. In the test case the offset is created by means of another function that is not used, and that can be removed from the object file by means of compiler macros. If the unused function is part of the object file, then the std::set manipulation runs fine, if the function is disabled and removed from the object file the manipulation of the std::set fails. The function is inserted into the object file by means of defining the precompiler macro MAKEOFFSET. Kind regards, -- Summary: compiler produces wrong code when optimizing Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roebel at ircam dot fr 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=34992
[Bug c++/34992] compiler produces wrong code when optimizing
--- Comment #1 from roebel at ircam dot fr 2008-01-27 22:55 --- Created an attachment (id=15034) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15034action=view) source file for reproducing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug c++/34992] compiler produces wrong code when optimizing
--- Comment #2 from roebel at ircam dot fr 2008-01-27 22:57 --- Created an attachment (id=15035) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15035action=view) script to compile the source and reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug c++/34992] compiler produces wrong code when optimizing
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-27 22:58 --- Since you are doing some = for fp, does -ffloat-store help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug middle-end/34992] compiler produces wrong code when optimizing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug middle-end/34992] compiler produces wrong code when optimizing
--- Comment #4 from roebel at ircam dot fr 2008-01-27 23:05 --- yes indeed, that fixes the problem. now, does that mean holding double values in a set is not possible? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug c/34993] New: [4.1/4.2/4.3 regression] ICE with attribute for array with unknown bound
The following valid code snippet triggers an ICE since GCC 4.0.0: typedef int x[] __attribute((may_alias)); bug.c:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] The crash happens with the C and C++ frontend. -- Summary: [4.1/4.2/4.3 regression] ICE with attribute for array with unknown bound Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34993
[Bug c/34993] [4.1/4.2/4.3 regression] ICE with attribute for array with unknown bound
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34993
[Bug middle-end/34992] compiler produces wrong code when optimizing
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-27 23:17 --- Even though -mfpmath=sse is used, x87 is used in some cases still and what you are seeing is an effect of PR 323. Closing as a duplicate. You should be more careful with your comparison loop of FP values. *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #102 from pinskia at gcc dot gnu dot org 2008-01-27 23:17 --- *** Bug 34992 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||roebel at ircam dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/34994] New: gfortran.dg/missing_optional_dummy_5.f90 doesn't work
On Linux/Intel64 with revision 131893, I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../ /export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/missing_optional_dummy_5.f90 -O -fdump-tree-original -S -m32 -o missing_optional_dummy_5.s(timeout = 300) PASS: gfortran.dg/missing_optional_dummy_5.f90 -O (test for excess errors) FAIL: gfortran.dg/missing_optional_dummy_5.f90 -O scan-tree-dump original tm_doit \(parm.7, 0B, 0\); -- Summary: gfortran.dg/missing_optional_dummy_5.f90 doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34994
[Bug middle-end/34992] compiler produces wrong code when optimizing
--- Comment #6 from roebel at ircam dot fr 2008-01-28 00:14 ---
Andrew,
while -ffloat-store fixes the problem, this solution is obviously not
acceptable. Moreover, here the problem is not that I compare floats
using = the problem is that std::setdouble::insert(double) compares
set elements using std::lessdouble which in this case just does not work.
Now using std::lessdouble for a set does not seem not carefull
to me, be cause this is the default. So the default is nonsense ?
I fixed the problem by means of using std::setdouble,dless
with dless being
struct dless{
typedef double first_argument_type;
typedef double second_argument_type;
typedef bool result_type;
volatile double d1;
volatile double d2;
bool operator()(double in1, double in2) {
d1 = in1;
d2 = in2;
return d1 d2;
}
};
which proves that the problem is in the std::less operator
and not in my code. In fact this even means that
std::lessdouble and std::greaterdouble and all
their company is useless because you can never be sure what they
are comparing. So many of the functions of the std::library
may fail!! Am I wrong, here ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug fortran/34994] gfortran.dg/missing_optional_dummy_5.f90 doesn't work
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-28 00:17 ---
With -m32, we got
doit ()
{
real(kind=4) doit1[2];
{
struct array1_real(kind=4) parm.6;
parm.6.dtype = 281;
parm.6.dim[0].lbound = 1;
parm.6.dim[0].ubound = 2;
parm.6.dim[0].stride = 1;
parm.6.data = (void *) doit1[0];
parm.6.offset = -1;
tm_doit (parm.6, 0B, 0);
}
goto __return_doit;
__return_doit:;
}
instead of
doit ()
{
real(kind=4) doit1[2];
{
struct array1_real(kind=4) parm.7;
parm.7.dtype = 281;
parm.7.dim[0].lbound = 1;
parm.7.dim[0].ubound = 2;
parm.7.dim[0].stride = 1;
parm.7.data = (void *) doit1[0];
parm.7.offset = -1;
tm_doit (parm.7, 0B, 0);
}
goto __return_doit;
__return_doit:;
}
with -m64. But we only expect tm_doit \\(parm.7, 0B, 0\\);.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34994
[Bug c++/34747] __attribute__((aligned(x)))+__alignof != correct behaviour
--- Comment #3 from andry at inbox dot ru 2008-01-28 01:16 --- I build trunk (2008.01.27) and run test. Several tests still failing: FAILED: test5 FAILED: test7 FAILED: test20 FAILED: test21 FAILED: test25 FAILED: test26 FAILED: test37 FAILED: test46 FAILED: test47 FAILED: test48 10 tests failed! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34747
[Bug middle-end/34992] compiler produces wrong code when optimizing
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-28 01:18 --- (In reply to comment #6) Am I wrong, here ? Semi, what is happening is the values for std::lessdouble is being stored in the fpr register and that is really a 80bit register and not a 64bit fp register. -mpc64 is another fix for the issue, but that only exists on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug fortran/34994] gfortran.dg/missing_optional_dummy_5.f90 doesn't work
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-28 02:09 --- Subject: Bug 34994 Author: jvdelisle Date: Mon Jan 28 02:09:07 2008 New Revision: 131898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131898 Log: 2008-01-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/34994 * gfortran.dg/missing_optional_dummy_5.f90: Fix matching regular expression. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34994
[Bug fortran/34994] gfortran.dg/missing_optional_dummy_5.f90 doesn't work
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-28 02:11 --- Fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34994
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #27 from jason at gcc dot gnu dot org 2008-01-28 02:20 --- Subject: Bug 27177 Author: jason Date: Mon Jan 28 02:19:38 2008 New Revision: 131899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131899 Log: PR c++/27177 * class.c (build_base_path): Fix previous change. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #28 from jason at gcc dot gnu dot org 2008-01-28 02:20 --- Really fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/34158] Template delete doesn't call if exception thrown in constructor
--- Comment #1 from andry at inbox dot ru 2008-01-28 02:46 --- In gcc 4.3 (trunk, 2008.01.27), bug still doesn't fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #7 from ian at airs dot com 2008-01-28 04:12 --- Created an attachment (id=15036) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15036action=view) DECL_NO_TBAA patch With regard to comment #3, I just bootstrapped and tested this patch on i686-pc-linux-gnu. Any opinions on whether this should go into 4.3? It seems to me that it should, to avoid any problems with inlining operator new. I believe this patch is safe, but I don't have a test case which it fixes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
