[Bug tree-optimization/54935] No way to do if converison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54935 --- Comment #5 from Igor Zamyatin izamyatin at gmail dot com 2012-11-27 08:40:44 UTC --- What do you think about the way we can relax this?
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-27 08:58:59 UTC --- (In reply to comment #7) Why are there no line numbers in the backtrace from gdb? You said you compiled with -g. Are you sure that libbacktrace itself was compiled with -g? I meant that I compiled the Fortran testcase with -g; GCC itself, including libbacktrace, was built with default flags which ought to be -O2 -g, but I didn't specifically check how libbacktrace was built. Now that you mention it, it does indeed seem like libbacktrace doesn't have debug symbols for some reason. (In reply to comment #8) The crash within libbacktrace is occurring as it tries to read the debug info. This is presumably a bug in libbacktrace, but I don't know what the problem is without more information. libbacktrace is pretty careful to only read memory that was explicitly read. There is presumably a bug there, but I don't know what it is. I doubt the fact that a signal occurred has anything to do with this. There seems to be something odd about the debug info, as shown both by the fact that libbacktrace crashes trying to read it and that gdb does not display file/line information. I forgot to mention, that I'm able to get a symbolic backtrace from outside a signal handler. Though in that case my testcase used external procedures rather than module procedures, so I guess it's possible there's a bug in handling debug info for module procedures. I'll recheck this..
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | Target Milestone|--- |4.8.0 Summary|Wrong value for optimized |[4.8 Regression] Debug info |debug, variants of |issues with |gcc.dg/guality/pr36728-2.c |gcc.dg/guality/pr36728-*.c --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 09:09:43 UTC --- I'm going to reuse this PR for issues caused or made no longer latent by the http://gcc.gnu.org/viewcvs?root=gccview=revrev=193802 on the pr36728-*.c testcases, given that it already contains some discussion about them.
[Bug tree-optimization/54935] No way to do if converison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54935 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-27 Ever Confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 09:16:01 UTC --- ISTR the argument that one can do mprotect on allocated memory, thus one way to relax this is to see if the access is to a decl and check if that resides in .rodata. Other than that there is of course the issue of introducing store data races - thus if !write_memrefs_written_at_least_once we may not introduce an unconditional store in the C++ memory model (or in the transactional memory model).
[Bug middle-end/55331] [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55331 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 09:20:07 UTC --- Author: rguenth Date: Tue Nov 27 09:20:02 2012 New Revision: 193839 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193839 Log: 2012-11-27 Richard Biener rguent...@suse.de PR middle-end/55331 * gimple-fold.c (gimplify_and_update_call_from_tree): Replace stmt with a NOP instead of removing it. * g++.dg/opt/pr55331.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr55331.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55331] [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55331 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 09:23:19 UTC --- Author: rguenth Date: Tue Nov 27 09:23:15 2012 New Revision: 193840 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193840 Log: 2012-11-27 Richard Biener rguent...@suse.de PR middle-end/55331 * gimple-fold.c (gimplify_and_update_call_from_tree): Replace stmt with a NOP instead of removing it. * g++.dg/opt/pr55331.C: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/opt/pr55331.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gimple-fold.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 09:27:06 UTC --- Created attachment 28789 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28789 gcc48-pr55467.patch The following patch tweaks the testcases to have explicit dependency between the two asms and use NOP from nop.h. Additionally it adds two modified testcases, which contain volatile asm everywhere but on the first occurrence in foo. That shouldn't cause any debug info degradation, some information will be lost after the volatile asm, but the breakpoint is still where the information should be present. But it seems e.g. on i686-linux, all the arg[1-7] vars lose their locations already much earlier, on the fp setter instruction. I've tracked it down to cselib_reset_table not actually resetting the REG/MEM locations in the table for values that aren't dropped completely from the hash table.
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27
09:32:55 UTC ---
(In reply to comment #6)
Created attachment 28779 [details]
Patch to use libbacktrace
I have to apply the following patch on your patch in order to be able to
compile it. (MULTIBUILDTOP is empty here and the library is not in
/libbacktrace.)
--- libgfortran-backtrace-pr54572.diff.orig 2012-11-27 10:09:13 +0100
+++ libgfortran-backtrace-pr54572.diff 2012-11-27 10:12:05 +0100
@@ -51 +51 @@ index abc23cd..dd325bd 100644
-+-I$(MULTIBUILDTOP)/../libbacktrace \
++-I$(MULTIBUILDTOP)../libbacktrace \
Additionally, I wonder whether one should have:
--- a/Makefile.def
+++ b/Makefile.def
languages = { language=fortran;gcc-check-target=check-fortran;
lib-check-target=check-target-libquadmath;
+ lib-check-target=check-target-libbacktrace;
lib-check-target=check-target-libgfortran; };
languages = { language=java; gcc-check-target=check-java;
And in the same file, I wonder which of the following two is correct:
+dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace; };
or
+dependencies = { module=configure-target-libgfortran;
on=all-target-libbacktrace; };
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27
09:44:32 UTC ---
Or perhaps better just follow what we do at the end of basic blocks in
var-tracking:
--- gcc/cselib.c.jj2012-11-26 10:14:26.0 +0100
+++ gcc/cselib.c2012-11-27 10:29:23.524991980 +0100
@@ -2632,6 +2632,8 @@ cselib_process_insn (rtx insn)
|| (NONJUMP_INSN_P (insn)
volatile_insn_p (PATTERN (insn
{
+ if (cselib_preserve_constants)
+cselib_preserve_only_values ();
cselib_reset_table (next_uid);
cselib_current_insn = NULL_RTX;
return;
That will also clear REG/MEMs from VALUEs that we drop from the hash table.
But there is another, unrelated, issue, that regressed with the r193802 commit.
In main of the new testcases, or even just
int
foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7);
int
main ()
{
int l = 0;
asm volatile ( : =r (l) : 0 (l));
foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
return 0;
}
alone for e.g. -g -O2 -m32, since that commit we now emit wrong call site info,
saying that e.g. the first argument has call_site_value of %eax + 1, which is
wrong, as %eax is call clobbered register.
I'd have expected that
case MO_CALL:
dataflow_set_clear_at_call (set);
should have cleared the %eax location from all the VALUEs, as %eax is call
clobbered.
With the cselib.c patch in this comment as opposed to the cselib.c in the
attached patch the call site info is also wrong, but differently (instead of
saying that the value is say %eax + 1 it now says it is 1 (it is correct only
because the inline asm hasn't changed it to non-zero, but the compiler can't
rely on that).
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #12 from Fran Martinez Fadrique fmartinez at gmv dot com 2012-11-27 09:49:20 UTC --- After readign the standard carefully again (I have the formal version for f2k3, not the draft for f2k8) I cannot really see how the need for the interfaces to be unique can be derived. Regardless whether some compilers issue certains messages or not; actually this is also just different interpretations of the same text. The propotype for SQLSetEnvAttr I do not think that realy matters for the discussion but I have added at the end of this comment. From what I see, the interface need not be unique (I share the point with Juno) The bahaviour that I would expect (and this is again just an interpretation) is that for a definition of a Fortran interface, when invoked, a C function is called based on the provided label (from the f2k3 'A reference to such a procedure causes the function described by the C prototype to be called as ...'). Not mandatory to be always a different one; maybe. 15.4.1 Binding labels for procedures defines how a label must be defined and behaves with respect to the defining fortran interface but it says nothing about being unique. In my case I have to invoke SQLSetEnvAttr with more than one represetnation of the ValuePtr (this is because of the way in which the ODBC library behaves internally; not very nice) and in the way I see the implementation once I need the void * to behave as an integer and then as an actual pointer (c_ptr). I'll try to find another way out of this, but the one I tried seem to be the natural one. I'll give c_intptr_t an opprtunity; it is not in my standard and I had not consider it all (not awware of it actually). SQLRETURN SQLSetEnvAttr( SQLHENV EnvironmentHandle, SQLINTEGER Attribute, SQLPOINTER ValuePtr, SQLINTEGER StringLength); SQLHENV = void * SQLINT = int SQLPOINTER = void *
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27
09:56:12 UTC ---
Note it isn't just call arg info, also NOTE_INSN_VAR_LOCATION for variable l.
Without any of the patches we have (testcase from previous comment):
(note 55 2 41 2 (var_location l (const_int 0 [0])) NOTE_INSN_VAR_LOCATION)
...
(note 56 7 35 2 (var_location l (reg:SI 0 ax [orig:68 l ] [68]))
NOTE_INSN_VAR_LOCATION) ! right after asm volatile
...
(insn 22 40 57 2 (parallel [
(set (reg:SI 0 ax [orig:76 D.1390 ] [76])
(plus:SI (reg:SI 0 ax [orig:68 l ] [68])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) ./pr36728-4.c:9 271 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(nil
(note 57 22 21 2 (var_location l (reg:SI 0 ax [orig:68 l ] [68]))
NOTE_INSN_VAR_LOCATION)
note 57 is wrong, obviously l doesn't have at that point value %eax, but %eax -
1.
With the patch from the previous comment,
(note 57 22 21 2 (var_location l (const_int 0 [0])) NOTE_INSN_VAR_LOCATION)
instead (also wrong, the compiler can't assume the inline asm hasn't changed
the register). What if it is
asm volatile (incl %0 : =r (l) : 0 (l));
instead.
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 10:05:50 UTC --- After compiling comment 5 with my changes of comment 10, I get: Backtrace for this error: 0x2b9567c7ca0d _gfortrani_show_backtrace /projects/tob/gcc-git/gcc/libgfortran/runtime/backtrace.c:92 0x2b9567c7d017 _gfortrani_backtrace_handler /projects/tob/gcc-git/gcc/libgfortran/runtime/compile_options.c:129 0x2b95687503ef ??? ???:0 0x40086b __test_MOD_c /dev/shm/foo.f90:5 0x400847 __test_MOD_b /dev/shm/foo.f90:10 0x40081a __test_MOD_a /dev/shm/foo.f90:15 0x400897 bt /dev/shm/foo.f90:22 0x40092f main /dev/shm/foo.f90:20 And before (i.e with addr2line), I got: Backtrace for this error: #0 0x2AC1DC8D7AE7 #1 0x2AC1DC8D80F2 #2 0x2AC1DD3A43EF #3 0x40086B in __test_MOD_c at foo.f90:5 #4 0x400847 in __test_MOD_b at foo.f90:10 #5 0x40081A in __test_MOD_a at foo.f90:15 #6 0x400897 in bt at foo.f90:22
[Bug middle-end/55331] [4.6 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55331 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3, 4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6 Regression] ICE: |ICE: SIGSEGV in |SIGSEGV in |substitute_and_fold with|substitute_and_fold with |-O2 -fno-tree-fre |-O2 -fno-tree-fre Known to fail|4.7.3, 4.8.0|4.7.2 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 10:14:21 UTC --- Fixed for trunk and 4.7 sofar.
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 10:19:18 UTC --- I suppose pristine 4.7 branch fails to devirtualize as well, right?
[Bug c++/55015] [4.7/4.8 Regression] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-27 10:26:03 UTC --- HJ, can you help finding which change broke this? In Comment #2 there is a very short testcase (it's pretty old, I guess you want -std=c++0x, not -std=c++11 in the command line)
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 10:38:13 UTC --- I'd bet the problem is that for the volatile asms (and setjmp call) cselib.c doesn't call the hook at all. var-tracking.c doesn't call cselib on CODE_LABELs (another spot that resetted the table), and previously as volatile asms we considered only volatile asms with no outputs and no clobbers.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-27 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 10:40:45 UTC --- Infinite loops are a sign for out-of-bound array accesses, 4.8 now very aggressively exploits undefined behavior that this triggers. Btw, it also happens when I declare data8 as int8_t data8[SIZE*2 ]; so it does look like genuine bug in GCC. It loops in #0 0x004009cc in test_constantsigned char, custom_or_constantssigned char (count=13, label=0x4012da int8_t or constants, first=0x6020d0 data8 '\001' repeats 13 times) at benchmark_shared_tests.h:661 btw.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 10:41:34 UTC --- Created attachment 28790 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28790 reduced testcase Reduced testcase attached.
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #28789|0 |1 is obsolete|| Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 10:42:46 UTC --- Created attachment 28791 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28791 gcc48-pr55467.patch Actually, I think for var-tracking it is completely nonsensical to reset the table and not call the hook on volatile insns. Var-tracking isn't performing any CSE or similar across the volatile insns, all it cares about are what values are preserved and what values are clobbered across them. And that is independent on whether they are volatile or not, even volatile asm can't clobber registers it doesn't describe to be clobbered, and memory it doesn't describe to be clobbered. So, instead of adding lots of code to somehow call the hook anyway for these instructions (even for setjmp we e.g. want to generate NOTE_INSN_CALL_ARG_LOCATION note), I think it is better just to reset everything only when cselib isn't used in var-tracking.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-27 10:55:04 UTC --- Created attachment 28792 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28792 patch This is patch I am going to test. It copies open64' notion of heavy calls - i.e. the calls that are not hot, but inlining is still importnat because callee takes considerable time. We had few examples where this is profitable thing, so I guess it is good idea to implement this. The heaviness should be propagated by ipa-profile that is the bit I did not implement for simplicity, so we now consider pretty much every nonleaf function or function with loop as possibly heavy.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-27
10:57:04 UTC ---
With the patch attached (or with main() renamed to something else) I now get at
-O3
int main() ()
{
struct FixedString empty;
int _16;
const char pretmp_18;
int _20;
char _24;
char _25;
const char pretmp_26;
bb 2:
MEM[(char )empty + 8] = 97;
MEM[(char )empty + 9] = 98;
_24 = empty.contents[0];
_16 = (int) _24;
printf (%d\n, _16);
_25 = empty.contents[1];
_20 = (int) _25;
printf (%d\n, _20);
empty ={v} {CLOBBER};
return 0;
}
seems like inconsistency in SRA is causing missing constant porpagation here.
97 and 98 should be propagated into the load.
Richard/Martin, can you take a look, please?
Also notice the stale pretmp declarations.
[Bug c++/55015] [4.7/4.8 Regression] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 11:00:54 UTC --- http://gcc.gnu.org/viewcvs?root=gccview=revrev=189175
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27
11:02:39 UTC ---
More reduced testcase, fails when compiled at -O2 with the C++ frontend,
passes compiled with the C frontend ...
typedef signed char int8_t;
extern void abort (void);
#define SIZE 13
double init_value = 1.0;
int8_t data8[SIZE];
static inline int8_t __attribute__((always_inline))
do_shift(int8_t input) { return ((int8_t)(23) | (int8_t)(10)); }
int main(int argc, char** argv)
{
int8_t *first = data8;
int8_t *last = data8+SIZE;
while (first != last) *first++ = (int8_t)(init_value);
first = data8;
int i;
for(i = 0; i 1000; ++i)
{
int8_t result = 0;
int n;
for (n = 0; n SIZE; ++n)
result += do_shift( first[n] );
int8_t temp = (int8_t)SIZE * do_shift((int8_t)init_value);
if (result != temp)
abort ();
}
return 0;
}
[Bug c++/55015] [4.7/4.8 Regression] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-27 11:02:42 UTC --- Never mind, it's very easy, it's the following change, the fix for PR53821: http://gcc.gnu.org/viewcvs?view=revisionrevision=189176 And PR55472 is a duplicate, reverting the above fixes it too.
[Bug c++/55472] [4.7/4.8 Regression] Linker cannot find lambda symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-27 11:03:54 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55015 ***
[Bug c++/55015] [4.7/4.8 Regression] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||walker_643 at yahoo dot com --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-27 11:03:54 UTC --- *** Bug 55472 has been marked as a duplicate of this bug. ***
[Bug middle-end/55430] [4.8 Regression] LRA miscompilation of ree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 11:06:49 UTC --- Fixed, thanks.
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-27
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-27
11:08:45 UTC ---
Hmm, devirt-2 is also the case we do not inline because function is called
once.
With main renamed to main2 I get at -O3
int main2() ()
{
bb 2:
printf (%d\n, 1);
printf (+1: %d\n, 2);
printf (%d\n, 2);
printf (+1: %d\n, 3);
return 0;
}
from GCC-4.7 as well as from the mainline.
Similarly for devirt-3.C. I will check why this is not matched by the heavy
heuristic I invented for PR55478, but otherwise I think it is non-bug.
Also in devirt-3 we no longer unroll the loop of 3 printf calls, that is IMO
fine.
We should add the updated testcases (with renamed main) to the testsuite IMO.
Honza
[Bug target/46453] MIPS backend is not using special instructions for __builtin_bswap32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46453 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-27 11:10:11 UTC --- Any news on this?
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||35634 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 11:12:03 UTC --- Note that the frontends warn with lucky13x.c: In function 'int main(int, char**)': lucky13x.c:24:64: warning: overflow in implicit constant conversion [-Woverflow] int8_t temp = (int8_t)SIZE * ((int8_t)(23) | (int8_t)(10)); when manually inlining do_shift at the checking point: int8_t temp = (int8_t)SIZE * ((int8_t)(23) | (int8_t)(10)); if (result != temp) abort (); this computes 13 * 31 which is 403 so the warning is correct. Fixed with an extra cast. This also means that for (n = 0; n SIZE; ++n) result += do_shift( first[n] ); triggers the bug about doing the addition in the wrong type and the bug is fixed by rewriting this as result = result + do_shift (first[n]); that is, self-modify is not correctly doing the addition in 'int'. And thus this is a dup of PR35634 I believe (-fwrapv also fixes this).
[Bug regression/55486] New: FAIL: gcc.dg/sms-7.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55486 Bug #: 55486 Summary: FAIL: gcc.dg/sms-7.c (internal compiler error) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: kyrylo.tkac...@arm.com CC: dnovi...@google.com Target: arm-none-eabi FAIL: gcc.dg/sms-7.c (internal compiler error) FAIL: gcc.dg/sms-7.c (test for excess errors) Target: arm-none-eabi gcc.dg/sms-7.c:17:1: internal compiler error: in schedule_reg_moves, at modulo-sched.c:725 Bisection shows regression appears with revision 193595 arm-none-eabi/obj/gcc2/gcc/xgcc -Barm-none-eabi/obj/gcc2/gcc/ src/gcc/gcc/testsuite/gcc.dg/sms-7.c gcc_tg.o -fno-diagnostics-show-caret -O3 -fmodulo-sched -fstrict-aliasing -fdump-rtl-sms -fmodulo-sched-allow-regmoves --param sms-min-sc=1 -specs=rdimon.specs -Wa,-mno-warn-deprecated -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./sms-7.exe Thanks, Kyrill
[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 --- Comment #14 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-27 11:39:25 UTC --- (In reply to comment #13) even volatile asm can't clobber registers it doesn't describe to be clobbered, and memory it doesn't describe to be clobbered. Wrong regarding registers. Since you think so, please reply to the discussion at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01542.html (cc:ed again now).
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-27 11:54:47 UTC --- (In reply to comment #7) This patch broke bootstrap on s390x. Please open a new PR, assigned to me, and attach preprocessed code. Make it depend on this PR.
[Bug c/35634] [4.6/4.7/4.8 Regression] operand of pre-/postin-/decrement not promoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Blocks|55481 | AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #35 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 12:25:02 UTC --- Mine.
[Bug middle-end/55487] New: ICE in mark_jump_label_1, at jump.c:1134 compiling gcc.c-torture/execute/pr51447.c at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55487 Bug #: 55487 Summary: ICE in mark_jump_label_1, at jump.c:1134 compiling gcc.c-torture/execute/pr51447.c at -O2 and above Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c -fno-diagnostics-show-caret -w -O2 -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/pr51447.x2 (timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c -fno-diagnostics-show-caret -w -O2 -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/pr51447.x2 /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c: In function 'main': /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c:27:1: internal compiler error: in mark_jump_label_1, at jump.c:1134 /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c:27:1: internal compiler error: Aborted xgcc: internal compiler error: Aborted (program cc1) compiler exited with status 1
[Bug tree-optimization/55110] [4.8 Regression] Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 13:34:19 UTC --- Author: jakub Date: Tue Nov 27 13:34:11 2012 New Revision: 193845 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193845 Log: PR tree-optimization/55110 * tree-vect-loop.c (vectorizable_reduction): Don't assert that STMT_VINFO_RELATED_STMT of orig_stmt is stmt. * gcc.dg/pr55110.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55110.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 13:38:40 UTC --- Author: jakub Date: Tue Nov 27 13:38:32 2012 New Revision: 193846 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193846 Log: PR middle-end/52650 * function.c (instantiate_virtual_regs_in_insn): Don't delete invalid asm gotos, instead just clear their template and inputs. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug tree-optimization/55110] [4.8 Regression] Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 13:39:53 UTC --- Fixed.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 13:39:57 UTC --- Well, the loop isn't unrolled until late cunroll after which there is no SRA / FRE to fix things up. No, DOM doesn't get it by implementation limitation. As for the PRE issue - we indeed seem to not release SSA temporaries created by PRE. I'll look into that.
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-27 13:41:06 UTC --- Fixed.
[Bug target/55426] gcc.target/arm/neon-vld1_dupQ.c ICEs on armeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55426 --- Comment #2 from Manjunath S Matti mmatti.gcc at gmail dot com 2012-11-27 13:43:43 UTC --- (In reply to comment #1) Reverting the definition of CANNOT_CHANGE_MODE_CLASS introduced on 2012-10-22 at rev #192687 avoids the ICE too. I have tried this, reverting the revision #192687 would fix this issue. But as the comment of the patch specifies In big-endian mode, modes greater than word size (i.e. DFmode) are stored in VFP registers in little-endian order. We can't describe that accurately to GCC, so avoid taking subregs of such values.. Reverting the patch would adversely affect the big-endian toolchain. Hence, I assume that we should have an alternate fix.
[Bug lto/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #27 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-27 13:56:37 UTC --- Author: hjl Date: Tue Nov 27 13:56:31 2012 New Revision: 193848 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193848 Log: Handle OPT_SPECIAL_XXX in LTO PR lto/54795 * lto-opts.c (lto_write_options): Also handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore and OPT_SPECIAL_program_name. PR lto/55474 * lto-wrapper.c (merge_and_complain): Handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore, OPT_SPECIAL_program_name and OPT_SPECIAL_input_file. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-opts.c trunk/gcc/lto-wrapper.c
[Bug lto/55474] global-buffer-overflow in lto-wrapper.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-27 13:56:38 UTC --- Author: hjl Date: Tue Nov 27 13:56:31 2012 New Revision: 193848 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193848 Log: Handle OPT_SPECIAL_XXX in LTO PR lto/54795 * lto-opts.c (lto_write_options): Also handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore and OPT_SPECIAL_program_name. PR lto/55474 * lto-wrapper.c (merge_and_complain): Handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore, OPT_SPECIAL_program_name and OPT_SPECIAL_input_file. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-opts.c trunk/gcc/lto-wrapper.c
[Bug sanitizer/55488] New: Implement cold calls in tsan run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488 Bug #: 55488 Summary: Implement cold calls in tsan run-time Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org, w...@gcc.gnu.org The hottest functions in tsan run-time make two cold calls: __tsan_report_race and __tsan_trace_switch If these calls are implemented via regular calling convention, they ruin the performance since the compiler creates too many spills. So, we've manually implemented a cold-call calling convention using a separate assembly file, libsanitizer/tsan/tsan_rtl_amd64.S Currently, this hack is disabled in GCC causing the tsan run-time to be slower than it could be: libsanitizer/tsan/tsan_rtl.h: #if 0 TSAN_DEBUG == 0 ... #define HACKY_CALL(f) \ We need to enable building/linking the file libsanitizer/tsan/tsan_rtl_amd64.S and enable the HACKY_CALL in libsanitizer/tsan/tsan_rtl.h. This will eliminate the only difference left between the gcc version and upstream. Or maybe gcc has another way to implement a cold call?
[Bug rtl-optimization/55489] New: [4.7 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 Bug #: 55489 Summary: [4.7 regression] insane PRE memory usage with PIE (translate.i) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: bonz...@gnu.org Created attachment 28793 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28793 gzipped preprocessed source Yet another evil testcase, this time for RTL GCSE. Compile with: $ gcc ~/translate.i -g -O2 -fPIE gcc 4.4.6: PRE : 3.83 (24%) usr 0.15 (17%) sys 3.99 (24%) wall 267307 kB (33%) ggc gcc 4.7.2: PRE : 7.95 (41%) usr 0.40 (40%) sys 8.31 (41%) wall 821017 kB (80%) ggc Fixed, or latent in trunk: gcc 4.8.0: PRE : 6.94 (26%) usr 0.02 ( 4%) sys 6.98 (26%) wall 731 kB ( 0%) ggc
[Bug sanitizer/55480] gfortran.dg/allocate_alloc_opt_1{0,3}.f90 test cases ICE f951 with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55480 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-27 14:08:41 UTC --- Also seen in... FAIL: gcc.c-torture/compile/20010525-1.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/20010525-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/20021015-2.c -O2 -flto (internal compiler error) FAIL: gcc.c-torture/compile/20021015-2.c -O2 -flto (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/930529-1.c -O2 -flto (internal compiler error) FAIL: gcc.c-torture/compile/930529-1.c -O2 -flto (test for excess errors) and is reproducible under x86_64 Fedora 15 linux as well.
[Bug rtl-optimization/55489] [4.7 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-27 Ever Confirmed|0 |1
[Bug rtl-optimization/55489] [4.7 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.6, 4.8.0 Target Milestone|--- |4.7.3 Known to fail||4.7.2
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-27 14:35:39 UTC --- Hmm, OK. I wonder how google's branch handles this correctly...
[Bug sanitizer/55480] many test cases fail using -fsanitize=address with internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55480 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-27 14:48:24 UTC --- On x86_64 Fedora 15, these failure back trace as... $ gdb /home/howarth/work-gcc/gcc/cc1 ... (gdb) r -quiet -v -iprefix /home/howarth/work-gcc/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/ -isystem /home/howarth/work-gcc/gcc/include -isystem /home/howarth/work-gcc/gcc/include-fixed /home/howarth/gcc/gcc/testsuite/gcc.c-torture/compile/20010525-1.c -quiet -dumpbase 20010525-1.c -mtune=generic -march=x86-64 -auxbase-strip 20010525-1.o -O0 -w -version -fno-diagnostics-show-caret -fsanitize=address -o /tmp/cc3cqyrC.s ... /home/howarth/gcc/gcc/testsuite/gcc.c-torture/compile/20010525-1.c:1:12: internal compiler error: verify_gimple failed 0x8fcc9b verify_gimple_in_cfg(function*) ../../gcc/gcc/tree-cfg.c:4721 0x834554 execute_function_todo ../../gcc/gcc/passes.c:1971 0x83515c execute_todo ../../gcc/gcc/passes.c:2000 which at the breakpoint tree-cfg.c:4721 backtraces as... Breakpoint 1, verify_gimple_in_cfg (fn=0x7172b140) at ../../gcc/gcc/tree-cfg.c:4721 4721internal_error (verify_gimple failed); (gdb) bt #0 verify_gimple_in_cfg (fn=0x7172b140) at ../../gcc/gcc/tree-cfg.c:4721 #1 0x00834555 in execute_function_todo (data=optimized out) at ../../gcc/gcc/passes.c:1971 #2 0x0083515d in execute_todo (flags=2072) at ../../gcc/gcc/passes.c:2000 #3 0x008387ed in execute_one_pass (pass=0x13e5c40) at ../../gcc/gcc/passes.c:2350 #4 0x00838ba5 in execute_pass_list (pass=0x13e5c40) at ../../gcc/gcc/passes.c:2384 #5 0x0060d85c in expand_function (node=0x717296f0) at ../../gcc/gcc/cgraphunit.c:1641 #6 0x0060f805 in output_in_order () at ../../gcc/gcc/cgraphunit.c:1834 #7 compile () at ../../gcc/gcc/cgraphunit.c:2038 #8 0x0060fca5 in finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:2120 #9 0x004f8b93 in c_write_global_declarations () at ../../gcc/gcc/c/c-decl.c:10120 #10 0x008dc395 in compile_file () at ../../gcc/gcc/toplev.c:559 #11 0x008de042 in do_compile () at ../../gcc/gcc/toplev.c:1884 #12 toplev_main (argc=24, argv=0x7fffdcc8) at ../../gcc/gcc/toplev.c:1960 #13 0x0035e962135d in __libc_start_main (main=0x4dce60 main(int, char**), argc=24, ubp_av=0x7fffdcc8, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffdcb8) at libc-start.c:226 #14 0x004dce91 in _start () (gdb)
[Bug c/35634] [4.6/4.7/4.8 Regression] operand of pre-/postin-/decrement not promoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634 --- Comment #36 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27 14:56:56 UTC --- Created attachment 28794 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28794 first patch updated With the first patch updated to apply again and to instead of promoting doing arithmetic in an unsigned type still causes +FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/vect-iv-8.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/pr18536.c -flto scan-tree-dump-times vect vectorized 1 loop s 1 +FAIL: gcc.dg/vect/vect-iv-8.c -flto scan-tree-dump-times vect vectorized 1 lo ops 1 +FAIL: gcc.dg/vect/vect-iv-8a.c -flto scan-tree-dump-times vect vectorized 1 l oops 1 which is better compared to doing the promotion: +FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/vect-iv-8.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/vect-reduc-dot-u16a.c scan-tree-dump-times vect vectorized 1 loops 2 +FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect vectorized 4 loops 1 +FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect vectorizing stmts using S LP 2 +FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect vectorized 1 loops 2 +FAIL: gcc.dg/vect/pr18536.c -flto scan-tree-dump-times vect vectorized 1 loop s 1 +FAIL: gcc.dg/vect/vect-iv-8.c -flto scan-tree-dump-times vect vectorized 1 lo ops 1 +FAIL: gcc.dg/vect/vect-iv-8a.c -flto scan-tree-dump-times vect vectorized 1 l oops 1 +FAIL: gcc.dg/vect/vect-reduc-dot-u16a.c -flto scan-tree-dump-times vect vecto rized 1 loops 2 +FAIL: gcc.dg/vect/slp-21.c -flto scan-tree-dump-times vect vectorized 4 loops 1 +FAIL: gcc.dg/vect/slp-21.c -flto scan-tree-dump-times vect vectorizing stmts using SLP 2 +FAIL: gcc.dg/vect/slp-perm-9.c -flto scan-tree-dump-times vect vectorized 1 l oops 1 +FAIL: gcc.dg/vect/slp-reduc-3.c -flto scan-tree-dump-times vect vectorized 1 loops 2 +FAIL: gcc.dg/vect/no-scevccp-outer-19.c scan-tree-dump-times vect OUTER LOOP V ECTORIZED. 1 note that the gimple semantics change patch will play foul with decltype / sizeof ( char += char ) where it likely will result in the promoted type rather than char.
[Bug other/55490] New: wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490
Bug #: 55490
Summary: wrong function argument evalution ?
Classification: Unclassified
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ontooo.com
Here the code:
// File: c:/bsd/rigel/sort/Zlog.c
// Date: Sun Nov 25 19:49:19 2012
// (C) OntoOO/ Dennis de Champeaux
#include time.h
#include stdio.h
#include math.h
main (int argc, char *argv[]) {
printf(Running ZLog.c ...\n);
int lng = 16777215;
double x = log(lng);
int j = floor(x);
printf(%d %f %d\n, lng, x, j);
test(floor(log(lng)));
}
test(int k) {
printf(test %d \n, k);
}
Here the compilation:
$ gcc -v -save-temps Zlog.c
Using built-in specs.
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/respins/4.3.4-4/gcc4-4.3.4-4/src/gcc-4.3.4/configure
--srcdir=/gn
u/gcc/releases/respins/4.3.4-4/gcc4-4.3.4-4/src/gcc-4.3.4 --prefix=/usr
--exec-prefix=/usr --bindir=
/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share
--localstatedir=/var --sysco
nfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man -C
--datadir=/usr/share --infodir=/usr/
share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr
--enable-bootstrap --enable-v
ersion-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib
--enable-static --enable-
shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld
--with-gnu-as --with-dwarf2 --dis
able-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--disable-symvers --enab
le-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada
--enable-threads=pos
ix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4
CXX=g++-4 CC_FOR_TARGET=gcc
-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake
GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/us
r/share/java/ecj.jar
Thread model: posix
gcc version 4.3.4 20090804 (release) 1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe -E -quiet -v -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix_
_ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api -idirafter /usr/l
ib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api
Zlog.c -mtune=generi
c -march=i686 -fpch-preprocess -o Zlog.i
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/include
ignoring duplicate directory
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../..
/include/w32api
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include-fixed
/usr/include
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe -fpreprocessed Zlog.i -quiet
-dumpbase Zlog.c -mtune=gene
ric -march=i686 -auxbase Zlog -version -o Zlog.s
GNU C (GCC) version 4.3.4 20090804 (release) 1 (i686-pc-cygwin)
compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-
p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ab3a9276892118426681bf5c260e9d16
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/as.exe -v -o
Zlog.o Zlog.s
GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils)
2.20.51.20100410
COMPILER_PATH=/usr/lib/gcc/i686-pc-cygwin/4.3.4/:/usr/lib/gcc/i686-pc-cygwin/4.3.4/:/usr/lib/gcc/i68
6-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/4.3.4/:/usr/lib/gcc/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cy
gwin/4.3.4/:/usr/lib/gcc/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwi
n/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-cygwin/4.3.4/:/usr/lib/gcc/i686-pc-cygwin/4.3.4/:/usr/lib/gcc/i686
-pc-cygwin/4.3.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-pc-cygwin/4.3.4/collect2.exe -tsaware --wrap _Znwj --wrap
_Znaj --wrap _ZdlPv --w
rap _ZdaPv --wrap _ZnwjRKSt9nothrow_t --wrap _ZnajRKSt9nothrow_t --wrap
_ZdlPvRKSt9nothrow_t --wrap
_ZdaPvRKSt9nothrow_t -Bdynamic --dll-search-prefix=cyg -u
___register_frame_info -u ___deregister_fr
ame_info /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../crt0.o
/usr/lib/gcc/i686-pc-cygwin/4.3.4/crtbegi
n.o -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4
-L/usr/lib/gcc/i686-pc-c
ygwin/4.3.4/../../..
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-11-27 15:34:06 UTC --- When compiled with -fno-weak, we re-use the out-of-line copy in clone_inlined_nodes(), around here: /* We may eliminate the need for out-of-line copy to be output. In that case just go ahead and re-use it. This is not just an memory optimization. Making offline copy of fuction disappear from the program will improve future decisions on inlining. */ This happens because the conditional can_remove_node_now_p_1() returns true for virtuals that are not weak: /* Inlining might enable more devirtualizing, so we want to remove those only after all devirtualizable virtual calls are processed. Lacking may edges in callgraph we just preserve them post inlining. */ (!DECL_VIRTUAL_P (node-symbol.decl) || (!DECL_COMDAT (node-symbol.decl) !DECL_EXTERNAL (node-symbol.decl))) When we re-use the out-of-line copy in clone_inlined_nodes(), we end up setting inlined_to here: e-callee-global.inlined_to = e-caller; This causes the ICE in ipa_make_edge_direct_to_target, because inlined_to is non-NULL: /* We can not make edges to inline clones. It is bug that someone removed the cgraph node too early. */ gcc_assert (!callee-global.inlined_to); Any tips on how to proceed from here?
[Bug target/51106] [4.6 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106 --- Comment #22 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-27 15:46:07 UTC --- Does revision 193846 fix this PR or not?
[Bug rtl-optimization/55489] [4.7/4.8 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added Known to work|4.8.0 | Summary|[4.7 regression] insane PRE |[4.7/4.8 regression] insane |memory usage with PIE |PRE memory usage with PIE |(translate.i) |(translate.i) Known to fail||4.8.0 --- Comment #1 from Paolo Bonzini bonzini at gnu dot org 2012-11-27 15:50:44 UTC --- Strictly not a regression, because the underlying bug is present since always. But something between 4.4.6 and 4.7.2 caused memory usage to become much worse. Also, marking it as not-working in 4.8 because the allocation of reg_known_value is wrong: vec_alloc (reg_known_value, maxreg - FIRST_PSEUDO_REGISTER); and that's what causes the bug to be latent: set_reg_known_value becomes a no-op, and get_reg_known_value always returns NULL.
[Bug middle-end/53992] Combining -fopenmp and -fgnu-tm results in segfault or misbehaving binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53992 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||aldyh at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-11-27 15:51:43 UTC --- fixed in 4.7 branch
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #25 from Adi adivilceanu at yahoo dot com 2012-11-27 15:54:30 UTC --- One more question: Do you know why cc1plus and cc1 have around 300 Mb after I build them ? I just did configure and make on the official sources.(now other options) I see that on the official rpm-s they have around 10 Mb.
[Bug c/55490] wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|other |c --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-27 15:59:05 UTC --- Try declaring your 'test' function before you call it.
[Bug c/55491] New: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 Bug #: 55491 Summary: Segmentation fault Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: tom@amlin.co.uk Created attachment 28795 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28795 Preprocessed source required to reproduce error Compilation of the attached produces segmentation fault error. GCC was invoked using following command line: gcc -O2 -mrtd conftest.c Output is as follows: conftest.c: In function 'e': conftest.c:12:1: 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. Output from gcc -v is as follows: Using built-in specs. COLLECT_GCC=C:\MinGW472\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw472/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.2 (GCC) Preprocessed source is attached.
[Bug c/55490] wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-27 16:06:44 UTC --- More generally, compile with -Wall and fix the warnings.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2012-11-27
16:10:29 UTC ---
The following even more reduced testcase is not fixed by the patch pending
for PR35634.
typedef signed char int8_t;
#define SIZE 13
static inline int8_t do_shift() { return 31; }
int main(int argc, char** argv)
{
int i;
for(i = 0; i 1000; ++i)
{
int8_t result = 0;
int n;
for (n = 0; n SIZE; ++n)
result += do_shift();
int8_t temp = (int8_t)((int8_t)SIZE * ((int8_t)(23) | (int8_t)(10)));
if (result != temp)
__builtin_abort ();
}
return 0;
}
With the C++ frontend we correctly do
D.2194 = do_shift ();
D.2207 = (int) result;
D.2208 = (int) D.2194;
D.2209 = D.2207 + D.2208;
result = (int8_t) D.2209;
anyway, but then IVOPTs comes around and changes it:
bb 4:
# result_17 = PHI result_8(3), 0(7)
- # n_18 = PHI n_9(3), 0(7)
- # ivtmp_12 = PHI ivtmp_13(3), 13(7)
_6 = (int) result_17;
_7 = _6 + 31;
- result_8 = (int8_t) _7;
- n_9 = n_18 + 1;
- ivtmp_13 = ivtmp_12 - 1;
- if (ivtmp_13 != 0)
+ _1 = result_17 + 31;
+ result_8 = _1;
+ if (result_8 != -109)
goto bb 3;
performing the computation in int8_t again which causes VRP to miscompile
the test.
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-27 Component|ada |sanitizer CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||ebotcazou at gcc dot ||gnu.org, jakub at gcc dot ||gnu.org, kcc at gcc dot ||gnu.org Ever Confirmed|0 |1 Summary|stack-buffer-overflow in|probable false positive on |sem_ch8.adb |__builtin_setjmp/__builtin_ ||longjmp --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-27 16:12:57 UTC --- It looks rather like AddressSanitizer is confused by the __builtin_setjmp based exception handling scheme, as hinted at by: Address 0x7fff47f1b588 is located at offset 72 in frame ada__exceptions__raise_current_excep of T0's stack: This frame has 1 object(s): [32, 40) 'id' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) So, does AddressSanitizer support __builtin_setjmp/__builtin_longjmp?
[Bug target/55492] New: __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492
Bug #: 55492
Summary: __atomic_load doesn't match ACQUIRE memory model
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yvan.r...@linaro.org
Created attachment 28796
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28796
Generic expansion patch proposal
Compiling this code for ARMv7
int v;
int foo()
{
return __atomic_load_n (v, __ATOMIC_ACQUIRE);
}
generates a data memory barrier defore the load:
foo:
movwr3, #:lower16:v
movtr3, #:upper16:v
dmb sy
ldr r0, [r3, #0]
bx lr
But, the `Acquire’ semantics imply that no reads in the current thread
dependent on the value currently loaded can be reordered before this load.
Thus, the barrier needs to be after the load and not before.
The issue seems to be in expand_atomic_load which put a memory fence before
the load in any memory model. The attached patch fixes the problem.
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-27 16:13:51 UTC --- The Obfuscated C Contest is this way: http://www.ioccc.org/ Why should anyone bother trying to work out what that does? At least fix the warnings and see if the error goes away.
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-27 16:15:22 UTC --- Oh sorry I missed it causes an ICE, I thought the segfault was from the program - apologies.
[Bug lto/55493] New: [4.8 Regression] LTO always ICEs on i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
Bug #: 55493
Summary: [4.8 Regression] LTO always ICEs on i686-w64-mingw32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fana...@gmail.com
Revision 193777 ICEs with
lto1.exe: internal compiler error: cannot read LTO decls from the object
file
when linking with -flto on i686-w64-mingw32. This happens for all inputs, even
for int main() { return 0; } or (that is, an empty file).
gcc -v
Using built-in specs.
COLLECT_GCC=C:\devel\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/devel/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../gcc-4.8-svn/configure --disable-nls
--build=i686-w64-mingw32 --disable-multilib --enable-languages=c,c++,lto
--disable-win32-registry --enable-openmp --enable-libgomp --enable-graphite
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-threads=posix --disable-symvers --enable-fully-dynamic-string
--disable-libstdcxx-pch --with-arch=i686 --with-tune=generic
--enable-checking=release --disable-werror --disable-sjlj-exceptions
--prefix=/c/builds/gcc/toolchain/out --with-gmp=/c/builds/gcc/prerequisites/out
--with-mpfr=/c/builds/gcc/prerequisites/out
--with-mpc=/c/builds/gcc/prerequisites/out
--with-isl=/c/builds/gcc/prerequisites/out
--with-cloog=/c/builds/gcc/prerequisites/out
--with-libiconv-prefix=/c/builds/gcc/prerequisites/out
--with-host-libstdcxx=-lstdc++ --enable-cloog-backend=isl
Thread model: posix
gcc version 4.8.0 20121124 (experimental) (GCC)
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Known to work||4.8.0 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-27 16:22:23 UTC --- On 4.8.x testcase doesn't ICE.
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 --- Comment #1 from fanael4 at gmail dot com 2012-11-27 16:25:58 UTC --- Forgot to mention: 4.7.2 - works 4.8.0 r193777 - fails
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #2 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-27 16:48:48 UTC --- So, does AddressSanitizer support __builtin_setjmp/__builtin_longjmp? We've never seen those, so I guess not. Can they be lowered to regular setjmp/longjmp calls? If yes, then the run-time library interceptor should take care of them.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #7 from Matt Hargett matt at use dot net 2012-11-27 17:32:01 UTC --- I'll rewrite the test to add a loop that hopefully triggers it as hot at -O3 (and gets unrolled). shouldn't it inline at -O2 since DCE would eliminate the function body and make it an overall win?
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 --- Comment #4 from Matt Hargett matt at use dot net 2012-11-27 17:37:01 UTC --- I'll add a loop to the test that hopefully triggers the inlining (and does the unrolling). Adding both variants (renamed main and with loop) to the test suite would be fantastic. Thanks for the prompt attention!
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-11-27 17:38:01 UTC --- I can't get it to ICE gcc-4.7.2 targeting x86_64-w64-mingw32 w/ -m32 -mrtd, whether hosted on x86_64-linux or on i686-pc-cygwin.
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-27 17:44:06 UTC --- Can they be lowered to regular setjmp/longjmp calls? If yes, then the run-time library interceptor should take care of them. The purpose of __builtin_setjmp/__builtin_longjmp is precisely to avoid using setjmp/longjmp so I don't think that would be very desirable.
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-27 17:52:02 UTC --- For what purpose would any one avoid longjmp call, other than for performance? Under asan, performance already drops by 2x, so using calls will not hurt much. Of course, we could instrument __builtin_longjmp call in the compiler module, but is it worth it? If yes, all we need is to call __asan_handle_no_return before __builtin_longjmp
[Bug sanitizer/48076] Unsafe double checked locking in __emutls_get_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
--- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2012-11-27
18:01:17 UTC ---
Are you sure this isn't a false-positive?
The way I read this code, it is certainly possible for the optimizer
(or the processor) to prefetch emutls_key before the load of offset:
__gthread_key_t prefetch = emutls_key;
pointer offset = obj-loc.offset;
if (__builtin_expect (offset == 0, 0))
{
...
}
struct __emutls_array *arr = __gthread_getspecific (prefetch);
But the compiler should see the memory barriers within the if path
and insert
if (__builtin_expect (offset == 0, 0))
{
...
__gthread_mutex_unlock (emutls_mutex);
prefetch = emutls_key;
}
and the processor had better cancel any speculative prefetch when
it sees the explicit barriers.
I'm also assuming here that Android is using the same gthr-posix.h
that is used by desktop glibc linux, and so there isn't a mistake
in the gthread macros causing a lack of barrier...
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-27 18:06:58 UTC --- For what purpose would any one avoid longjmp call, other than for performance? Under asan, performance already drops by 2x, so using calls will not hurt much. Of course, we could instrument __builtin_longjmp call in the compiler module, but is it worth it? You won't be instrumenting the original executable if you don't do it. If yes, all we need is to call __asan_handle_no_return before __builtin_longjmp Thanks for the tip, I'll give it a try.
[Bug sanitizer/48076] Unsafe double checked locking in __emutls_get_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-27 AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2012-11-27 18:18:23 UTC --- Nevermind. Talking this over with Torvald I see the error. You are correct.
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 --- Comment #5 from tom.day at amlin dot co.uk 2012-11-27 18:20:09 UTC --- Thanks for comments and sorry if original post was at all unclear. The error I got was from gcc hosted on mingw32 and, as per Mikael's comment, I noticed that omitting the -O2 option made it run correctly.
[Bug other/55490] wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490 dennis ddcc at ontooo dot com changed: What|Removed |Added Component|c |other Severity|normal |blocker --- Comment #3 from dennis ddcc at ontooo dot com 2012-11-27 18:22:20 UTC --- I know how to code around this problem. My point is that I don't believe that I should have to do that. Am I wrong?
[Bug c/55490] wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|other |c Severity|blocker |normal --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-27 18:35:29 UTC --- (Please don't change the component and priority back again) Yes, you're wrong. If you don't want to declare your functions properly then you need to convert the argument type explicitly, otherwise the compiler assumes you want to pass an eight byte double, then the function only looks at four of those bytes. test((int)floor(log(lng)));
[Bug c/55490] wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-27 18:37:10 UTC --- Also, GCC 4.3 is no longer supported, there's no point reporting bugs in old discontinued releases.
[Bug c++/55494] New: ICE for char array or int in variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55494
Bug #: 55494
Summary: ICE for char array or int in variadic template
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jondre...@gmail.com
The following code generates internal compiler error: in unify_one_argument, at
cp/pt.c:15267
The error is generated if the template argument to Foo is a char array or int.
It is not generated if it is a struct.
gcc version 4.7.2.20120921 (Red Hat 4.7.2-2)
Target: x86_64-redhat-linux
struct S {};
template char const * Name
struct Foo {};
template typename...Args
void operator(S os, FooArgs... m)
{
}
char test[] = test;
int main()
{
S s;
Footest m;
s m;
}
[Bug c/55490] wrong function argument evalution ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55490 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-27 18:46:10 UTC --- As mentioned the testcase is undefined code.
[Bug c++/55494] ICE for char array or int in variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55494 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-27 18:49:34 UTC --- Reproduced with trunk.
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #26 from Adi adivilceanu at yahoo dot com 2012-11-27 18:55:08 UTC --- One more question: Do you know why cc1plus and cc1 have around 300 Mb after I build them ? I just did configure and make on the official sources.(now other options) I see that on the official rpm-s they have around 10 Mb.
[Bug c++/55494] ICE for char array or int in variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55494 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-27 18:55:34 UTC --- ICEs even with 4.7 branch. With 4.6: /home/marek/rh/tests/pr55494.C:6:19: warning: variadic templates only available with -std=c++0x or -std=gnu++0x [enabled by default] /home/marek/rh/tests/pr55494.C:7:35: sorry, unimplemented: cannot expand ‘Args ...’ into a fixed-length argument list /home/marek/rh/tests/pr55494.C:7:35: error: type/value mismatch at argument 1 in template parameter list for ‘templateconst char* Name struct Foo’ /home/marek/rh/tests/pr55494.C:7:35: error: expected a constant of type ‘const char*’, got ‘Args ...’ /home/marek/rh/tests/pr55494.C: In function ‘int main()’: /home/marek/rh/tests/pr55494.C:17:10: error: no match for ‘operator’ in ‘s m’ /home/marek/rh/tests/pr55494.C:17:10: note: candidate is: /home/marek/rh/tests/pr55494.C:7:6: note: templateclass ... Args void operator(S, int)
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #27 from Adi adivilceanu at yahoo dot com 2012-11-27 19:00:53 UTC --- I have put gmp 4.3.2 and still I get the errors when it builds libstdc++-v3.
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2012-11-27 19:09:34 UTC --- Actually my tests were with -O2 -m32 -mrtd; I only mentioned the -m32 -mrtd part because the 64-bit target ignores -mrtd, one has to explicitly select the 32-bit target for -mrtd to have any effect.
[Bug fortran/55476] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 19:21:09 UTC --- Too simple patch. It won't work in the following case: module m integer, pointer :: p contains subroutine test integer, target :: t p = t contains subroutine sub() if (p /= 0) return end subroutine end subroutine end module m
[Bug fortran/55476] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 19:23:34 UTC --- (In reply to comment #4) Too simple patch. It won't work in the following case: … and it shouldn't: That's actually a case where the warning is correct!
[Bug c++/55495] New: internal compiler error: in write_array_type, at cp/mangle.c:3124
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55495
Bug #: 55495
Summary: internal compiler error: in write_array_type, at
cp/mangle.c:3124
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jasongross9+bugzi...@gmail.com
I have the following code:
#include algorithm
struct foo {
char memory[];
};
void *bar(foo *x) {
return std::move(x-memory);
}
compiling with g++ -std=c++11 -v -save-temps -c main.cpp gives
Using built-in specs.
COLLECT_GCC=/afs/csail/proj/courses/6.172/gcc-cilkplus/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
--prefix=/afs/csail/proj/courses/6.172/gcc-cilkplus --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120618 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-E -quiet -v -iprefix /afs/csail.mit.edu/proj/\
courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/
-D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess
-o\
main.ii
ignoring nonexistent directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-\
linux-gnu/include
ignoring duplicate directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../inc\
lude/c++/4.8.0
ignoring duplicate directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../inc\
lude/c++/4.8.0/x86_64-unknown-linux-gnu
ignoring duplicate directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../inc\
lude/c++/4.8.0/backward
ignoring duplicate directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
ignoring duplicate directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
ignoring nonexistent directory
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x\
86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/opt/intel/composer_xe_2013.0.079/mkl/include
/opt/intel/composer_xe_2013.0.079/tbb/include
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
/usr/local/include
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-fpreprocessed main.ii -quiet -dumpbase main.c\
pp -mtune=generic -march=x86-64 -auxbase main -std=c++11 -version -o main.s
GNU C++ (GCC) version 4.8.0 20120618 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120618 (experimental), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
warning: GMP header version 5.0.2 differs from library version 4.3.2.
warning: MPFR header version 3.1.0 differs from library version 3.0.0-p3.
warning: MPC header version 0.9 differs from library version 0.8.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.8.0 20120618 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120618 (experimental), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
warning: GMP header version 5.0.2 differs from library version 4.3.2.
warning: MPFR header version 3.1.0 differs from library version 3.0.0-p3.
warning: MPC header version 0.9 differs from library version 0.8.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 9140df29c77763bd28b47359117a6952
In file included from
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 20:04:21 UTC --- (In reply to comment #13) class(child),allocatable :: infant allocate(infant,source=new_child()) ... the finalizer is called twice: Once at the end of the main program, and once through the _copy procedure (which is invoked by the ALLOCATE statement), I think. Not sure if this is the expected behavior. The invocation through the _copy wrapper is a bug for ALLOCATE. However, it's fine for a = b which invoke _copy. I believe _copy should use intent(inout) dst instead of intent(out) dest – and if needed (e.g. intrinsic assignment), _final should be called directly. Then one can also replace calloc and memset '\0' by a simple malloc. (Caveat: One should check that coarray components are properly handled; possibly, _copy also needs a coarray argument as _final has.) * * * Current FINAL-wrapper patch (submitted) - it is still preparatory and doesn't call finalization subroutines: http://gcc.gnu.org/ml/fortran/2012-11/msg00086.html See also draft patches at https://userpage.physik.fu-berlin.de/~tburnus/final/ and http://gcc.gnu.org/ml/fortran/2012-11/msg9.html
[Bug rtl-optimization/55489] [4.7/4.8 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 --- Comment #2 from Paolo Bonzini bonzini at gnu dot org 2012-11-27 20:27:09 UTC --- Author: bonzini Date: Tue Nov 27 20:26:57 2012 New Revision: 193867 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193867 Log: 2012-11-27 Paolo Bonzini pbonz...@redhat.com PR rtl-optimization/55489 * gcse.c (compute_transp): Precompute a canonical version of XEXP (x, 0), and pass it to canon_true_dependence. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gcse.c
[Bug rtl-optimization/55489] [4.7/4.8 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 --- Comment #3 from Paolo Bonzini bonzini at gnu dot org 2012-11-27 20:29:24 UTC --- Author: bonzini Date: Tue Nov 27 20:29:15 2012 New Revision: 193868 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193868 Log: 2012-11-27 Paolo Bonzini pbonz...@redhat.com PR rtl-optimization/55489 * gcse.c (compute_transp): Precompute a canonical version of XEXP (x, 0), and pass it to canon_true_dependence. * alias.c (init_alias_analysis): Fix allocation of reg_known_value. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/gcse.c
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #28 from David Edelsohn dje at gcc dot gnu.org 2012-11-27 20:42:06 UTC --- Is the executable size due to debugging information? Do the RPMs contain stripped executables? I do not know why your build is failing. It looks like a conflict due to your GMP installation.
[Bug target/55448] using const-reference SSE or AVX types leads to unnecessary unaligned loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55448 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-27 20:45:50 UTC --- I have proposed a patch on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02265.html It still needs a testcase from this bug but addresses this problem.
[Bug tree-optimization/55415] Early SRA produces unaligned complex types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55415 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-27 20:46:11 UTC --- I have proposed a patch on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02265.html
[Bug tree-optimization/54386] [4.8 Regression] Unaligned mem load wrongly generated for inlined inline/static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54386 --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-27 20:46:58 UTC --- I have proposed a patch on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02265.html Any testing, especially on strict-alignment platforms I do not have access to, would be very welcome.
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 --- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-27 20:47:21 UTC --- I have proposed a patch on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02265.html
[Bug c++/54560] g++ with --sysroot and -save-temps don't play nicely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560 --- Comment #3 from Etienne Le Sueur elesueur at vmware dot com 2012-11-27 21:25:47 UTC --- Ping. Any chance we can get this triaged? It breaks both ccache and distcc...
