[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 11:07 ---
Whoops. Yeah, I only added x86_64-*-* to the vect_perm targets. Obviously,
as sse2 is active by default for the vectorizer testsuite I also need to
add the i?86-*-* targets. H.J., can you try with this patch on a native system
(so that we may see any possible fallout)?
Index: testsuite/lib/target-supports.exp
===
--- testsuite/lib/target-supports.exp (revision 164367)
+++ testsuite/lib/target-supports.exp (working copy)
@@ -2426,6 +2426,7 @@ proc check_effective_target_vect_perm {
set et_vect_perm_saved 0
if { [istarget powerpc*-*-*]
|| [istarget spu-*-*]
+|| [istarget i?86-*-*]
|| [istarget x86_64-*-*] } {
set et_vect_perm_saved 1
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug tree-optimization/45733] [4.6 Regression] ICE: verify_stmts failed: invalid conversion in gimple call with -fstrict-overflow -ftree-vectorize
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 13:17 --- Yeah, probably some fold_convert is missing in reverse_vec_elements() in case the type of the args or the return type of the chosen builtin decl don't exactly match. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45733
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-09-20 14:12 --- Subject: Bug 45706 Author: matz Date: Mon Sep 20 14:12:04 2010 New Revision: 164433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164433 Log: PR testsuite/45706 * lib/target-supports.exp (check_effective_target_vect_perm): Add i?86-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug testsuite/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-20 14:14 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|middle-end |testsuite Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug testsuite/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-20 14:45 --- Subject: Bug 45706 Author: matz Date: Mon Sep 20 14:45:30 2010 New Revision: 164435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164435 Log: PR testsuite/45706 * gcc.dg/vect/pr43432.c: Don't override dg-options, defaults are enough. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr43432.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug tree-optimization/43432] Missed vectorization: complicated access pattern for increasing and decreasing data indexing
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-17 13:26 --- Subject: Bug 43432 Author: matz Date: Fri Sep 17 13:26:43 2010 New Revision: 164367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164367 Log: PR tree-optimization/43432 * tree-vect-data-refs.c (vect_analyze_data_ref_access): Accept backwards consecutive accesses. (vect_create_data_ref_ptr): If step is negative generate decreasing IVs. * tree-vect-stmts.c (vectorizable_store): Reject negative steps. (perm_mask_for_reverse, reverse_vec_elements): New functions. (vectorizable_load): Handle loads with negative steps when easily possible. testsuite/ PR tree-optimization/43432 * lib/target-supports.exp (check_effective_target_vect_perm_byte, check_effective_target_vect_perm_short): New predicates. (check_effective_target_vect_perm): Include x86_64. * gcc.dg/vect/pr43432.c: New test. * gcc.dg/vect/vect-114.c: Adjust. * gcc.dg/vect/vect-15.c: Ditto. * gcc.dg/vect/slp-perm-8.c: Use new predicate. * gcc.dg/vect/slp-perm-9.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/vect/pr43432.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/slp-perm-8.c trunk/gcc/testsuite/gcc.dg/vect/slp-perm-9.c trunk/gcc/testsuite/gcc.dg/vect/vect-114.c trunk/gcc/testsuite/gcc.dg/vect/vect-15.c trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432
[Bug rtl-optimization/45685] [4.6 Regression] GCC optimizer for Intel x64 generates inefficient code
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-17 13:45 --- It might have been exposed by that revision, but that merely points out a deficiency in RTL if conversion. The final gimple code doesn't have explicit jumps in the inner loop, but uses cond_expr: bb 3: # s_22 = PHI 0(2), s_30(3) # i_19 = PHI 0(2), i_31(3) D.2693_11 = MEM[base: products_9(D), index: i_19, step: 8, offset: 0B]; val_4 = [cond_expr] D.2693_11 = 0 ? -1 : 1; prephitmp.9_39 = [cond_expr] D.2693_11 = 0 ? -1 : 1; prephitmp.10_40 = [cond_expr] D.2693_11 = 0 ? 1 : -1; prephitmp.11_41 = [cond_expr] D.2693_11 = 0 ? 1 : -1; D.2698_21 = D.2693_11 * prephitmp.9_39; D.2699_25 = (long unsigned int) D.2698_21; val_3 = [cond_expr] i_19 != D.2699_25 ? prephitmp.10_40 : val_4; prephitmp.11_43 = [cond_expr] i_19 != D.2699_25 ? prephitmp.11_41 : prephitmp.9_39; MEM[base: products_9(D), index: i_19, step: 8, offset: 0B] = prephitmp.11_43; s_30 = val_3 + s_22; i_31 = i_19 + 1; if (i_31 != count_7(D)) goto bb 3; else goto bb 4; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #1 from matz at gcc dot gnu dot org 2010-09-17 16:12 --- This passes for me, even in -m32 mode (if -msse is added, like vect.exp does): % ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \ vect-114.c -ftree-vectorizer-verbose=2 21 | grep note: vect-114.c:13: note: LOOP VECTORIZED. vect-114.c:6: note: vectorized 1 loops in function. -- matz at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.6 regression]|[4.6 regression] |gcc.dg/vect/vect-114.c |gcc.dg/vect/vect-114.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug tree-optimization/45656] [4.5 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-13 14:21 --- Uh, I just disabled tree-sinking in some cases. This can't be directly the reason for the problem, rather it must have uncovered a latent problem. Will try to investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45656
[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-08 12:35 --- Subject: Bug 33244 Author: matz Date: Wed Sep 8 12:34:52 2010 New Revision: 163998 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163998 Log: PR tree-optimization/33244 * tree-ssa-sink.c (statement_sink_location): Don't sink into empty loop latches. testsuite/ PR tree-optimization/33244 * gfortran.dg/vect/fast-math-vect-8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sink.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33244
[Bug tree-optimization/43430] Missed vectorization: stmt not supported: cond_expr
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-08 12:40 --- Subject: Bug 43430 Author: matz Date: Wed Sep 8 12:40:24 2010 New Revision: 163999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163999 Log: PR tree-optimization/43430 * tree-vect-stmts.c (vectorizable_condition): Support multiple copies for conditional statements if it's not part of a reduction. testsuite/ PR tree-optimization/43430 * gcc.dg/vect/pr43430-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr43430-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
[Bug tree-optimization/43430] Missed vectorization: stmt not supported: cond_expr
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-07 13:24 --- The remaining problem is the support for ncopies 1 in vectorizable_condition. http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00550.html implements this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
[Bug tree-optimization/43432] Missed vectorization: complicated access pattern for increasing and decreasing data indexing
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-07 13:27 --- The patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00548.html implements support for consecutive loads with negative step. It will vectorize the first testcase. But not the second one because it only handled loads, not stores. -- matz at gcc dot gnu dot org changed: What|Removed |Added Summary|Missed vectorization: |Missed vectorization: |complicated access pattern|complicated access pattern |for increasing and |for increasing and |decreasing data indexing|decreasing data indexing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432
[Bug tree-optimization/43434] Missed vectorization: not vectorized: data ref analysis: pointer incremented by a parameter
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-07 13:42 --- Since Ira implemented unaligned support in SLP mode we get somewhat further, but not much. If complete unrolling is active that we can't disambiguate between *s and *(s+stride). That is correct because stride is unknown and might be 8. The problem is the code generated by unrolling looks like so: b_1[0] = s1_2[0]... b_1[1] = s1_2[1]... ... b_3 = b_1 + 8; s1_4 = s1_2 + stride; b_3[0] = s1_4[0]... b_3[1] = s1_4[1]... Now SLP checks for dependencies between the first block of access and those in the second block. Although this is really uninteresting for SLP, nevertheless it prevents SLPing here because the dependencies can't be computed. Deactivating loop-unrolling reveals another problem, namely that SLP doesn't support multiple types at all, see vect_build_slp_tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434
[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-07 14:41 --- Since the fix for PR44710 we can if-convert the conditions in the inner loop. With http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00542.html we also make sure that the latch block isn't filled, which in turn then triggers the if-conversion. This then reveals the rest of the problems, which are: * inlining needs to happen (our default parameters don't inline ginteg) The patch above ensures this by making the functions internal * a library with vectorized logf needs to be available (libacml_mv for instance) The patch above works around this by getting rid of calls to log/sqrt * loop interchange needs to happen, because in the original testcase we have: do i=0,Ng1 do j=0,Ng2 G(i,j) = ... exactly the wrong way around. Our loop-interchange code is only capable of vectorizing perfect nests, which here doesn't exist as LIM and PRE move out some loop invariant expressions from the inner to the outer loop. If we weren't doing that, that itself would already prevent vectorization. The patch above works around this by doing the interchange by hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33244
[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-03 14:43 --- Subject: Bug 45415 Author: matz Date: Fri Sep 3 14:42:46 2010 New Revision: 163822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163822 Log: PR middle-end/45415 * tree-sra.c (sra_modify_assign): If we modify the statement, say so. * tree-ssa.c (verify_ssa): Check number of operands and links per statement to agree. testsuite/ PR middle-end/45415 * gcc.dg/pr45415.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45415.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45415
[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-03 14:46 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45415
[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-02 12:58 --- Mine. I'm adding some checking code too. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-08-26 14:19:59 |2010-09-02 12:58:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45415
[Bug ada/45499] New: Ada bootstrap broken
r163773 doesn't want to bootstrap with Ada because of dependency problems.
I think I've tracked it down to ultimately '-I-' not working as described.
The symptom during make is while building gnattools in gcc/ada/tools:
error: make.adb must be recompiled (a-except.ads has been modified)
error: ali.adb must be recompiled (a-except.ads has been modified)
error: output.adb must be recompiled (a-except.ads has been modified)
(and many more about a-except.ads being out-of-date)
This is because there are conflicting entries for a-except.ads (and for Richi
also a-strunb.ads) in the different .ali files. In a-except.ali:
D a-except.ads 20090806060045 34786013
But for instance in make.ali:
D a-except.ads 20090419230738 d4161513
Clearly two different files. This is because compiling a-except.adb uses
the file from ../rts/a-except.ads which in turn is a symlink to
a-except-2005.ads. But compiling make.adb from the same directory uses
not that symlink but the copy in $srcdir/ada/a-except.ads. Can be easily
seen with strace. From inside the builddir:
% cd gcc/ada/tools
% strace ../../gnat1 -I- -I ../rts -I . \
-I /matz/gcc/svn/real-trunk/gcc/gcc/ada -gnatwa -dumpbase \ a-except.adb
-auxbase-strip \ a-except.o -O2 -O1 -Wextra -Wall -Wwrite-strings
-Wstrict-prototypes \
-Wmissing-prototypes -fno-inline -fno-toplevel-reorder -g -gnatpg -gnata \
-g -mtune=generic -march=x86-64 -gnatO a-except.o ../rts/a-except.adb 21 |
grep a-except.ads
stat(../rts/a-except.ads, {st_mode=S_IFREG|0644, st_size=17275, ...}) = 0
stat(../rts/a-except.ads, {st_mode=S_IFREG|0644, st_size=17275, ...}) = 0
open(../rts/a-except.ads, O_RDONLY) = 4
% ls -l ../rts/a-except.ads
lrwxrwxrwx 1 matz suse 54 2010-09-02 15:20 ../rts/a-except.ads -
/matz/gcc/svn/real-trunk/gcc/gcc/ada/a-except-2005.ads
whereas:
% ../../gnat1 -I- -I../rts -I . -I /matz/gcc/svn/real-trunk/gcc/gcc/ada \
-gnatwa -quiet -dumpbase make.adb -auxbase-strip \ make.o -O2 -Wextra -Wall
-Wwrite-strings -Wstrict-prototypes \
-Wmissing-prototypes -g -gnatpg -gnata -mtune=generic -march=x86-64 -gnatO \
make.o /matz/gcc/svn/real-trunk/gcc/gcc/ada/make.adb -o bla.s 21 | grep
a-except.ads
stat(/matz/gcc/svn/real-trunk/gcc/gcc/ada/a-except.ads,
{st_mode=S_IFREG|0644, st_size=15580, ...}) = 0
stat(/matz/gcc/svn/real-trunk/gcc/gcc/ada/a-except.ads,
{st_mode=S_IFREG|0644, st_size=15580, ...}) = 0
open(/matz/gcc/svn/real-trunk/gcc/gcc/ada/a-except.ads, O_RDONLY) = 4
So, when compiling make.adb it uses the a-except.ads file from the sourcedir
of make.adb.
This is contrary to the documentation of '-I-' which is used here for a reason
I guess.
--
Summary: Ada bootstrap broken
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45499
[Bug c/45289] gcc lacks a posix option for -std since POSIX 2008 defines special behavior
--- Comment #5 from matz at gcc dot gnu dot org 2010-08-15 21:07 --- First, yes, the work-around from the official POSIX man-pages is alias-unsafe. They added this example because ISO C doesn't allow conversion of void* pointers to function pointer, but dlsym returns a void* pointer. There are two possibilities to use dlsym: 1) ptrtofntype f = (ptrtofntype) dlsym (...); 2) *(void**)f = dlsym (...); The former is invalid ISO C (conversion between void* and function pointer not allowed), the latter is invalid ISO C (alias violation). So they were between a rock and a hard place, the dlsym interface was impossible to use with a strict ISO C compiler when it was used to get at addresses of functions. That's why they added language to POSIX 2008 to make conversions between void* and function-pointer types valid. They could have added a new interface in parallel to dlsym that would return a function pointer from the start. Well, they chose to add a new requirement for POSIX systems making variant (1) valid. GCC, at least on POSIX systems, should reflect this, and also make this conversion valid. In fact we're already doing the right thing for such conversions, so we only need to specify that this isn't going to change in the future and disable the warning even in pedantic mode. That means we wouldn't be a strict ISO compiler in this mode anymore. It's what happen when there are two standards in conflict with each other. I think that by default, even with -pedantic, we should not warn for the void* - fnptr conversion (note that POSIX only specifically allows the conversion from/to void*, not to any arbitrary data pointer type). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289
[Bug c/45289] gcc lacks a posix option for -std since POSIX 2008 defines special behavior
--- Comment #8 from matz at gcc dot gnu dot org 2010-08-16 00:55 --- Well, okay, (3) indeed is valid ISO C (no warning) and works on POSIX 2008. I'd find it very awkward to write such work-around for (1) just so the warning in strict ISO C mode is silenced. I find this case different from other cases where such warnings about standard violations are explicitely wanted even though perhaps the code happens to work. I think it's different from those cases because POSIX (mostly concerned with portability) is a standard too, one that we'd probably like to adhere to on some systems. Hence, I still would suggest to not warn about solution (1), even in ISO C mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #35 from matz at gcc dot gnu dot org 2010-08-13 13:00 --- char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #36 from matz at gcc dot gnu dot org 2010-08-13 13:14 --- If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset was unclear to you to expect that abs20==seg16*16+ofs16? The prohibitive expensive referred to the necessary lookup of the base in the LDT/GDT that would have been required for every far pointer subtraction. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Did I say that? Let's see: size limitation of ptrdiff_t that was 16bit. Nope. I didn't. The point being that if ptrdiff_t is only 16 bit, then no matter how fantastically capable the compiler was in emitting 32bit arithmetic, the result of subtracting to char pointers pointing more than 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t. No, not me, I don't want to write nonsense on the web, Maybe you don't necessarily want to. But ... , well, there we are. I prefer to be clear headed. One never knows when stuff one wrote on the net will come back and bite one in the ass!! I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Much better than Pizarro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #41 from matz at gcc dot gnu dot org 2010-08-13 15:18 --- You should really adjust your glasses if you want to continue trolling with the high standards we're used to meanwhile: What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset So, I think it's pretty clear that I'm referring to the 80286, whereas you cite something ... From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left ... about the 8086. To make it very obvious, even to you: 86 vs 286. As you have so huge experiences with such old processors, I'm sure you can guess what I meant with real segmentation aka protected mode now. In case you still can't and because we seem to start using wikipedia to back up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation . Now, implement a routine that subtracts two pointer for this memory model. You'll see that it requires bit-magic on the segment selector, lookup in the GDT or LDT and finally some 24bit arithmetic to produce the result. The arithmetic is of course trivial, the lookup is expensive. Doing it for every pointer subtract was what I called prohibitive expensive for a normal pointer subtraction. That, together with the fact that all segments are max 2^16 in size, and that it's impossible to map back all 24bit numbers into segmented addresses without generally adding new entries into the GDT/LDT made it useless to have pointer differences any larger than 16 bit, not impossible but useless in real compilers. Therefore the result of such a subtraction isn't always representable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #42 from matz at gcc dot gnu dot org 2010-08-13 15:25 --- [ ] Yes [x] No Thanks. The comunity will be alerted to this. I'll get back to you when your name is in some famous place associated with this claim. That's very good. Though I'm a bit confused because you only wanted to post my name everywhere if I got the answer wrong. Now, it's very obvious that my answer is the only correct one. Well, nevertheless I'm looking forward to become famous. Thanks for your help in that, though I fear somebody else will become even more famous than me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #51 from matz at gcc dot gnu dot org 2010-08-14 01:26 --- There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism Thank you, that's encouraging, I just hope the language of that article won't be changed too much to also mention everyone else who has a clue. Because, you see, I'm of course very excited about me being famous now and about being the only one who knows the truth, but OTOH I fear there were some other clever people that happen to agree with me, and I now see a real danger of those replacing me in that wikipedia article. Even worse would be that the list of names would be too large to mention in wikipedia and that the list would be replaced by some more unspecific phrases like people who actually understood the standard or the like. The comunity has been warned about GCC. Which community? Rogerio-cdecl church followers? In that case I'm happy, because I'll expect less bug-reports from supporters of that specific religion. I'll continue to feel sorry for them (especially because I've learned over the conversation that you might actually influence new programmers, which is a terrible thing to do for you) but am not particularly looking forward to seeing misguided and crippled attempts of creating meagre imitations of stumbling pseudo bug-reports, especially because we can have the best there is: Rilhas bugs! If, OTOH, you mean a different community, like for instance that consisting of people who actually write C source code, I don't see any warning about using GCC for them. If anything, it's more like an invitation to use GCC for developing because it's more standard compliant than other compilers. It was a good day's work after all. You mean writing down incoherent brain-dumps? Uhm, well, if that's all your day-work is about... more power to you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #10 from matz at gcc dot gnu dot org 2010-08-12 16:00 --- Ahh, it's just so entertaining. C99 is a language, cdecl a calling convention. There is no 'cdecl compiler', it makes no sense to speak about such a thing. cdecl is a calling convention for function written in all kinds of languages. If you chose to program in C (and you claim you do), then you have to work by the rules the relevant language standard imposes on you. It has been shown multiple times to you (and you even agree), that what you do is outside of C99. Countering this with but it should still work, because 'cdecl' says so is invalid reasoning, a calling convention can't override any limitation the language standard imposes. What you want to program in is not C99 (or any C whatsoever), but rather Microsofts idea of what a language looking similar to C might look like-C. GCC makes no claim to support such language. It supports C99, and it supports the cdecl calling convention. It does not support the language that you think is C, but isn't. It might be conceivable that somebody implements a new language frontend for GCC that would support the Microsoft language without name, as long as that isn't the case (and you yourself aren't interested in developing such frontend) the bug reports remain invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #27 from matz at gcc dot gnu dot org 2010-08-12 18:05 --- Oh, this fun. Enjoyable, really! ;-) So, you admit that MSVC does in fact miscompile your perfectly fine cdecl code, if you request optimization from it? How bad is that of them? Terrible! I would consider creating a bug report with them, because if they miscompile your code with optimizations it must surely be their bug. After all optimization is a process of transforming a valid program into another program that behaves exactly the same, hence if they optimize your valid program into a crasher, what else could it be than a bug in their compiler? I mean, really. They are supposed to provide a commercial grade compiler. How can it be that they force you to deactivate optimization options (and hence live with slow runtime) just so that your valid cdecl program doesn't crash? One side remark about your p2-p1 claim: char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. You obviously never used segmented platforms (old DOS was such a thing, but there are others more recent, e.g. Cell with PowerPC is similar in this respect). On those it was valid only to sunstract pointers from each other when they pointed into the same segment. Because the pointer difference type was a 16 bit type, whereas the pointers could address 1MB of memory (hence effectively 20 bit). If you do the math you'll see that it's impossible to map all 2^20 possible differences between pointers (unsigned 2-completement 20-bit arithmetic, otherwise 2^21 differences) into just 16 bit. So yes, on those platforms it really was impossible to substract two arbitrary pointers. C (the language) reflects such constraints. With complete trust in your incapability to grok these concepts. but hats off to a capable troll, Michael. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #33 from matz at gcc dot gnu dot org 2010-08-12 18:56 --- Don't talk about what you don't know, you clearly know much less about the old days than me. Well, I'll grant you that you know many wondrous and astounding facts, indeed. Let me just answer one random sentence out of your answer, just to keep it funny: Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. They didn't. If you subtracted far pointers that pointed into different segment, the segment difference was ignored. If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. And of course the subtraction of addresses of parameter is always meaningless in C, segmented or not, as pointed out multiple times. With or without cdecl. Or, another one: No, optimizations take away room for assumptions. Um, huh? That's completely backwards. Optimizations make _use_ of the assumptions/guarantees that the relevant standard gives you. Drink something with vitamins and get out more, it will do you good. That is certainly a good advise. I OTOH would advise you to possibly drink more alcohol. Much more. Really much much more. Go and read C99 about the far qualifier so that you can see why it was not smart of you to talk about DOS. C99 doesn't mention such qualifiers. I said that the restrictions in the standard (in this case which pointers can be compared/subtracted) have their reason in wanting to support all imaginable memory models. Nevertheless those restriction apply to _all_ implementations, even those that have trivial memory models, like a flat address space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
A conforming variant of what you probably are trying to code is:
#include stdio.h
#include stdarg.h
void format_indirect(char* dst_buffer, size_t dst_buffer_size_bytes,
const char *format, va_list va)
{
vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va);
dst_buffer[dst_buffer_size_bytes-1]=0;
}
void format_direct(char* dst_buffer, size_t dst_buffer_size_bytes,
const char* format, ...)
{
va_list va;
va_start (va, format);
format_indirect(dst_buffer, dst_buffer_size_bytes, format, va);
va_end (va);
}
int main(void)
{
char buffer[1000];
format_direct((char*)buffer, sizeof(buffer), %s %s, __DATE__, __TIME__);
printf(Result: \%s\\n, buffer);
return 0;
}
---
Note how the va_list is constructed in the function that actually is
a varargs one, in particular how the necessary parameter is mentioned.
Note further how that va_list is passsed to the function that is not
varargs in order to capture all variable arguments of its caller.
There, no assumption on stack-layout. It will work with all types and
ABIs, even those that happen to pass even some varargs in registers,
not on the stack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution
--- Comment #9 from matz at gcc dot gnu dot org 2010-07-26 15:06 ---
Here's a testcase (nicer in the sense of not requiring inlining) that shows
the current compiler botching the nrv - retslot optimizations:
struct S {int x, y, makemelarge[5];};
S __attribute__((noinline)) f (S s) {
S r;
r.x = s.y;
r.y = s.x;
return r;
}
int __attribute__((noinline)) glob (int a, int b)
{
S local = { a, b };
local = f (local);
return local.y;
}
extern C void abort (void);
int main (void)
{
if (glob (1, 3) != 1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43784
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- Comment #25 from matz at gcc dot gnu dot org 2010-07-07 11:15 --- Due to SSA form the alias information reflects dependencies only between accesses as if it ignores back edges. Hence any transformation that transforms a back edge into a forward edge, or moves code over back edges needs to do adjustment to the alias info (effectively doing something like PHI translation, or making the alias info simply more imprecise). Hmpf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- Comment #29 from matz at gcc dot gnu dot org 2010-07-07 12:10 --- [just for completeness to not lose the thought:] Thinking about this some more (triggered by the problem of not having nice back edges in irreducible loops), it's not really the back edges that are interesting but the underlying property of SSA, namely the correspondence between static single assignments and dynamic single assignments: The alias oracle will give correct answers only for memory references when it can infer runtime equality of values from syntactic equality, which it can for a correct SSA program. So, if M1 and M2 (two memrefs) contain mentions of syntactically the same values, then A1/A2 (two accesses to M1/M2) have to be dominated by the dynamically same definitions of those values. For SSA form that's trivially true, for RTL of course it isn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #16 from matz at gcc dot gnu dot org 2010-06-30 16:34 --- Subject: Bug 44699 Author: matz Date: Wed Jun 30 16:34:22 2010 New Revision: 161614 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161614 Log: PR bootstrap/44699 * tree-vrp.c (vrp_finalize): Deal with changing num_ssa_names. * gimple-fold.c (gimplify_and_update_call_from_tree): If LHS is a gimple reg, attach the original VDEF to the last store in the sequence. testsuite/ PR bootstrap/44699 * gcc.dg/pr44699.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr44699.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-30 16:54 --- Testcases are fixed. And according to http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03137.html we can probably also assume the bootstrap fail is fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #3 from matz at gcc dot gnu dot org 2010-06-29 11:31 --- Can you perhaps run the testsuite without bootstrapping (configure --disable-bootstrap; make; make check) to see if there occurs some more obvious bug than a miscompilation of genmodes? Debugging bootstrap miscompilations via bugzilla is difficult. The miscompile might be in bitmap_clear, perhaps there's something obvious, but a breaking testcase is much easier. (I do wonder though why the miscompile happens on darwin but not linux, even though the architecture is the same) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-29 13:47 --- Is /opt/gcc/gcc4.6bw/bin/gcc a bootstrapped compiler or one created without bootstrapping? The initial comment didn't reveal it, so maybe my assumption that it's a miscompiled cc1 is wrong. So, just to be crystal clear in the initial comment, the segfaulting compiler, is that the stage1 or the stage2 compiler? (you can check for the existence of stage1-gcc directory in the build-dir when the segfault happens, if there's such a directory then prev-gcc/xgcc is the stage2 compiler). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #9 from matz at gcc dot gnu dot org 2010-06-29 14:48 --- Yes, but I'm asking if it was a bootstrapped compiler (in difference to one built with configuring with --disable-bootstrap) or not. If it was a bootstrapped compiler, are you saying that bootstrap fails with r161501 (initial comment), but works when using r161462 plus patch of 161496? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #11 from matz at gcc dot gnu dot org 2010-06-29 15:15 --- I can reproduce now. It's also the non-bootstrapped compiler failing with the testcase, thanks for that. I'm on it. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 15:15:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug middle-end/44592] [4.5/4.6 Regression] wrong code at -O3
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-28 15:14 --- Subject: Bug 44592 Author: matz Date: Mon Jun 28 15:14:31 2010 New Revision: 161496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161496 Log: PR middle-end/44592 * gimple-fold.c (gimplify_and_update_call_from_tree): Maintain proper VDEF chain for intermediate stores in the sequence. testsuite/ PR middle-end/44592 * gfortran.dg/pr44592.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr44592.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug middle-end/44592] [4.5 Regression] wrong code at -O3
--- Comment #6 from matz at gcc dot gnu dot org 2010-06-28 15:16 --- Fixed for 4.6, waiting a bit for 4.5. -- matz at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression] wrong |[4.5 Regression] wrong code |code at -O3 |at -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug middle-end/44592] [4.5/4.6 Regression] wrong code at -O3
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-25 15:34 --- Indeed. Mine. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-24 21:58:27 |2010-06-25 15:34:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug target/44575] [4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location
--- Comment #2 from matz at gcc dot gnu dot org 2010-06-18 15:58 ---
It's not SSA expand (might be exposed by it, don't know), but the
bug is pre-existing already in 4.3:
long unsigned int D.2219;
struct S116 va_arg_tmp.3;
...
addr.0 = va_arg_tmp.3;
addr.4 = (long unsigned int *) addr.0;
sse_addr.5 = (long unsigned int *) sse_addr.2;
D.2214 = *sse_addr.5;
*addr.4 = D.2214;
addr.6 = (long unsigned int *) addr.0;
D.2216 = addr.6 + 8;
sse_addr.7 = (long unsigned int *) sse_addr.2;
D.2218 = sse_addr.7 + 16;
D.2219 = *D.2218;
*D.2216 = D.2219;
Here the second store is also a 8-byte store at offset 8 of a struct only
12 bytes long. The problem is in ix86_gimplify_va_arg (and friends).
For the type in question (struct S116), we build this classes[] array:
(gdb) p regclass
$47 = {X86_64_SSE_CLASS, X86_64_SSE_CLASS, ...
That's okay, for such structs we really need two words, and both are passed
in registers (if available). But the construct_container constructs this
container:
(gdb) p debug_rtx(container)
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 21 xmm0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DI 22 xmm1)
(const_int 8 [0x8]))
])
So, we try to move the content at offset 0 in DImode (the register itself
will be irrelevant here, as we're needing a temporary), which is still fine.
But the register of slot 1 also has DImode, for moving the values at offset
8. This mode will be used to determine the type of the move instruction
generated, and is the one where things become wrong. See the loop in
ix86_gimplify_va_arg, starting here:
for (i = 0; i XVECLEN (container, 0); i++)
{
...
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #1 from matz at gcc dot gnu dot org 2010-06-15 11:19 --- We have a slightly problematic ordering issue here. Here's what I think should be made the case: DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that. (and for calculating offsets from stack-ptr we can calculate the alignment directly) If that were the case already we wouldn't have the problem of having to maintain DECL_ALIGN. Of course the problem is, that MEM_ALIGN is actually generated from DECL_ALIGN during expansion itself. It follows that it actually wouldn't help at all to fixup only DECL_ALIGN after the final stack alignment is known. We would also have to walk all RTL and fixup MEM_ALIGN too (in possibly non-obvious ways). If we wouldn't do that but start with minimal DECL_ALIGN we have only managed to produce very suboptimal code. On some architecture even so unoptimal as to use unaligned instructions were aligned ones would be possible. And we wouldn't necessarily be able to fixup _that_ after the fact. Now, the mentioned ordering problem is, that we align the stack only after all instructions are converted (and hence all stack-vars are expanded). We can't do it before, because the necessity for stack-alignment depends on the actually emitted stack-vars. And doing it afterwards will lead to the need for walking all instructions again, fixing DECL_ALIGN and MEM_ALIGN (and changing instructions to use more optimal versions of the alignment now is somehow better). I think the only correct way is for expand_stack_alignment to align the stack exactly so that all DECL_ALIGN and MEM_ALIGN entries are correct. In other words I think it would be a bug for expand_stack_alignment to generate an actual stack alignment that would lessen the alignment of stack vars. To that effect I think I'd rather want to see a reproducer for 4.5/4.6 and fix the bug in expand_stack_alignment (possibly in the target hooks) than trying to fiddle with the insn chain. Weren't there some DRAP fixes after 4.4? I seem to remember some patches flying by at that time-frame. Perhaps you can also create a reproducer for 4.5 just before expand-from-ssa? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-15 13:40 --- Can you try to instead do the stack-estimation only when really_expand is false? The issue is, we see all variables (or we _should_ see) exactly twice, once for estimation, once for generating the DECL_RTL. The code was so twisted that I didn't want to touch it too much during expand-from-ssa, but I planned to return to that somewhen, hence I'm not sure if we really see each variable only twice. But we should be working towards that goal. In any case it should be fine to track crtl-stack_alignment_estimated only in the first pass (really_expand == false), and never touch it again in the second pass (really_expand == true). Then you should also be able to simplify the condition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-15 13:50 --- Oh, and yes, I agree that in expand_one_stack_var_at (only called when really_expand == true) we should limit align to $something. I'm just not sure what $something is. crtl-stack_alignment_estimated is not really it, because that one itself is adjusted by expand_stack_alignment (running after all expansion). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-15 14:56 --- Jakub was not talking about crtl-stack_alignment_estimated becoming 256, but rather DECL_ALIGN of certain decls in expand_one_stack_var_at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- Comment #12 from matz at gcc dot gnu dot org 2010-06-10 12:26 --- I don't think it ever was intended that 'm' includes operands with embedded side-effects. I don't think so because making this work reliably is relatively difficult. In particular the tests that Jakub mentions would need implementation (and probably other changes too), and the point is that such things never were implemented. Hence with enough work it's probably possible to construct testcases also for much older versions of GCC that fail in similar ways. If that means to slightly change the definition of 'm' compared to what is documented currently, well, so be it. The other definition is unreliable anyway, so any inline asm that uses 'm' and expects a side-effect is fishy at best. It is fishy because if the compiler forwards a side-effect into the operands it would have to rewrite the inline asm string to actually contain an instruction to calculate this side-effect, which obviously is bollocks. So, yes, auto-inc-dec should of course _not_ push side-effects into inline asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-10 13:34 --- m is defined to be the most general memory constraint, and a pre/post modified memory operand is still a memory operand. I know that this is the case, which is why I said: If that means to slightly change the definition of 'm' compared to what is documented currently, well, so be it. I.e. I'm arguing that the documentation should be amended to state something that can actually be implemented in a reliable way. I.e. include without side-effects at the appropriate place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug tree-optimization/43984] PRE misses full-redundancies, inserts into loops
--- Comment #9 from matz at gcc dot gnu dot org 2010-05-06 13:55 --- Subject: Bug 43984 Author: matz Date: Thu May 6 13:54:32 2010 New Revision: 159106 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159106 Log: PR tree-optimization/43984 * tree-ssa-pre.c (inserted_phi_names): Remove. (inserted_exprs): Change to bitmap. (create_expression_by_pieces): Set bits, don't append to vector. (insert_into_preds_of_block): Don't handle inserted_phi_names. (eliminate): Don't look at inserted_phi_names, remove deleted insns from inserted_exprs. (remove_dead_inserted_code): Adjust to use bitmaps instead of vectors. (init_pre, fini_pre): Allocate and free bitmaps. (execute_pre): Insert insns on edges before elimination. testsuite/ * gfortran.dg/pr43984.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr43984.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
[Bug tree-optimization/43984] PRE misses full-redundancies, inserts into loops
--- Comment #4 from matz at gcc dot gnu dot org 2010-05-05 12:35 --- Ah, another case of a patch I held back for 4.6 to open, and then forgetting about it :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
[Bug tree-optimization/43984] PRE misses full-redundancies, inserts into loops
--- Comment #6 from matz at gcc dot gnu dot org 2010-05-05 13:32 --- PRE seems to have done this since forever. All edge inserts are delayed if the _immediate forms aren't used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
[Bug middle-end/43835] New: IPA-SRA doesn't rewrite attributes
The testcase I'm attaching shortly will be miscompiled by IPA-SRA. The problem is, that SRA splits the pointer argument 'c' of mark_cell into two new parameters, one being a pointer itself, and another int param. But it doesn't rewrite the attribute list of the fndecl, hence the nonnull attributes now apply to the new parameters. That's of course bogus and results in a null-pointer check (on c-p) being optimized out by VRP later. This happens with simply -O2 (on i686 and x86_64, but it's a generic problem). -- Summary: IPA-SRA doesn't rewrite attributes Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: i686-linux GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug middle-end/43835] IPA-SRA doesn't rewrite attributes
--- Comment #1 from matz at gcc dot gnu dot org 2010-04-21 15:08 --- Created an attachment (id=20454) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20454action=view) testcase # gcc -O2 sra-nonnull.c ./a.out Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug tree-optimization/42963] [4.5/4.6 Regression] Redundant switch labels not cleaned up anymore
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-14 14:51 --- Subject: Bug 42963 Author: matz Date: Wed Apr 14 14:50:33 2010 New Revision: 158345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158345 Log: PR tree-optimization/42963 * tree-cfg.c (touched_switch_bbs): New static variable. (group_case_labels_stmt): New function broken out from ... (group_case_labels): ... here, use the above. (start_recording_case_labels): Allocate touched_switch_bbs. (end_recording_case_labels): Deallocate it, call group_case_labels_stmt. (gimple_redirect_edge_and_branch): Remember index of affected BB. testsuite/ * testsuite/gcc.dg/pr42963.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr42963.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug tree-optimization/42963] [4.5 Regression] Redundant switch labels not cleaned up anymore
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-14 14:53 --- Fixed for 4.6. I propose to WONTFIX this for 4.5. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to work|4.4.3 |4.4.3 4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] Redundant |Redundant switch labels not |switch labels not cleaned up |cleaned up anymore |anymore Target Milestone|4.5.1 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #4 from matz at gcc dot gnu dot org 2010-04-13 11:59 --- No, we shouldn't unconditionally create REGs if the target isn't one, but rather only if it doesn't match the predicate. Like so, which I'm testing right now: Index: builtins.c === --- builtins.c (revision 158160) +++ builtins.c (working copy) @@ -2316,7 +2316,8 @@ expand_builtin_interclass_mathfn (tree e tree orig_arg = arg; /* Make a suitable register to place result in. */ if (!target - || GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp))) + || GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp)) + || !insn_data[icode].operand[0].predicate (target, GET_MODE (target))) target = gen_reg_rtx (TYPE_MODE (TREE_TYPE (exp))); gcc_assert (insn_data[icode].operand[0].predicate -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-12 18:38:24 |2010-04-13 11:59:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-13 13:35 --- Subject: Bug 43730 Author: matz Date: Tue Apr 13 13:35:30 2010 New Revision: 158268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158268 Log: PR middle-end/43730 * builtins.c (expand_builtin_interclass_mathfn): Also create a register if the predicate doesn't match. testsuite/ * gcc.dg/pr43730.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr43730.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-13 13:47 --- Subject: Bug 43730 Author: matz Date: Tue Apr 13 13:47:11 2010 New Revision: 158270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158270 Log: PR middle-end/43730 * builtins.c (expand_builtin_interclass_mathfn): Also create a register if the predicate doesn't match. testsuite/ * gcc.dg/pr43730.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43730.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/builtins.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-13 13:54 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug target/43671] [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-08 13:40 --- Um, how can r138953 be the reason when (as the original report says) it's still okay with r153685? In any case, my patch just shuffled around the activation/non-activation of the scheduler, so if at all it exposed a latent bug in it, which given that -fsched2-use-superblocks isn't used by default is very likely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43671
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #19 from matz at gcc dot gnu dot org 2010-04-08 14:50 --- This seems rather like a hack for our not-so-capable loop unroller. The estimator already correctly knows that much of it will be optimized away, hence it would make more sense for the code emitter to also not emit useless things that the estimator already knows will be optimized away. It seems backward to have an additional limit on compile time/memory need for a transformation that we know will succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #28 from matz at gcc dot gnu dot org 2010-04-06 10:34 --- I don't think we should fix the double-accounting bug for the 4.5 series, when we tried it on SPEC it caused several regression, meaning we would need much more fine-tuning. We have time for that for 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #33 from matz at gcc dot gnu dot org 2010-04-06 11:09 --- Steven, please note that this PR was proposed WONTFIX for 4.5 already in comment #15. The discussion after that was about something that is only slightly related to this bug, something that wouldn't actually affect this very bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #14 from matz at gcc dot gnu dot org 2010-03-23 16:16 --- Simply replace the recursive call to expand_expr_real_1 with a call to expand_expr_real. That's the wrapper setting locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #18 from matz at gcc dot gnu dot org 2010-03-23 16:46 --- It should mostly not matter anymore as expand_expr_real_[12] and friends use an explicit location parameter, stored away before expanding operands. But to be safe, yes, expand_expr_real() should instead also restore the old location. You don't need to check for NULL gimple_block(), set_curr_insn_block does that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-22 11:57 --- optimize_reg_copy_3 misses to replace in notes. Mine. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-03-22 11:11:38 |2010-03-22 11:57:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43475
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #9 from matz at gcc dot gnu dot org 2010-03-22 16:01 --- For sched-deps.c there are two calls to cselib_lookup: 1) in sched_analize_1 (for writing to MEM) 2) in sched_analize_2 (for reading a MEM) Regarding (2): cselib_lookup is called on a copy of X (made into T) which then is replaced into XEXP(t,0). But for debug-insn that very T isn't used at all further down. So we can disregard the use at (2) (and move the whole manipulation of T into the !DEBUG_INSN_P block). Regarding (1): Here we don't handle debug-insns specially, but sched_analize_1 is called only on PRE/POST_DEC/INC/MODIFY, top-level SET/CLOBBER insns (maybe in a PARALLEL) or CLOBBERS in CALL_INSN_FUNCTION_USAGE. It better should be true that debug-insn don't contain a PRE/POST_DEC/INC/MODIFY side-effect, or a top-level SET/CLOBBER. IOW sched_analyze_1 never should be called on debug-insns. So we can disregard case (1) too. Next: if the cselib_lookup calls (that always have their 'create' argument be true) ever create a new VALUE for a MEM in a debug-insn, that same wouldn't happen without debug-insn, or in different order. I think this would lead to debug-miscompare later down anyway. So, I think any calls into cselib on debug-insns that happen to create new values are actually bugs waiting to be discovered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-22 16:29 --- Subject: Bug 43475 Author: matz Date: Mon Mar 22 16:28:51 2010 New Revision: 157640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157640 Log: PR middle-end/43475 * recog.c (validate_replace_rtx_group): Replace also in REG_EQUAL and REG_EQUIV notes. testsuite/ * gfortran.dg/pr43475.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr43475.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43475
[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-22 16:30 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43475
[Bug c++/43333] [4.5 Regression] __is_pod seems broken
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-22 16:34 --- Re comment #6: well, then we still need to fix the c++98 case. Re comment #7: note carefully how I have avoided is_pod in the testcase, but instead used the internal mean to implement the former. That's the regression I'm interested about. (well, to tell the truth I would also consider it a regression of is_pod, if not by the letter of the standard, then as quality of implementation, because we _do_ have compiler support) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/43333] [4.5 Regression] __is_pod seems broken
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-22 16:54 --- Hmm, well, but there's code out there that expects the old TR1 semantic, namely blocxx, and if the definition is indeed muddled than IMNSHO we should retain the behaviour as it was in older GCC versions, instead of breaking existing code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-20 17:00 --- But Simons patch was accepted. Simon: can you simply combine the two testcases into one? No need to artificially lengthen the time for make check. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org AssignedTo|matz at gcc dot gnu dot org |simartin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43081
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 --- Subject: Bug 43305 Author: matz Date: Fri Mar 19 12:37:28 2010 New Revision: 157567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157567 Log: PR 43305 * builtins.c (expand_builtin_interclass_mathfn, expand_builtin_signbit): Use maybe_emit_unop_insn, emit libcalls if that fails. testsuite/ * gcc.dg/pr43305.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43305.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug c++/43116] [4.3/4.4/4.5 Regression] ICE when using attributes in a function alias declaration
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-18 23:25:51 |2010-03-19 15:33:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-23 01:50:47 |2010-03-19 16:18:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43081
[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 --- I'm not sure what you're asking. When the unpatched compiler the testcase (with the printf or the x!=6-abort) will ICE with a checking compiler, and produce wrong output (0 or an abort) with a nonchecking compiler. With a patched compiler the printf testcase will print 6, and the abort testcase will not abort. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug c++/43116] [4.3/4.4/4.5 Regression] ICE when using attributes in a function alias declaration
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-19 16:37 --- Subject: Bug 43116 Author: matz Date: Fri Mar 19 16:37:27 2010 New Revision: 157578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157578 Log: PR c++/43116 * attribs.c (decl_attributes): When rebuilding a function pointer type use the same qualifiers as the original pointer type. testsuite/ * g++.dg/other/pr43116.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/other/pr43116.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug c++/43116] [4.3/4.4 Regression] ICE when using attributes in a function alias declaration
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:40 --- Fixed for 4.5. Unassigning myself. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to fail|4.5.0 4.2.3 4.3.2 |4.2.3 4.3.2 Known to work|4.1.3 |4.1.3 4.5.0 Summary|[4.3/4.4/4.5 Regression] ICE|[4.3/4.4 Regression] ICE |when using attributes in a |when using attributes in a |function alias declaration |function alias declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug tree-optimization/42963] [4.5 Regression] Redundant switch labels not cleaned up anymore
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-19 16:55 --- Actually I have a patch for this, need to polish it somewhat. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-05 10:15:46 |2010-03-19 16:55:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:59 --- How about not calling cselib_process_insn on DEBUG_INSNs (or better make cselib_process_insn ignore them). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-18 12:21 --- Subject: Bug 43402 Author: matz Date: Thu Mar 18 12:20:50 2010 New Revision: 157538 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157538 Log: PR tree-optimization/43402 * tree-cfgcleanup.c (cleanup_control_expr_graph): Don't follow PHI chains of ssa names registered for update. testsuite/ * gcc.dg/pr43402.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43402.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-18 12:46 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-18 14:35 --- Mine. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-18 14:35:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-18 14:48 --- I checked, and these and similar transformations are always guarded by flag_unsafe_math_optimizations, so we should be fine, unless I missed a case of course. If you notice one, please create a bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:08 --- Subject: Bug 43419 Author: matz Date: Thu Mar 18 16:07:53 2010 New Revision: 157543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157543 Log: PR middle-end/43419 * builtins.c (expand_builtin_pow): Don't transform pow(x, 0.5) into sqrt(x) if we need to preserve signed zeros. testsuite/ * gcc.dg/pr43419.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43419.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:47 --- Mine. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-03-09 15:49:38 |2010-03-18 16:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-18 16:47 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-18 16:53 --- That would indeed be my preferred approach. The alternative would be to add much if (x == error_mark_node) sillyness all over the middle-end, like the front-ends do. The middle-end should be able to rightfully expect to be fed only at least basically valid trees. This could possibly also be done in the gimplifier (just don't emit a statement if some operands smell bad). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug tree-optimization/43402] New: dom1 miscompiles binary search
This actually happens in libicu, preventing genbrk (and hence openoffice and texlive) to work. # gcc -O1 icubug.c ./a.out Aborted With -O0 it works. The wrong transformation is done by dom1, it transforms the loop into a linear sequence without backedges. bb 2: goto bb 8; bb 3: # start_16 = PHI mid_25(5), start_21(8) # limit_19 = PHI limit_22(5), mid_25(8) # lastMid_15 = PHI mid_25(5), mid_25(8) bb 4: # start_1 = PHI start_16(3) # limit_2 = PHI limit_19(3) # lastMid_3 = PHI mid_25(3) D.2744_9 = start_1 + limit_2; mid_10 = D.2744_9 / 2; goto bb 7; bb 5: if (result_14 0) goto bb 3; else goto bb 6; bb 6: D.2754_17 = cnvNameType[mid_25].type; D.2753_18 = converterData[D.2754_17]; bb 7: # D.2753_4 = PHI D.2753_18(6), 0B(4) return D.2753_4; bb 8: # start_21 = PHI 0(2) # limit_22 = PHI 3(2) # lastMid_23 = PHI 4294967295(2) D.2744_24 = start_21 + limit_22; mid_25 = D.2744_24 / 2; D.2746_12 = cnvNameType[mid_25].name; result_14 = __builtin_strcmp (realName_13(D), D.2746_12); if (result_14 0) goto bb 3; else goto bb 5; -- Summary: dom1 miscompiles binary search Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] dom1 miscompiles binary search
--- Comment #1 from matz at gcc dot gnu dot org 2010-03-17 14:02 --- Created an attachment (id=20127) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20127action=view) testcase Testcase reduced from ucnv_bld.c of libicu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-17 15:31 ---
It seems the jump threading somehow confuses cfgcleanup. Right after the
jumps are threaded (in tree_ssa_dominator_optimize after the call to
thread_through_all_blocks) the function looks like so:
bb 2:
goto bb 9;
bb 3:
# start_16 = PHI mid_10(6), start_1(10)
# limit_19 = PHI limit_2(6), mid_10(10)
# lastMid_15 = PHI mid_10(6), mid_10(10)
bb 4:
# start_1 = PHI start_16(3)
# limit_2 = PHI limit_19(3)
# lastMid_3 = PHI mid_10(3)
D.2744_9 = start_1 + limit_2;
mid_10 = D.2744_9 / 2;
if (lastMid_3 == mid_10)
goto bb 8;
else
goto bb 5;
bb 6:
if (result_14 0)
goto bb 3;
else
goto bb 7;
bb 7:
D.2754_17 = cnvNameType[mid_10].type;
D.2753_18 = converterData[D.2754_17];
bb 8:
# D.2753_4 = PHI D.2753_18(7), 0B(4)
return D.2753_4;
bb 9:
# start_21 = PHI 0(2)
# limit_22 = PHI 3(2)
# lastMid_23 = PHI 4294967295(2)
D.2744_24 = start_1 + limit_2;
mid_25 = D.2744_9 / 2;
goto bb 10;
bb 5:
bb 10:
D.2746_12 = cnvNameType[mid_10].name;
result_14 = __builtin_strcmp (realName_13(D), D.2746_12);
if (result_14 0)
goto bb 3;
else
goto bb 6;
At that point the PHI nodes for BB 10 are still missing, and we have
registered these ssaname updates:
start_21 - { start_1 }
limit_22 - { limit_2 }
lastMid_23 - { lastMid_3 }
D.2744_24 - { D.2744_9 }
mid_25 - { mid_10 }
With the right PHI nodes at bb 10 the code still looks good. But somehow
cfgcleanup scrambles the whole thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-17 15:36 --- Um, we cleanup the CFG before updating SSA form, hence no wonder that the missing PHI nodes confuse it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-17 15:49 --- Hmm, create_edge_and_update_destination_phis is supposed to add new PHI arguments for the ultimate threading destination. But it only does so if there are already PHI nodes in that BB. We need to create new ones, which is difficult as we would have to create a new SSA name to hold the result, and rewrite all dominating uses. I wonder how this all is supposed to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-17 16:05 --- Hmm, I wonder how that could cause the bug. Probably because we can't rely on SSA form being uptodate during cfgcleanup, and hence looking up PHI arguments is wrong, at least for those SSA names that are registered for updating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #9 from matz at gcc dot gnu dot org 2010-03-17 17:03 --- http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00774.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug middle-end/43300] [4.5 Regression] ICE: in emit_move_insn, at expr.c:3432
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-15 16:13 --- Subject: Bug 43300 Author: matz Date: Mon Mar 15 16:13:28 2010 New Revision: 157461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157461 Log: PR middle-end/43300 * tree-outof-ssa.c (emit_partition_copy): New argument sizeexp, use it to expand block copies. (insert_partition_copy_on_edge, insert_rtx_to_part_on_edge, insert_part_to_rtx_on_edge): Adjust callers of emit_partition_copy. (insert_value_copy_on_edge): Use store_expr for BLKmode values. testsuite/ * gcc.dg/pr43300.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43300.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-outof-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43300
[Bug middle-end/43300] [4.5 Regression] ICE: in emit_move_insn, at expr.c:3432
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-15 16:15 --- Fixed. I put in a testcase that doesn't need graphite. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43300
[Bug c++/43333] New: __is_pod seems broken
On r157245 (and former revisions) this testcase will abort:
# cat ispod.cc
struct strPOD
{
const char *const foo;
const char *const bar;
};
extern C void abort (void);
int main ()
{
if (!__is_pod (strPOD))
abort ();
return 0;
}
This manifests itself in blocxx not compiling with gcc 4.5 (due to its use
of tr1::is_pod implemented in terms of above). It still works with a random
gcc 4.3 version.
--
Summary: __is_pod seems broken
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
