[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-04
08:46:30 UTC ---
(In reply to comment #3)
Or at least the other compilers and the other gfortran modes did not need to
break these tricks yet.
The issue is essentially that GCC will optimize in
subroutine iei4ei(inpu,oupu)
inte(:) = inpu(:)
oupu(4) = inte(1)
oupu(3) = inte(2)
oupu(2) = inte(3)
oupu(1) = inte(4)
the inte away, which is perfectly valid as inpu and outu may not point to
the same memory.
To be more precise (cf. -fdump-tree-optimized), instead of (-O0):
MEM[(c_char * {ref-all})inte] = MEM[(c_char * {ref-all})inpu_1(D)];
D.1820_2 = inte[0];
*oupu_3(D)[3] = D.1820_2;
...
the compiler generates (-O2, -O3):
inte$0_14 = MEM[(c_char * {ref-all})inpu_1(D)];
inte$1_15 = MEM[(c_char * {ref-all})inpu_1(D) + 1B];
...
*oupu_3(D)[3] = inte$0_14;
...
and depending on the assembler generation (order, register usage), this will
work or not. Seemingly, on i386 the generated assembler will break your program
while it happens to work on x86-64.
This optimization is perfectly valid according the Fortran standard and speeds
valid programs. I am sure that other compilers do the same, though whether it
will break your program depends on the generated assembler code. I wouldn't be
surprised if the program also breaks with other compilers with some compiler
flag or a slightly different compiler version.
This breakage happens in principle for all optimization levels (-O1, -O2,
...). However, if iei8ei/iei4ei and program gfortran_debug are in the
same file, inlining and other optimizations happen such that the program
happens to work by chance for -O2/-O3.
Work-around solutions: Use -O0 or make inte VOLATILE. [The program is then
still formally wrong, but should work.]
The better change is to change the call to:
call iei4ei((in4),in4)
call iei8ei((in8),in8)
That will force the generation of a temporary variable in the caller, which
makes this part of the program valid. (You still have the issue of passing an
INTEGER(4) to an INTEGER(1) and misuse of EQUIVALENCE.)
(The () seems to be enough to fix the program; I don't know why it didn't
seem to fix the issue when I wrote comment 1.)
Alternatively, you can add to both arguments of iei4ei and iei8ei the
TARGET attribute - in that case the compiler knows that the arguments may be
storage associated each other. However, Fortran then requires an explicit
interface. (This will be difficult as you pass an integer(kind=4) to an
integer(kind=1), which is invalid.)
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2012-01-04 09:32:28 UTC --- On Tue, 3 Jan 2012, hubicka at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-03 18:06:28 UTC --- Hmm, adding CONST_DECLs into varpool would be fun: we would have to ensure that most of target machinery is ready to output CONST_DECLs promoted to hidden vars by ltrans partitioning + there will be some additional surprises for sure (i.e. CONST_DECLs being constructed very late in optimization). The problem is not specific to ipa-cp, ale ipa-split and inlining can migrate same CONST_DECL across function bodies that can end up in different ltrans partitions. I wonder if we should not simply promote CONST_DECLs into initialized const vars for this purpose by local tree pass running just before early inliner? I don't see much of downsides of this transform at them moment, except for lack of sharing of const pool in between early and late const decls. The problem is we do not have CONST_DECLs at all at the moment but we have ADDR_EXPRs of STRING_CSTs. I think we should simply ignore this PR for 4.7 and work on it in the 4.8 timeframe (making the FEs to emit CONST_DECL instead of STRING_CST, how we deal with them wrt the varpool is a completely different issue). Richard.
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383 --- Comment #17 from rguenther at suse dot de rguenther at suse dot de 2012-01-04 09:43:13 UTC --- On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383 --- Comment #16 from davidxl xinliangli at gmail dot com 2012-01-04 00:28:55 UTC --- A related topic - aliasing property of realloc -- the malloc attribute is not applied in the glibc header and the comment is like /* __attribute_malloc__ is not used, because if realloc returns the same pointer that was passed to it, aliasing needs to be allowed between objects pointed by the old and new pointers. * It is true that the realloc can return an address is physically aliased with the pointer passed to it -- but assuming no-alias by the compiler should cause no harm -- as all code motions/CSEs across the realloc call will not be possible because realloc may modify/use the memory location. Any comment on this? The malloc attribute assumes that the contents of the memory pointed to by the return value is undefined, so the comment is inaccurate but the malloc attribute can indeed be not used. We can explicitly handle REALLOC in the points-to code to honor the fact that it is not (we do not at the moment).
[Bug tree-optimization/49651] [4.4/4.5 Regression] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 09:47:18 UTC --- Author: rguenth Date: Wed Jan 4 09:47:12 2012 New Revision: 182865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182865 Log: 2012-01-04 Richard Guenther rguent...@suse.de PR tree-optimization/49651 * tree-ssa-structalias.c (type_can_have_subvars): New function. (var_can_have_subvars): Use it. (get_constraint_for_1): Only consider subfields if there can be any. * gcc.dg/tree-ssa/pta-ptrarith-1.c: Adjust. * gcc.dg/tree-ssa/pta-ptrarith-2.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-2.c trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/49651] [4.4/4.5 Regression] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 09:50:18 UTC --- Author: rguenth Date: Wed Jan 4 09:50:13 2012 New Revision: 182866 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182866 Log: 2012-01-04 Richard Guenther rguent...@suse.de PR tree-optimization/49651 * tree-ssa-structalias.c (type_can_have_subvars): New function. (var_can_have_subvars): Use it. (get_constraint_for_1): Only consider subfields if there can be any. * gcc.dg/tree-ssa/pta-ptrarith-1.c: Adjust. * gcc.dg/tree-ssa/pta-ptrarith-2.c: Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-2.c branches/gcc-4_6-branch/gcc/tree-ssa-structalias.c
[Bug libstdc++/51749] New: Including algorithm pollute global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
Bug #: 51749
Summary: Including algorithm pollute global namespace
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nospam.kotarou.d...@gmail.com
Created attachment 26235
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26235
Preprocessed file
Including the header file algorithm on Linux seems to pollute the global
namespace. I discovered this while attempting to put sys/select.h in a
namespace. A quick example is given below:
test.cpp:
#include algorithm
fd_set set; // Should not compile
int main() { return 0; }
Compiles with: g++ test.cpp -o test
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/kotarou3/usr/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../mingw/gcc-src/configure
--prefix=/home/kotarou3/work/gcc-build/../gcc
--with-gmp=/home/kotarou3/work/gcc-build/../mingw/gmp
--with-mpfr=/home/kotarou3/work/gcc-build/../mingw/mpfr
--with-mpc=/home/kotarou3/work/gcc-build/../mingw/mpc --enable-languages=c,c++
--disable-win32-registry --enable-checking=release --enable-shared
Thread model: posix
gcc version 4.7.0 20111231 (experimental) (GCC)
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-04 10:11:29 UTC --- Closing.
[Bug libstdc++/51749] Including algorithm pollute global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 10:16:56 UTC --- bits/stl_algo.h ends up including cstdlib.
[Bug tree-optimization/51528] [4.6/4.7 Regression] SRA should not create BOOLEAN_TYPE replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51528 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.3
[Bug preprocessor/51745] Strange symbol appears when using commandline definition without =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51745 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-04 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 10:21:49 UTC --- Strangely ICC agrees with GCC here (hopefully using its own preprocessor ;)) So, confirmed, but maybe invalid.
[Bug libstdc++/51749] Including algorithm pollute global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-04 10:25:45 UTC --- Thus I understand you are new to GCC, because the problem was already there in, eg, gcc3, and very likely the original HP/SGI STL! It's because of the use of rand(), or a similar system function, which requires including cstdlib. Note, all of this is in general allowed by the standard: including a c* header as an implementation detail, and cstdlib specifically including stdlib.h as an implementation detail. The latter unfortunately on these particular systems also provides 'set'. In principle we could handle this specific manifestation of the annoyance by eg, adding to the compiler a __builtin_rand, but it's too late for 4.7, or by exporting from the .so some __rand function. The latter idea doesn't sound too bad to me, wasn't done in the original HP/SGI code because it didn't come with any .src files. Anyway, beware that many more of these issues are lurking around, we don't control the underlying libc and the stuff its headers provide in the global namespace, sooner or later you may find unexpected names in it.
[Bug fortran/46356] [OOP] Erroneous procedure/intent error and ICE for class dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-04 10:25:53 UTC --- (In reply to comment #4) the reduced one of comment 2 still fails with: internal compiler error: in gfc_conv_descriptor_offset, at fortran/trans-array.c:210 The same error message one gets with Andrew Benson's code, cf. http://gcc.gnu.org/ml/fortran/2012-01/msg00028.html
[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, lto Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-04 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 10:31:09 UTC --- I think this is a linker bug, GCC optimizes away the function (seeing that the argument is _not_ zero), but the linker warns about it anyway and it is still output for some reason: 72: 004006f0 2 FUNCGLOBAL HIDDEN15 __warn_memset_zero_le n resolution file: 2 ma2.o 4 84 cd7721f0 PREVAILING_DEF_IRONLY ma_init 95 cd7721f0 PREVAILING_DEF_IRONLY ma_pool 105 cd7721f0 PREVAILING_DEF_IRONLY ma_get_cell 124 cd7721f0 RESOLVED_EXEC __warn_memset_zero_len ma2_test.o 4 86 64da28d6 PREVAILING_DEF main 108 64da28d6 RESOLVED_IR ma_get_cell 113 64da28d6 RESOLVED_IR ma_pool 117 64da28d6 RESOLVED_IR ma_init
[Bug target/51743] [ia64] Many gcc.dg/torture/vshuf*.c tests FAIL with -O2 -mbig-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51743 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 10:34:43 UTC --- (In reply to comment #2) Uh... can you even force ia64-linux to run in big-endian mode? Just because you said -mbig-endian doesn't mean it is. I don't see anything in the linux kernel that allows per-process endian switching. Hm, should we then reject this switch on linux? Do these same failures appear for ia64-hpux?
[Bug bootstrap/51742] 4.6.2 v. HP-UX 11.11, PA-RISC: make bootstrap-lean fails: internal compiler error: Segmentation fault (In function '__fixunssfdi')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51742 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-04 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 10:36:03 UTC --- This is the first time the stage1 compiler is used which means it doesn't work at all. Please use gdb to debug it and see why it segfaults.
[Bug debug/51746] Segfault in cselib_preserved_value_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51746
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04
10:40:35 UTC ---
Looks latent before to me.
The issue is that when cselib_process_insn for
(insn 56 51 60 4 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem:QI (plus:SI (reg:SI 1 r1 [orig:169 ivtmp.6 ] [169])
(const_int -1 [0x])) [0 MEM[base: 0B,
index: ivtmp.6_13, offset: 4294967295B]+0 S1 A8])
(reg:QI 2 r2 [176]))) pr51746.i:16 3031 {*p *arm_movqi_insn}
(nil))
is called, initially when doing cselib_lookup on the r1 - 1, we get value
18:18,
but still during processing of that insn htab_expand is called on the cselib
hash table, as it reached the 3/4 fullness limit. After this expand we don't
find VALUE 18:18 for r1 - 1 anymore and instead create VALUE 27:8168 (8168 is
the hash value of r1 - 1 at that point). But that means cselib_lookup on
(mem:QI (value 27:8168)) in add_stores fails, because the desired value that
was created earlier on for (mem:QI (r1 - 1)) is in value 18:18's addr_list, not
in 27:8168's addr_list and add_stores calls cselib_lookup with create=0.
It seems most of the places in var-tracking.c that call cselib_lookup with
create=0 allow it to return NULL, but not this spot. So the easiest fix is
just handle the oval == NULL case. And we can think about some improvements if
it would be possible to improve this case somehow. E.g. if cselib_find_slot
in cselib_lookup_1 succeeeds, but returns a value with e-hash != hash, perhaps
we could insert a cselib_val with the desired hash and make it
cselib_add_permanent_equiv to the actual value found? Perhaps not 4.7
material...
[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51746 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-04 Target Milestone|--- |4.7.0 Summary|Segfault in |[4.7 Regression] Segfault |cselib_preserved_value_p|in cselib_preserved_value_p Ever Confirmed|0 |1
[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51746 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 10:46:39 UTC --- Created attachment 26236 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26236 gcc47-pr51746.patch Untested fix.
[Bug middle-end/51750] New: [4.7 Regression] FAIL: 25_algorithms/heap/moveable*.cc execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51750 Bug #: 51750 Summary: [4.7 Regression] FAIL: 25_algorithms/heap/moveable*.cc execution test Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: hjl.to...@gmail.com, ia...@gcc.gnu.org, paolo.carl...@oracle.com, rguent...@suse.de Target: i686-*-linux* x86_64-*-linux* x86_64-apple-darwin10 Between revisions 182828 and 182830 the following tests started to fail with -m32 (see http://gcc.gnu.org/ml/gcc-regression/2012-01/msg00048.html ): FAIL: 25_algorithms/heap/moveable.cc execution test FAIL: 25_algorithms/heap/moveable2.cc execution test The failures are Assertion failed: (this-SharedInfo this-ptr this-SharedInfo-last), function operator*, file /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_iterators.h, line 287. FAIL: 25_algorithms/heap/moveable.cc execution test
[Bug middle-end/51750] [4.7 Regression] FAIL: 25_algorithms/heap/moveable*.cc execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51750 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-04 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 11:03:16 UTC --- Confirmed, caused by the PR51730 fix.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04
11:04:41 UTC ---
We can always work around this as in (completely untested):
--- gcc/dwarf2out.c2012-01-03 16:22:48.794866121 +0100
+++ gcc/dwarf2out.c2012-01-04 11:50:30.516022278 +0100
@@ -8166,6 +8166,13 @@ output_loc_list (dw_loc_list_ref list_he
/* Don't output an entry that starts and ends at the same address. */
if (strcmp (curr-begin, curr-end) == 0 !curr-force)
continue;
+ size = size_of_locs (curr-expr);
+ /* If the expression is too large, drop it on the floor. We could
+ perhaps put it into DW_TAG_dwarf_procedure and refer to that
+ in the expression, but = 64KB expressions for a single value
+ in a single range are unlikely very useful. */
+ if (size 0x)
+continue;
if (!have_multiple_function_sections)
{
dw2_asm_output_delta (DWARF2_ADDR_SIZE, curr-begin, curr-section,
@@ -8184,7 +8191,6 @@ output_loc_list (dw_loc_list_ref list_he
Location list end address (%s),
list_head-ll_symbol);
}
- size = size_of_locs (curr-expr);
/* Output the block length for this list of location operations. */
gcc_assert (size = 0x);
But it would be nice to a) find out how can we limit the excessive expression
sizes still during var-tracking, because it might consume lots of compile time
memory b) if we can't do anything smarter at least in cases like PR51695 where
the expression is so huge just because it keeps computing the same values again
and again and again. If we remembered we have computed some VALUE (with a
non-trivial expression of more than say 16 rtxes in it), we could represent it
as tmpforvalueXXX = the_rtx, and then just use the temporary in all places.
In the DWARF expression it would mean we'd compute (all the temporaries) first
and keep them pushed into the DWARF stack, then once all those are computed
we'd just DW_OP_picked the values we want (as many times as needed).
So, e.g. in the pr51695 case, we'd have a temporary for:
(if_then_else:SI (lt (mem/c/i:SI (symbol_ref:DI (v) [flags 0x2] var_decl
0x7 f431dcea140 v) [2 v+0 S4 A32]) (const_int 0 [0]))
(xor:SI (ashift:SI (mem/c/i:SI (symbol_ref:DI (v) [flags 0x2] var_decl
0x7f431dcea140 v) [2 v+0 S4 A32]) (const_int 1 [0x1]))
(const_int -1550293667 [0xa398655d]))
(ashift:SI (mem/c/i:SI (symbol_ref:DI (v) [flags 0x2] var_decl
0x7f431dcea140 v) [2 v+0 S4 A32]) (const_int 1 [0x1])))
expression and use it in all the places where it is used (in that testcase this
is used over 2000 times), then perhaps some larger expression that uses these
many times would be again a temporary, etc. and here we could end up with a
DWARF expression of only few dozens of bytes.
[Bug preprocessor/51745] Strange symbol appears when using commandline definition without =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51745 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 11:10:07 UTC --- The 1 comes likely from -Dfoo being equivalent to Dfoo=1 if there is no = on the command line, and as the preprocessor internally doesn't use = signs but spaces after macro name, we append 1. -Dfoo bar is thus expanded as -Dfoo bar 1. processed correctly means what exactly? You can't define macro blabla(x, y) bleble[x,y], C doesn't have macros with spaces in the names. Garbage in garbage out in my eyes.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added Attachment #26214|0 |1 is obsolete|| --- Comment #39 from Marc Glisse marc.glisse at normalesup dot org 2012-01-04 11:10:30 UTC --- Created attachment 26237 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26237 remember linkage of a function type (5) Updated patch, now bootstraps with configure --enable-languages=c,c++ --disable-werror (except for some __int128 error in libitm which I assume is unrelated). The main difference is that I allow (with a warning) conversions between function pointers that differ by extern C, so things like calling pthread_create with a C++ function compile. The library changes are still there but most of them are unnecessary if we don't mind warnings. I didn't try to do the cleanup suggested by Andrew, I was concentrating on the functionality. And I believe the only big functionality missing is giving builtins their right type (__builtin_memcpy is extern C, operator new[] is C++, etc). Then (before even thinking of cleaning up the patch and fixing the whole gcc code base) will come the decision of whether we actually want to do this change. It is necessary in order to conform to the standard, but it is more convenient to keep ignoring linkage...
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 11:25:57 UTC --- One problem with such temporaries approach would be that if the temporaries are in the whole expression evaluated only conditionally, they could have unwanted side-effects (reading uninitialized memory, division by zero, producing NaNs etc.) that the debugger might complain about loudly. Say if the expression is (if_then_else (r1 56) (temp1) (const_int 0)) where temp1 is (mem (foo + r1)) or similar, if we evaluate it upfront, the debugger might complain. Another alternative would be (for a dwarf2out.c solution, so the compile time memory issue would be still there) when we'd be finalizing all the DWARF expressions in the CU, we'd somehow hash the larger subexpressions where it might be beneficial and if they are long enough and occur at least twice, create a DW_TAG_dwarf_procedure for them and just replace those subexpressions with DW_OP_call* to that procedure.
[Bug bootstrap/51734] [4.7 Regression] Bootstrap fails in libada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51734 --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-01-04 11:41:11 UTC --- Author: krebbel Date: Wed Jan 4 11:41:06 2012 New Revision: 182868 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182868 Log: config/ 2012-01-04 Andreas Krebbel andreas.kreb...@de.ibm.com PR bootstrap/51734 * picflag.m4: Remove s390 case statement. gcc/ 2012-01-04 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. libada/ 2012-01-04 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. libgcc/ 2012-01-04 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. * config/s390/t-crtstuff: Remove -fPIC. libiberty/ 2012-01-04 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. Modified: trunk/config/ChangeLog trunk/config/picflag.m4 trunk/gcc/ChangeLog trunk/gcc/configure trunk/libada/ChangeLog trunk/libada/configure trunk/libgcc/ChangeLog trunk/libgcc/config/s390/t-crtstuff trunk/libgcc/configure trunk/libiberty/ChangeLog trunk/libiberty/configure
[Bug bootstrap/51734] [4.7 Regression] Bootstrap fails in libada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51734 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-01-04 11:49:43 UTC --- Fixed with the patch from comment #2.
[Bug fortran/49693] Spurious unused-variable warnings for COMMON block module variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-01-04 11:51:40 UTC --- Author: tkoenig Date: Wed Jan 4 11:51:37 2012 New Revision: 182869 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182869 Log: 2012-01-04 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/49693 * trans-common.c (create_common): Update copyright years. Mark variables as used to avoid warnings about unused variables in common blocks. 2012-01-04 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/49693 * gfortran.dg/common_17.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/common_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #40 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-04 11:49:35 UTC --- Great! If all existing code is accepted with a warning that provides backwards compatibility, but also allows conforming code to correctly overload on language linkage - that sounds ideal. IMHO the warning should be controllable by something such as -Wlanguage-linkage (since there will be lots of warnings in some codebases, so it needs to be possible to use -Wall but disable these warnings) and the conversion should be rejected with -pedantic-errors.
[Bug tree-optimization/49651] [4.4/4.5 Regression] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651 --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 11:54:25 UTC --- Author: rguenth Date: Wed Jan 4 11:54:18 2012 New Revision: 182870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182870 Log: 2012-01-04 Richard Guenther rguent...@suse.de Backport from mainline 2012-01-04 Richard Guenther rguent...@suse.de PR tree-optimization/49651 * tree-ssa-structalias.c (type_can_have_subvars): New function. (var_can_have_subvars): Use it. (get_constraint_for_1): Only consider subfields if there can be any. 2011-07-14 Richard Guenther rguent...@suse.de PR tree-optimization/49651 * tree-ssa-structalias.c (get_constraint_for_1): Properly handle dereferences with subvariables. * gcc.dg/torture/pr49651.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr49651.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-structalias.c
[Bug fortran/49693] Spurious unused-variable warnings for COMMON block module variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-01-04 11:55:15 UTC --- Fixed on trunk, closing. If somebody really, really wants a backport to 4.6, please speak up.
[Bug tree-optimization/49651] [4.4 Regression] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Known to work||4.5.4 AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org Summary|[4.4/4.5 Regression] nested |[4.4 Regression] nested |lambdas and -O3 produced|lambdas and -O3 produced |incorrect integer variable |incorrect integer variable |increments |increments --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 11:56:05 UTC --- Fixed for 4.5 as well. I am not considering 4.4 at this moment.
[Bug target/51751] New: COMPLEX16 tests fail in Lapack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51751 Bug #: 51751 Summary: COMPLEX16 tests fail in Lapack Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Target: powerpc64-unknown-linux-gnu Running the Lapack 3.4.0 testsuite exposes the following errors: ZGB:281 out of 28488 tests failed to pass the threshold *** On entry to ZGBSVX parameter number 13 had an illegal value *** *** On entry to ZGBSVX parameter number 13 had an illegal value *** *** On entry to ZGBSVX parameter number 13 had an illegal value *** *** On entry to ZGBSVX parameter number 13 had an illegal value *** ... *** On entry to ZGBSVX parameter number 14 had an illegal value *** *** On entry to ZGBSVX parameter number 14 had an illegal value *** *** On entry to ZGBSVX parameter number 14 had an illegal value *** *** On entry to ZGBSVX parameter number 14 had an illegal value *** and a few more. The same occurs with current trunk. This can be reproduced on gcc110 on the compile farm.
[Bug c++/51064] False Positive for -Wparentheses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51064 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-04 12:14:50 UTC --- On it.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #41 from Wolfgang Bangerth bangerth at gmail dot com 2012-01-04 12:28:13 UTC --- I would expect a lot of code to trigger this warning. It is quite common to pass the address of a static member function to pthread_create but since there is no way to make a static member function 'extern C', I can't see how to do that without major contortions. I'm rather sure that this will turn out to be an unpopular warning :-) W.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #42 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 12:45:15 UTC --- Well, perhaps something like: #ifdef __cplusplus extern C++ int __REDIRECT_NTH (pthread_create, (pthread_t *__restrict __newthread, const pthread_attr_t *__restrict __attr, void *(*__start_routine) (void *), void *__restrict __arg) __nonnull ((1, 3)), pthread_create); #endif (for glibc) could do the trick (and similarly for qsort and other C functions that take callbacks?), still I agree this would be terribly annoying for everybody. At least this shouldn't be considered for GCC 4.7 at this point.
[Bug lto/51663] LTO does not reclaim comdat-local statics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04
12:49:47 UTC ---
It's interesting that with a simplified testcase
struct T;
static T *m ()
{
static T *d;
return d;
}
int
fn ()
{
m ();
}
int main() {}
The C++ frontend with -fwhole-program no longer removes m::d, so this is
maybe a general issue, not LTO specific.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #43 from Marc Glisse marc.glisse at normalesup dot org 2012-01-04
12:51:55 UTC ---
(In reply to comment #40)
Great! If all existing code is accepted with a warning that provides backwards
compatibility, but also allows conforming code to correctly overload on
language linkage - that sounds ideal.
Well, not all existing code, just the most common ones. For instance:
templateclassstruct is_fun1{static const bool value=false;};
templateclass F,class Tstruct is_fun1F(T){static const bool value=true;};
will answer false for an extern C function type, and I am not sure how I
could make it return true without breaking valid code too much (and you can
call templateclass F,class Tvoid f(F(T)); with an extern C function, but it
has lower priority than templateclass T void f(T); or even void f(...);).
But most uses in common code seem to be fine (it is even more lenient than
sunCC, which fails to compile gcc because of extern C). Note that accepting
these broken codes does imply we do the wrong thing on some valid code but I am
hoping not too much. As a guiding principle, I tried to allow conversions only
when there would be an error otherwise.
IMHO the warning should be controllable by something such as
-Wlanguage-linkage
(since there will be lots of warnings in some codebases, so it needs to be
possible to use -Wall but disable these warnings) and the conversion should be
rejected with -pedantic-errors.
Agreed, there's a lot of cleanup to do...
(In reply to comment #41)
I would expect a lot of code to trigger this warning. It is quite common
to pass the address of a static member function to pthread_create but since
there is no way to make a static member function 'extern C', I can't see
how to do that without major contortions. I'm rather sure that this will
turn out to be an unpopular warning :-)
libstdc++ does something like that in one place. As Jonathan told earlier, it
would make sense to overload pthread_create so it can take a C++ function. The
easiest way not to have the warning is to use a cast (not that this is very
standard...).
As for the popularity... I am still not sure we actually want to do this at
all, this is a proof of concept to help make a decision.
[Bug lto/51663] LTO does not reclaim comdat-local statics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-04
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04
12:54:33 UTC ---
Smaller testcase:
int m ()
{
static int d;
return d;
}
int main() {}
Does not eliminate m::d with -O0 -fwhole-program (but does, with -O1).
It does eliminate m with -O0 -fwhole-program. Similar with LTO and
the original testcase - m::d is only eliminated with optimization.
Odd inconsistency (remember, with -O0 -fwhole-program on the original
testcase m::d is eliminated).
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-04 12:57:28 UTC --- I agree that ignoring the bug or adding sorry refusing -fno-merge-constants -flto is probably only way to deal with it in 4.7. If we go the way translating into initialized vars, we probably could translate string constants as easilly as const_decls, so perhaps there is no frontend change needed at all. In general it would be very useful to have pass tagging ADDR_EXPRs on whether the address of object taken needs to be unique or can change freely. This would be useful at several places in IPA and also we could then only promote some of the const decls. Honza
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-04 13:00:27 UTC --- (In reply to comment #42) still I agree this would be terribly annoying for everybody. Not everybody, only those who don't also use another compiler that already diagnoses it ;) I'd be happy if a warning was only enabled by -pedantic not -Wall, but I accept I'm in a small minority who even know about this problem, and an even smaller minority who want it fixed
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de 2012-01-04 13:02:26 UTC --- On Wed, 4 Jan 2012, hubicka at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-04 12:57:28 UTC --- I agree that ignoring the bug or adding sorry refusing -fno-merge-constants -flto is probably only way to deal with it in 4.7. If we go the way translating into initialized vars, we probably could translate string constants as easilly as const_decls, so perhaps there is no frontend change needed at all. In general it would be very useful to have pass tagging ADDR_EXPRs on whether the address of object taken needs to be unique or can change freely. This would be useful at several places in IPA and also we could then only promote some of the const decls. Well, whether or not is the Frontends burden to decide. And if not, it has to use an ADDR_EXPR of a CONST_DECL. Richard.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #45 from Marc Glisse marc.glisse at normalesup dot org 2012-01-04 13:06:10 UTC --- (In reply to comment #42) Well, perhaps something like: #ifdef __cplusplus extern C++ int __REDIRECT_NTH (pthread_create, (pthread_t *__restrict __newthread, const pthread_attr_t *__restrict __attr, void *(*__start_routine) (void *), void *__restrict __arg) __nonnull ((1, 3)), pthread_create); #endif (for glibc) could do the trick (and similarly for qsort and other C functions that take callbacks?) For bsearch and qsort, the standard actually requires those (and solaris has them, although we fixinclude them out currently). For posix functions, well, the posix-c++-wg mailing-list hasn't seen a single email since March 2010... still I agree this would be terribly annoying for everybody. Yes. At least this shouldn't be considered for GCC 4.7 at this point. Oh, of course. Maybe not even 4.8. In the patch, I (partially) enabled alias templates in system headers because there are some things in libstdc++ that may not be possible to do without those, so it may be better to wait until -std=c++11 becomes the default if we want to do that. Plus, that completely breaks the ABI, so it should be synchronized with other ABI-breaking changes. And we may even decide on an official WONTFIX.
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2012-01-04 13:14:17 UTC --- In general it would be very useful to have pass tagging ADDR_EXPRs on whether the address of object taken needs to be unique or can change freely. This would be useful at several places in IPA and also we could then only promote some of the const decls. Well, whether or not is the Frontends burden to decide. And if not, it has to use an ADDR_EXPR of a CONST_DECL. What I meant here is pass that tracks uses of ADDR_EXPR to see if it possibly can be compared for equality that would break when the object gets duplicated for some reason. This would strenghten some stuff, like hidding COMDAT functions (where we special case already virtual functions, but we could do more) Honza
[Bug middle-end/51750] [4.7 Regression] FAIL: 25_algorithms/heap/moveable*.cc execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51750 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:25:35 UTC --- Author: rguenth Date: Wed Jan 4 13:25:28 2012 New Revision: 182872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182872 Log: 2012-01-04 Richard Guenther rguent...@suse.de PR middle-end/51750 * tree.c (size_low_cst): New function. * tree.h (size_low_cst): Declare. * fold-const.c (fold_comparison): Use it to extract the low part of the POINTER_PLUS_EXPR offset. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug middle-end/51750] [4.7 Regression] FAIL: 25_algorithms/heap/moveable*.cc execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51750 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:26:50 UTC --- Fixed.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:30:21 UTC --- Was the patch installed?
[Bug bootstrap/51072] [4.7 Regression] Build with --disable-bootstrap fails in libitm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51072 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:33:55 UTC --- We need at least some solution, like forcefully enabling C++ or disable libitm if C++ is not in stage$N-languages.
[Bug target/51106] [4.5/4.6/4.7 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:36:30 UTC --- I assume the issue would reproduce on mipsisa64-elf as well.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-04 13:33:20 UTC --- --- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:30:21 UTC --- Was the patch installed? Unfortunately not, I'm currently applying it to my private tree to allow IRIX to bootstrap at all. I'm not even sure it was ever submitted. Rainer
[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51471 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug libgcj/51498] [4.7 regression] temporary hack to make dejagnu work in libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51498 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-04 13:40:19 UTC --- Oh, and why is this a regression?
[Bug tree-optimization/51528] [4.6/4.7 Regression] SRA should not create BOOLEAN_TYPE replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51528 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/51565] [4.4/4.5/4.6/4.7 Regression] fastcall in array of method pointers: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51565 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Priority|P3 |P2 Component|target |c++
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/51613] [4.4/4.5/4.6/4.7 Regression] Ambiguous function template instantiations as template argument are not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51613 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug c++/51614] [4.6/4.7 Regression] ICE with ambiguous base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51614 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/51633] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/51694] [4.7 Regression] ICE while compiling alliance package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51694 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51746 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2012-01-04 14:04:29 UTC --- Author: mikael Date: Wed Jan 4 14:04:24 2012 New Revision: 182874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182874 Log: PR fortran/50981 * trans.h (struct gfc_ss_info): New field data::scalar::can_be_null_ref * trans-array.c: If the reference can be NULL, save the reference instead of the value. * trans-expr.c (gfc_conv_expr): If we have saved a reference, dereference it. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h
[Bug middle-end/51752] New: trans-mem: publication safety violated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752
Bug #: 51752
Summary: trans-mem: publication safety violated
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: torv...@gcc.gnu.org
Created attachment 26238
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26238
publication safety test
Publication safety refers to transactions being able to safely publish data by
setting something like a shared flag (e.g., data=23; __transaction_atomic {
flag = 1; }). For that to work, programmers must access the data only if the
flag is true. Second, the compiler must preserve program order in this case
and is not allowed to reorder the two loads (i.e., load data before loading the
flag). Otherwise, there will be a race condition and the data load can return
an inconsistent value.
The attached test shows that this isn't working currently (e.g., look at
149t.optimized, the load of data is moved to out of the loop and before the
flag loads).
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-04 14:18:26 UTC --- OK, it is bug in estimate_edge_devirt_benefit that cause overall function size to go bellow 0. I am looking into the fix. Honza
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695
--- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com
2012-01-04 14:20:29 UTC ---
(In reply to comment #4)
they could have unwanted
side-effects (reading uninitialized memory, division by zero, producing NaNs
etc.) that the debugger might complain about loudly.
GDB will complain.
create a DW_TAG_dwarf_procedure for them and just replace those subexpressions
with DW_OP_call* to that procedure.
DW_OP_call{2,4} is supported by GDB now. DW_TAG_dwarf_procedure is unsupported
now but it looks like a oneliner patch, ping me for DW_TAG_dwarf_procedure
implementation, please.
[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2012-01-04 14:20:24 UTC --- Author: mikael Date: Wed Jan 4 14:20:17 2012 New Revision: 182875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182875 Log: PR fortran/50981 * trans-array.h (gfc_walk_elemental_function_args): New argument. * trans-intrinsic.c (gfc_walk_intrinsic_function): Update call. * trans-stmt.c (gfc_trans_call): Ditto. * trans-array.c (gfc_walk_function_expr): Ditto. (gfc_walk_elemental_function_args): Get the dummy argument list if possible. Check that the dummy and the actual argument are both optional, and set can_be_null_ref accordingly. Added: trunk/gcc/testsuite/gfortran.dg/elemental_optional_args_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/44777] [4.4/4.5/4.6/4.7 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 14:27:21 UTC --- In y we instrument edges 2-5 (count 1001), 3-4 (count 0), 5-6 (count 1) and 7-8 (count 0). bb 4 has the goto *x; which is never executed (a is never -1), bb 6 ends in the non-local goto, bb 7 contains the recursive call to y and bb 8 contains the return from y (which is even never reached, as the innermost y call performs a non-local goto to the caller). I think the problem is that the fake edge from bb 7 to exit (the one added because the call is not const/pure/noreturn and thus might not return at all or might return e.g. through throwing exception or (in this case doing nonlocal goto) is not added to the spanning tree, because there is already fake edge from entry to the same block 7 (as bb 7 is also a destination of the abnormal edge, computed goto). Don't we need for bbs that have both entry and exit fake edges split those bbs before find_spanning_tree (or in it), so that instrumentation can be added into the middle of that basic block?
[Bug middle-end/51696] [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 14:32:59 UTC --- Author: aldyh Date: Wed Jan 4 14:32:54 2012 New Revision: 182876 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182876 Log: PR middle-end/51696 * trans-mem.c (diagnose_tm_1): Display indirect calls with no name correctly. Added: trunk/gcc/testsuite/gcc.dg/tm/pr51696.c Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/51696] [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 14:34:39 UTC --- fixed
[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2012-01-04 14:36:38 UTC --- Author: mikael Revision: 182875 Modified property: svn:log Modified: svn:log at Wed Jan 4 14:36:34 2012 -- --- svn:log (original) +++ svn:log Wed Jan 4 14:36:34 2012 @@ -1,3 +1,4 @@ + PR fortran/50981 * trans-array.h (gfc_walk_elemental_function_args): New argument. * trans-intrinsic.c (gfc_walk_intrinsic_function): Update call. @@ -7,3 +8,5 @@ if possible. Check that the dummy and the actual argument are both optional, and set can_be_null_ref accordingly. +* gfortran.dg/elemental_optional_args_2.f90: New test. +
[Bug c++/50998] [C++0x] ICE partial specialization error at cp/pt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50998
Michal Malecki ethouris at gmail dot com changed:
What|Removed |Added
CC||ethouris at gmail dot com
--- Comment #3 from Michal Malecki ethouris at gmail dot com 2012-01-04
14:52:56 UTC ---
I found a case of similar case - different line number, so maybe it's something
else:
template size_t B, typename Type1, typename... Types
struct tuple_sliced
{
typedef typename tuple_slicedB-1, Types...::type type;
};
templatetypename... Types
struct tuple_sliced0, Types... // -- line 18
{
typedef tupleTypes... type;
};
gcc 4.6 says that it's not implemented to expand Types... in the first
structure. I got a message:
tuple.cc:18:8: internal compiler error: in process_partial_specialization, at
cp/pt.c:4398
The master declaration of tuple_sliced passes correctly - however any use of it
will result in infinite recursion when there's no terminal version.
[Bug middle-end/51212] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51212 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 14:53:44 UTC --- Author: aldyh Date: Wed Jan 4 14:53:30 2012 New Revision: 182877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182877 Log: PR middle-end/51212 * opts.c (finish_options): Sorry out when using transactional memory and non-call exceptions. * doc/invoke.texi (C Dialect Options): Document it. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/opts.c
[Bug middle-end/44777] [4.4/4.5/4.6/4.7 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 14:57:58 UTC --- Created attachment 26239 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26239 gcc47-pr44777.patch Untested fix.
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-04
14:57:34 UTC ---
Estimate_edge_devirt_benefit seems to not make much of sense in mixing the
effects of inlining into the local size. Unforutnately we don't really have
much infrastructure for similar cases. For 4.8 I plan to add benefit metrics
that allows inline-analysis to hint inliner that the inlining is cool idea
besides the local code size/time improvements.
I am testing the following patch.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 182871)
+++ ipa-inline-analysis.c (working copy)
@@ -2204,9 +2204,9 @@ estimate_edge_devirt_benefit (struct cgr
tree target;
struct cgraph_node *callee;
struct inline_summary *isummary;
- int edge_size = 0, edge_time = 0;
+ int edge_size, edge_time, time_diff, size_diff;
- if (!known_vals || !known_binfos)
+ if (!known_vals !known_binfos)
return;
target = ipa_get_indirect_edge_target (ie, known_vals, known_binfos);
@@ -2214,10 +2214,12 @@ estimate_edge_devirt_benefit (struct cgr
return;
/* Account for difference in cost between indirect and direct calls. */
- *size -= ((eni_size_weights.indirect_call_cost - eni_size_weights.call_cost)
- * INLINE_SIZE_SCALE);
- *time -= ((eni_time_weights.indirect_call_cost - eni_time_weights.call_cost)
- * INLINE_TIME_SCALE * prob / REG_BR_PROB_BASE);
+ size_diff = ((eni_size_weights.indirect_call_cost -
eni_size_weights.call_cost)
+ * INLINE_SIZE_SCALE);
+ *size -= size_diff;
+ time_diff = ((eni_time_weights.indirect_call_cost -
eni_time_weights.call_cost)
+ * INLINE_TIME_SCALE * prob / REG_BR_PROB_BASE);
+ *time -= time_diff;
callee = cgraph_get_node (target);
if (!callee || !callee-analyzed)
@@ -2229,21 +2231,18 @@ estimate_edge_devirt_benefit (struct cgr
estimate_edge_size_and_time (ie, edge_size, edge_time, prob);
/* Count benefit only from functions that definitely will be inlined
- if additional context from NODE's caller were available. */
- if (edge_size = isummary-size * INLINE_SIZE_SCALE)
+ if additional context from NODE's caller were available.
+
+ We just account overall size change by inlining. TODO:
+ we really need to add sort of benefit metrics for these kind of
+ cases. */
+ if (edge_size - size_diff = isummary-size * INLINE_SIZE_SCALE)
{
/* Subtract size and time that we added for edge IE. */
- *size -= edge_size;
- *time -= edge_time;
+ *size -= edge_size - size_diff;
- /* Subtract benefit from inlining devirtualized call. */
- *size -= edge_size - isummary-size * INLINE_SIZE_SCALE;
- *time -= edge_time - (isummary-time * INLINE_TIME_SCALE * prob
- / REG_BR_PROB_BASE);
-
- /* TODO: estimate benefit from optimizing CALLEE's body provided
-additional context from IE call site.
-For insipiration see ipa-cp.c: devirtualization_time_bonus(). */
+ /* Account inlined call. */
+ *size += isummary-size * INLINE_SIZE_SCALE;
}
}
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-04 Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 Regression] |Regression] Wrong-code for |Wrong-code for scalarizing |scalarizing ELEMENTAL call |ELEMENTAL call with absent |with absent OPTIONAL|OPTIONAL argument |argument| Ever Confirmed|0 |1 --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org 2012-01-04 15:05:47 UTC --- Fixed on trunk (4.7), backport bending.
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #9 from Mikael Morin mikael at gcc dot gnu.org 2012-01-04 15:06:32 UTC --- (In reply to comment #8) Fixed on trunk (4.7), backport bending. s/bending/pending/
[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-04 15:28:16 UTC --- Fixed in 4.6.3+ For a complete fix covering libgcc, however, PR51345 is needed which is fixed in 4.7.0
[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-04 15:29:29 UTC --- Fixed in 4.7.0
[Bug bootstrap/51648] [4.7 Regression] Profiledbootstrap failure on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51648 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 16:38:37 UTC --- That delta script had a typo (was using gcc.o instead of gccmy.o), thus the resulting preprocessed file is irrelevant. Here is an actually reduced testcase: rm -f pr51648-1.gcda pr51648-2.gcda ./cc1 -fpreprocessed -quiet -g -O2 -fexceptions -fprofile-generate \ pr51648-1.c -o pr51648-1.s ./xgcc -B ./ -o pr51648 -fprofile-generate pr51648-1.s pr51648-2.c ./pr51648 ./cc1 -fpreprocessed -quiet -g -O2 -fexceptions -fprofile-use \ pr51648-1.c -o pr51648-2.s gives: pr51648-1.c: In function ‘main’: pr51648-1.c:37:1: error: corrupted profile info: profile data is not flow-consistent pr51648-1.c:37:1: error: corrupted profile info: number of executions for edge 4-5 thought to be 1 pr51648-1.c:37:1: error: corrupted profile info: number of executions for edge 4-9 thought to be -1 I'll attach the two sources.
[Bug c++/51064] False Positive for -Wparentheses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51064 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-01-04 16:40:01 UTC --- Author: paolo Date: Wed Jan 4 16:39:53 2012 New Revision: 182880 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182880 Log: /cp 2012-01-04 Paolo Carlini paolo.carl...@oracle.com PR c++/51064 * pt.c (tsubst_copy_and_build): Maybe set TREE_NO_WARNING on the tree returned by build_x_binary_op. /testsuite 2012-01-04 Paolo Carlini paolo.carl...@oracle.com PR c++/51064 * g++.dg/warn/Wparentheses-26.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wparentheses-26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51064] False Positive for -Wparentheses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51064 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-04 16:41:03 UTC --- Fixed for 4.7.0.
[Bug bootstrap/51648] [4.7 Regression] Profiledbootstrap failure on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51648 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 16:39:44 UTC --- Created attachment 26240 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26240 pr51648-1.c
[Bug bootstrap/51648] [4.7 Regression] Profiledbootstrap failure on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51648 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #26163|0 |1 is obsolete|| Attachment #26164|0 |1 is obsolete|| Attachment #26169|0 |1 is obsolete|| --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 16:40:34 UTC --- Created attachment 26241 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26241 pr51648-2.c
[Bug other/51163] gcc.dg/tm/alias-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51163 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 17:02:03 UTC --- Author: aldyh Date: Wed Jan 4 17:01:50 2012 New Revision: 182882 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182882 Log: Add PR reference. +PR other/51163 +PR other/51164 Modified: trunk/gcc/testsuite/ChangeLog
[Bug other/51164] gcc.dg/tm/alias-2.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51164 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 17:02:05 UTC --- Author: aldyh Date: Wed Jan 4 17:01:50 2012 New Revision: 182882 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182882 Log: Add PR reference. +PR other/51163 +PR other/51164 Modified: trunk/gcc/testsuite/ChangeLog
[Bug other/51163] gcc.dg/tm/alias-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51163 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 17:04:45 UTC --- fixed
[Bug other/51164] gcc.dg/tm/alias-2.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51164 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 17:05:16 UTC --- fixed
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383 --- Comment #18 from davidxl xinliangli at gmail dot com 2012-01-04 17:11:26 UTC --- (In reply to comment #17) On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383 --- Comment #16 from davidxl xinliangli at gmail dot com 2012-01-04 00:28:55 UTC --- A related topic - aliasing property of realloc -- the malloc attribute is not applied in the glibc header and the comment is like /* __attribute_malloc__ is not used, because if realloc returns the same pointer that was passed to it, aliasing needs to be allowed between objects pointed by the old and new pointers. * It is true that the realloc can return an address is physically aliased with the pointer passed to it -- but assuming no-alias by the compiler should cause no harm -- as all code motions/CSEs across the realloc call will not be possible because realloc may modify/use the memory location. Any comment on this? The malloc attribute assumes that the contents of the memory pointed to by the return value is undefined, so the comment is inaccurate but the malloc attribute can indeed be not used. Which part of the optimizer takes advantage of the 'undefinedness' of returned memory? We can explicitly handle REALLOC in the points-to code to honor the fact that it is not (we do not at the moment). ok.
[Bug target/51753] New: Many gcc.dg/simultate-thread tests fail on Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51753 Bug #: 51753 Summary: Many gcc.dg/simultate-thread tests fail on Solaris 10+/x86 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ubiz...@gmail.com Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] Many of the new gcc.dg/simulate-thread tests FAIL on Solaris 10 and 11/x86, both 32 and 64-bit: FAIL: gcc.dg/simulate-thread/atomic-other-int.c -O1 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-int.c -O2 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-int.c -O3 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-int.c -Os -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-longlong.c -O0 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-longlong.c -O1 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-longlong.c -O2 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-longlong.c -O3 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-longlong.c -Os -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-short.c -O1 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-short.c -O2 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-short.c -O3 -g thread simulation test FAIL: gcc.dg/simulate-thread/atomic-other-short.c -Os -g thread simulation test This happens neither on Solaris 8 and 9/x86 (32-bit only), nor on x86_64-unknown-linux-gnu or i686-unknown-linux-gnu, using gdb 7.3.1 everywhere. E.g. in atomic-other-int.c, the __atomic_fetch_sub FAILs; if I add logging code to test_abort, I find FAIL: invalid intermediate result for value value = 1 ret = 0 I'm uncertain if this is a code generation issue or a problem on the gdb side. Rainer
[Bug fortran/51754] New: [OOP] ICE on valid with class arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51754 Bug #: 51754 Summary: [OOP] ICE on valid with class arrays Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu This test case gives an ICE on valid related to class arrays: module test private type :: componentB end type componentB type :: treeNode class(componentB), allocatable, dimension(:) :: componentB end type treeNode contains function BGet(self) implicit none class(componentB), pointer :: BGet class(treeNode), intent(in) :: self select type (self) class is (treeNode) BGet = self%componentB(1) end select return end function BGet end module test $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc-4.7/libexec/gcc/x86_64-unknown-linux- gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/opt/gcc-4.7 --enable- languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 20120103 (experimental) (GCC) $ gfortran -c test.F90 -o test.o test.F90: In function ‘bget’: test.F90:19:0: internal compiler error: in gfc_conv_descriptor_offset, at fortran/trans-array.c:210 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. If I remove the allocatable I instead get: $ gfortran -c test.F90 -o test.o f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. If I remove the dimension(:) and change the pointer association to: BGet = self%componentB then it compiles successfully.
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64-suse-linux|powerpc64-suse-linux, ||i386-pc-solaris2* CC||ro at gcc dot gnu.org Host|powerpc64-suse-linux|powerpc64-suse-linux, ||i386-pc-solaris2* Target Milestone|--- |4.7.0 Build|powerpc64-suse-linux|powerpc64-suse-linux, ||i386-pc-solaris2* --- Comment #8 from Rainer Orth ro at gcc dot gnu.org 2012-01-04 17:35:36 UTC --- This also affects 32-bit Solaris/x86. Rainer
[Bug gcov-profile/50127] [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-01-04 Resolution|DUPLICATE | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2012-01-04 17:42:53 UTC --- While the partition2.C assembly failure has in fact been resolved by the fix for PR 49972, the 64-bit gcc.dg/tree-prof/bb-reorg.c execution failure remains, as described. I could meanwhile reproduce it in a i686-unknown-linux-gnu --enable-targets=all bootstrap, so there's nothing Solaris-specific in here. Richard, could you please have a look? This is also a regression from 4.6. Thanks. Rainer
[Bug fortran/49693] Spurious unused-variable warnings for COMMON block module variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693 --- Comment #7 from Harald Klimach harald at klimachs dot de 2012-01-04 18:41:08 UTC --- Thanks a lot! Just ran the gcc trunk over my code, and the annoying warnings are gone.
[Bug c++/51755] New: -Wconversion generates false warnings when the ternary operator is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755
Bug #: 51755
Summary: -Wconversion generates false warnings when the ternary
operator is used
Classification: Unclassified
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: james.ka...@gmail.com
This might be covered by 40752; it's related. But if -Wconversion is used,
simple code like the following
int main()
{
static uint8_t const k = 0x02;
bool c = true;
uint8_t x = 0;
x |= c ? k : 0;
}
triggers a warning, although there is absolutely no possibility of overflow.
[Bug c++/51755] -Wconversion generates false warnings when the ternary operator is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-04 19:02:33 UTC --- also PR 51294
[Bug fortran/46356] [OOP] Erroneous procedure/intent error and ICE for class dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Blocks||51754 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-04 19:13:40 UTC --- (In reply to comment #5) The same error message one gets with Andrew Benson's code, cf. http://gcc.gnu.org/ml/fortran/2012-01/msg00028.html That's now PR 51754
[Bug middle-end/51752] trans-mem: publication safety violated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752 torvald at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-04 Ever Confirmed|0 |1
[Bug middle-end/51017] GCC 4.6 performance regression (vs. 4.4/4.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017 --- Comment #5 from Alexander Peslyak solar-gcc at openwall dot com 2012-01-04 19:39:26 UTC --- I wrote and ran some scripts to test many versions/snapshots of gcc. It turns out that 4.6-20100703 (oldest 4.6 snapshot available for FTP) was already affected by this regression, whereas 4.5-20111229 and 4.4-20120103 are not affected (as expected). Also, it turns out that there was a smaller regression at this same benchmark between 4.3 and 4.4. That is, 4.3 produces the fastest code of all gcc versions I tested. Here are some numbers: 4.3.5 20100502 - 2950K c/s, 28229 bytes 4.3.6 20110626 - 2950K c/s, 28229 bytes 4.4.5 20100504 - 2697K c/s, 29764 bytes 4.4.7 20120103 - 2691K c/s, 29316 bytes 4.5.1 20100603 - 2729K c/s, 29203 bytes 4.5.4 20111229 - 2710K c/s, 29203 bytes 4.6.0 20100703 - 2133K c/s, 29911 bytes 4.6.0 20100807 - 2119K c/s, 29940 bytes 4.6.0 20100904 - 2142K c/s, 29848 bytes 4.6.0 20101106 - 2124K c/s, 29848 bytes 4.6.0 20101204 - 2114K c/s, 29624 bytes 4.6.3 20111230 - 2116K c/s, 29624 bytes 4.7.0 20111231 - 2147K c/s, 29692 bytes These are for JtR 1.7.9 with DES_BS_ASM set to 0 on line 157 of x86-64.h (to disable this version's workaround for this GCC 4.6 regression), built with make linux-x86-64 and run on one core in a Xeon E5420 2.5 GHz (the system is otherwise idle). The code sizes given are for .text of DES_bs_b.o (which contains three similar functions, of which one is in use by this benchmark - that is, the code size in the loop is about 10 KB). As you can see, 4.3 generated code that was both significantly faster and a bit smaller than all other versions'. In 4.4, the speed decreased by 8.5% and code size increased by 4.4%. 4.5 corrected this to a very limited extent - still 8% slower and 3.5% larger than 4.3's. 4.6 brought a huge performance drop and a slight code size increase. 4.7.0 20111231's code is still 27% slower than 4.3's.
[Bug middle-end/44777] [4.4/4.5/4.6/4.7 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #26239|0 |1 is obsolete|| --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 19:41:17 UTC --- Created attachment 26242 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26242 gcc47-pr44777.patch Unfortunately that patch regressed tree-prof/pr34999.c on i?86. The bb's of __builtin_setjmp_receiver (and __builtin_setjmp_dispatcher) contain abnormal incoming and outgoing edges, therefore with the patch we want to split them, which apparently is nothing the __builtin_setjmp_* expansion is prepared for. In particular the code was first optimized so that the 64-bit counters are in some places shadowed in local stack slots, but accessing those slots using %ebp before the blockage from __builtin_setjmp_receiver means %ebp contains some bad value rather than the correct one that __builtin_setjmp_receiver computes. So, either we don't split bbs starting with these two builtins as done in this new version of the patch, or perhaps we should just ignore some of the edges between the 3 __builtin_setjmp_* builtins altogether for profiling purposes.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-04 19:58:07 UTC --- Author: jakub Date: Wed Jan 4 19:58:03 2012 New Revision: 182886 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182886 Log: PR debug/51695 * dwarf2out.c (output_loc_list): For now drop = 64KB expressions in .debug_loc on the floor. * gcc.dg/pr51695.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr51695.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
