[Bug fortran/42865] OpenMP threadprivate allocatable saved variable - seg fault
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-26 08:15 --- This is invalid, you violate the restrictions of the copyin clause. Page 101 talks about POINTER copyin arguments, not ALLOCATABLEs. See http://openmp.org/forum/viewtopic.php?f=7t=639 for more details. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42865
[Bug fortran/42866] ICE for REDUCTION with ALLOCATABLE array as variable on SECTIONS
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-26 09:14 --- Created an attachment (id=19708) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19708action=view) gcc45-pr42866.patch Patch I'm testing. BTW, the provided testcase is wrong, if more than one section is scheduled on the same thread, it will abort. The problem is that it overwrites the reduction array in each section rather than adds to it, so it can only succeed if each section is scheduled in a different thread. But scheduling of !$omp sections is implementation defined, there are no restrictions on that choice. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42866
[Bug fortran/42865] OpenMP threadprivate allocatable saved variable - seg fault
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-26 09:19 --- Another link http://openmp.org/forum/viewtopic.php?f=5t=7start=10#p292 (I knew I've raised this issue already before 3.0 standard was released). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42865
[Bug fortran/42866] ICE for REDUCTION with ALLOCATABLE array as variable on SECTIONS
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-26 09:48 --- Subject: Bug 42866 Author: jakub Date: Tue Jan 26 09:47:45 2010 New Revision: 156235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156235 Log: PR fortran/42866 * omp-low.c (expand_omp_sections): Only use single_pred if l2_bb is single_pred_p. * testsuite/libgomp.fortran/allocatable5.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/allocatable5.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42866
[Bug fortran/42866] ICE for REDUCTION with ALLOCATABLE array as variable on SECTIONS
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-26 09:51 --- Subject: Bug 42866 Author: jakub Date: Tue Jan 26 09:51:23 2010 New Revision: 156236 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156236 Log: PR fortran/42866 * omp-low.c (expand_omp_sections): Only use single_pred if l2_bb is single_pred_p. * testsuite/libgomp.fortran/allocatable5.f90: New test. Added: branches/gcc-4_4-branch/libgomp/testsuite/libgomp.fortran/allocatable5.f90 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/omp-low.c branches/gcc-4_4-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42866
[Bug fortran/42866] ICE for REDUCTION with ALLOCATABLE array as variable on SECTIONS
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-26 09:56 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42866
[Bug middle-end/42694] Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-26 09:57 --- Ugh, I don't like more switches. Instead I would say that using two sqrt calls instead of one pow call is always profitable if not optimizing for size and the target has an optab for sqrt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42694
[Bug middle-end/42694] Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-26 10:03 --- With my user of the compiler hat, I must say that I was also put off by the 3 new switches... fwiw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42694
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #6 from uramakrishna at gmail dot com 2010-01-26 10:08 --- This PR is perhaps related to a href=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42644;PR42644/a (equake problem) and a href=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130;PR42130/a (DealII problem), as it has the 2^32-1 values as well as unsigned int in the cloog output. -- uramakrishna at gmail dot com changed: What|Removed |Added CC||uramakrishna at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug c++/42870] New: [4.5 regression] __attribute__ ((dllexport)) produces broken linkage
testcase
test.cpp
#ifdef FOOBAR
#define ATTRIBUTE __attribute__ ((dllexport))
#else
#define ATTRIBUTE __attribute__ ((visibility (default)))
#endif
class ATTRIBUTE Sa {
public:
Sa()
{}
~Sa();
};
ATTRIBUTE Sa::~Sa()
{return;}
bool DllMain(void *a,void*b,int)
{
Sa s;
return true;
}
--
test2.cpp
class __attribute__((dllimport)) Sa {
public:
Sa()
{}
__attribute__((dllimport)) ~Sa();
};
Sa a;
bool DllMain(void *a,void*b,int)
{
Sa s;
return true;
}
the following are directives that gcc emit when given attribute is
__attribute__ ((dllexport))
surely it must emit _ZN2SaD1Ev symbol or linker cannot find this symbol.
.section .drectve
.ascii -export:_ZN2SaD2Ev
.ascii -export:_ZN2SaC1Ev
.ascii -export:_ZN2SaC2Ev
for now i workaround this using __attribute__ ((visibility (default)))
--
Summary: [4.5 regression] __attribute__ ((dllexport)) produces
broken linkage
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jojelino at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42870
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug c++/42870] [4.5 regression] __attribute__ ((dllexport)) produces broken linkage
--- Comment #1 from jojelino at gmail dot com 2010-01-26 10:41 --- Created an attachment (id=19709) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19709action=view) given __attribute__ ((dllexport)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42870
[Bug tree-optimization/35639] [4.3/4.4/4.5 Regression] -fprofile-generate = huge SCCs for PRE
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-01-26 10:43 --- New timings (I suppose machines get faster ...): GCC 4.3.4: tree PRE : 2.18 (68%) usr 0.04 (33%) sys 2.23 (66%) wall 972 kB ( 7%) ggc TOTAL : 3.22 0.12 3.36 13328 kB GCC 4.4.[01]: tree PRE : 0.63 (48%) usr 0.01 (20%) sys 0.66 (48%) wall 291 kB ( 3%) ggc GCC 4.4.[23]: tree PRE : 0.05 ( 7%) usr 0.00 ( 0%) sys 0.04 ( 5%) wall 261 kB ( 3%) ggc TOTAL : 0.72 0.04 0.77 10324 kB trunk: tree PRE : 0.03 ( 6%) usr 0.00 ( 0%) sys 0.03 ( 4%) wall 129 kB ( 2%) ggc TOTAL : 0.51 0.08 0.84 7674 kB I suppose the maximal set translation fixed this. WONTFIX for the 4.3 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Known to work|4.2.3 |4.2.3 4.4.2 4.5.0 Resolution||FIXED Target Milestone|4.3.5 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #4 from mateusz at loskot dot net 2010-01-26 11:00 --- (In reply to comment #3) But really you did report it to us rather than Ubuntu first as both are modified versions of GCC. (...) And this bug is invalid. I didn't know really. Thank you for the patient clarification. I forwarded it to Ubuntu (https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/512741) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug middle-end/37448] [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-26 11:35 --- Updated timings and memory: ~/bin/maxmem2.sh /usr/bin/time gcc-4.5 -S -o /dev/null lgwam.c 32.62user 1.48system 0:34.41elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+333822minor)pagefaults 0swaps total: 1333745 kB ~/bin/maxmem2.sh /usr/bin/time /space/rguenther/install/gcc-4.4.3/bin/gcc -S -o /dev/null lgwam.c 35.01user 1.54system 0:36.89elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+329139minor)pagefaults 0swaps total: 1306898 kB ~/bin/maxmem2.sh /usr/bin/time /space/rguenther/install/gcc-4.3.4/bin/gcc -S -o /dev/null lgwam.c 27.42user 1.83system 0:29.61elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 16inputs+0outputs (0major+374338minor)pagefaults 0swaps total: 1341721 kB ~/bin/maxmem2.sh /usr/bin/time /space/rguenther/install/gcc-4.2.3/bin/gcc -S -o /dev/null lgwam.c 15.33user 0.80system 0:16.31elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 256inputs+0outputs (2major+197427minor)pagefaults 0swaps total: 598733 kB time-report for 4.5 trunk (only interesting parts): expand: 6.72 (20%) usr 0.72 (26%) sys 7.45 (20%) wall 140609 kB (35%) ggc integrated RA : 8.56 (25%) usr 0.12 ( 4%) sys 8.76 (24%) wall 5151 kB ( 1%) ggc reload: 7.72 (23%) usr 0.22 ( 8%) sys 7.94 (21%) wall TOTAL : 34.17 2.7937.15 402913 kB memory-usage is still high compared to 4.2. At -O2 the picture is similar (memory peaks at 2.5GB): Execution times (seconds) garbage collection: 0.64 ( 0%) usr 0.00 ( 0%) sys 0.64 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 0.31 ( 0%) usr 0.08 ( 1%) sys 0.39 ( 0%) wall 20525 kB ( 3%) ggc callgraph optimization: 1.40 ( 1%) usr 0.03 ( 0%) sys 1.46 ( 1%) wall 639 kB ( 0%) ggc ipa cp: 0.20 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 9607 kB ( 1%) ggc ipa reference : 0.14 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.33 ( 0%) usr 0.00 ( 0%) sys 0.32 ( 0%) wall 199 kB ( 0%) ggc cfg cleanup : 0.92 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 0%) wall 1168 kB ( 0%) ggc trivially dead code : 0.92 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.86 ( 0%) usr 0.01 ( 0%) sys 0.88 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 2.69 ( 1%) usr 0.96 (12%) sys 3.94 ( 2%) wall 0 kB ( 0%) ggc df live regs : 7.15 ( 3%) usr 0.07 ( 1%) sys 7.13 ( 3%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.33 ( 2%) usr 0.06 ( 1%) sys 3.36 ( 1%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.85 ( 0%) usr 0.03 ( 0%) sys 0.88 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 6.31 ( 3%) usr 0.05 ( 1%) sys 12.84 ( 6%) wall 18222 kB ( 2%) ggc register information : 3.42 ( 2%) usr 0.00 ( 0%) sys 3.46 ( 2%) wall 0 kB ( 0%) ggc alias analysis: 1.14 ( 1%) usr 0.01 ( 0%) sys 1.17 ( 1%) wall 10447 kB ( 1%) ggc alias stmt walking: 4.39 ( 2%) usr 0.26 ( 3%) sys 4.53 ( 2%) wall 0 kB ( 0%) ggc register scan : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 7 kB ( 0%) ggc rebuild jump labels : 0.53 ( 0%) usr 0.00 ( 0%) sys 0.51 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.64 ( 0%) usr 0.35 ( 4%) sys 0.93 ( 0%) wall 23140 kB ( 3%) ggc lexical analysis : 0.30 ( 0%) usr 0.54 ( 7%) sys 0.88 ( 0%) wall 0 kB ( 0%) ggc parser: 0.69 ( 0%) usr 0.38 ( 5%) sys 1.09 ( 0%) wall 38129 kB ( 5%) ggc inline heuristics : 1.18 ( 1%) usr 0.01 ( 0%) sys 1.15 ( 1%) wall 29832 kB ( 4%) ggc integration : 3.42 ( 2%) usr 0.45 ( 6%) sys 3.66 ( 2%) wall 175322 kB (22%) ggc tree gimplify : 1.08 ( 1%) usr 0.09 ( 1%) sys 1.17 ( 1%) wall 104718 kB (13%) ggc tree eh : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.14 ( 0%) usr 0.01 ( 0%) sys 0.14 ( 0%) wall 11817 kB ( 1%) ggc tree CFG cleanup : 1.23 ( 1%) usr 0.00 ( 0%) sys 1.21 ( 1%) wall 60 kB ( 0%) ggc tree VRP : 3.08 ( 1%) usr 0.01 ( 0%) sys 3.09 ( 1%) wall 6719 kB ( 1%) ggc tree copy propagation : 1.22 ( 1%) usr 0.02 ( 0%) sys 1.14 ( 0%) wall 585 kB ( 0%) ggc tree find ref. vars : 0.11 ( 0%) usr 0.01 ( 0%) sys 0.12 ( 0%) wall 6045 kB ( 1%) ggc tree PTA : 0.62 ( 0%) usr 0.00 ( 0%) sys 0.68 ( 0%) wall 2178 kB ( 0%) ggc tree PHI insertion: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 185 kB ( 0%) ggc tree SSA rewrite : 2.92 ( 1%) usr 0.06 ( 1%) sys 3.04 ( 1%) wall 54148 kB ( 7%) ggc tree SSA other:
[Bug middle-end/37448] [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function
--- Comment #32 from rguenth at gcc dot gnu dot org 2010-01-26 11:44 --- Finally it finished. -O1: inline heuristics : 810.76 (63%) usr 4.58 (24%) sys 957.16 (53%) wall 0 kB ( 0%) ggc integrated RA : 115.69 ( 9%) usr 3.86 (20%) sys 290.09 (16%) wall 5979 kB ( 1%) ggc reload: 312.19 (24%) usr 4.99 (26%) sys 453.32 (25%) wall 5139 kB ( 1%) ggc TOTAL :1290.2019.28 1807.46 486943 kB ugh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug c++/42870] [4.5 regression] __attribute__ ((dllexport)) produces broken linkage
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-26 12:04 --- Please tell how you invoked gcc and what version works for you (and what the correspoding output is). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42870
[Bug target/42869] GOMP_critical_start wrong on Itanium due to __sync miscompilation
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-26 12:06 --- Please check trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||ia64-*-* Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
[Bug rtl-optimization/42863] [4.5 Regression] with auto increments
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |rtl-optimization Keywords||missed-optimization Priority|P3 |P4 Summary|[4.5] Regression with auto |[4.5 Regression] with auto |increments |increments Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42863
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-26 12:14 ---
Note the http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01282.html doesn't
bootstrap on the redhat/gcc-4_4-branch on ppc, while it bootstraps on the trunk
on x86_64-linux and i686-linux and on the branch on those arches too.
I will try to bootstrap trunk with that patch on ppc soon to see.
Anyway, the bootstrap problem can be simplified to:
typedef struct { char **b; int c[]; } T;
int a;
extern int d[], e;
extern char f[30];
static void
foo (unsigned *x, unsigned *y, int z)
{
int i;
for (i = 0; i z; i++)
x[i] = y[i / 2];
}
void
bar (T *y)
{
unsigned x[4];
foo (x, (unsigned *) d, e);
__builtin_memcpy (y-b [y-c[0]], f, a);
}
at -O2 -g -m64 this doesn't assemble, as .debug_loc contains:
.LLST3:
.8byte .LVL1-.Ltext0# Location list begin address (*.LLST3)
.8byte .LVL7-.Ltext0# Location list end address (*.LLST3)
.2byte 0x1 # Location expression size
.byte 0x59 # DW_OP_reg9
.8byte .LVL7-.Ltext0# Location list begin address (*.LLST3)
.8byte .LVL9-1-.Ltext0 # Location list end address (*.LLST3)
.2byte 0xc # Location expression size
.byte 0x72 # DW_OP_breg2
.byte 0x0 # sleb128 0
.byte 0x3 # DW_OP_addr
.8byte @toc
.byte 0x22 # DW_OP_plus
.8byte 0x0 # Location list terminator begin (*.LLST3)
.8byte 0x0 # Location list terminator end (*.LLST3)
and @toc isn't allowed in .8byte.
There is:
(insn 41 43 40 2 random.i:18 (set (reg/f:DI 9 9 [orig:148 d.0 ] [148])
(mem/u/c:DI (plus:DI (reg:DI 2 2)
(const:DI (unspec:DI [
(symbol_ref/u:DI (*.LC2) [flags 0x2])
] 49))) [7 S8 A8])) 350 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 2 2)
(expr_list:REG_EQUIV (symbol_ref:DI (d) [flags 0xc0] var_decl
0x7fdb7e28de60 d)
(nil
...
(debug_insn 47 46 48 2 random.i:18 (var_location:DI y (reg/f:DI 9 9 [orig:148
d.0 ] [148])) -1 (nil))
before var-tracking and apparently var-tracking doesn't consider that
REG_EQUIV, which leads to:
(note 142 75 89 5 (var_location y (expr_list:REG_DEP_TRUE (mem/u/c:DI (plus:DI
(reg:DI 2 2)
(const:DI (unspec:DI [
(symbol_ref/u:DI (*.LC2) [flags 0x2])
] 49))) [7 S8 A8])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug target/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #9 from andriys at gmail dot com 2010-01-26 12:16 --- Well, I have finally managed to build the trunk on Windows (mingw32). Now all test cases work fine for me without any patches (as of revision 156168 at least). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/42871] New: g++: Internal error: Segmentation fault (program cc1plus)
Line causing the error: g++ -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE -I/home/gabriel/Vigilance/3rdParty/ace/ACE_wrappers -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -I../../.. -c -o .obj/Sets.o Sets.cpp g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [.obj/Sets.o] Error 1 make[1]: Leaving directory `/home/gabriel/Vigilance/3rdParty/ace/ACE_wrappers/examples/APG/Containers' make: *** [Sets] Error 2 OS: CentOS release 5.4 (Final) GCC was built with no optional settings. This is the config.log output: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ ../gcc-4.4.3/configure ## - ## ## Platform. ## ## - ## hostname = VibeDEV.vibesec-hq.com uname -m = i686 uname -r = 2.6.18-164.9.1.el5PAE uname -s = Linux uname -v = #1 SMP Tue Dec 15 21:41:47 EST 2009 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/pgsql/bin PATH: /sbin PATH: /usr/local/ssl/bin PATH: /usr/lib/qt-3.3/bin PATH: /usr/kerberos/bin PATH: /usr/local/bin PATH: /bin PATH: /usr/bin PATH: /home/gabriel/bin ## --- ## ## Core tests. ## ## --- ## configure:1563: checking build system type configure:1581: result: i686-pc-linux-gnu configure:1616: checking host system type configure:1630: result: i686-pc-linux-gnu configure:1638: checking target system type configure:1652: result: i686-pc-linux-gnu configure:1696: checking for a BSD-compatible install configure:1762: result: /usr/bin/install -c configure:1773: checking whether ln works configure:1795: result: yes configure:1799: checking whether ln -s works configure:1803: result: yes configure:3002: checking for gcc configure:3018: found /usr/local/bin/gcc configure:3028: result: gcc configure:3274: checking for C compiler version configure:3277: gcc --version /dev/null 5 gcc (GCC) 4.4.3 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3280: $? = 0 configure:3282: gcc -v /dev/null 5 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.4.3/configure Thread model: posix gcc version 4.4.3 (GCC) configure:3285: $? = 0 configure:3287: gcc -V /dev/null 5 gcc: '-V' option must have argument configure:3290: $? = 1 configure:3313: checking for C compiler default output file name configure:3316: gccconftest.c 5 configure:3319: $? = 0 configure:3367: result: a.out configure:3372: checking whether the C compiler works configure:3378: ./a.out configure:3381: $? = 0 configure:3400: result: yes configure:3407: checking whether we are cross compiling configure:3409: result: no configure:3412: checking for suffix of executables configure:3414: gcc -o conftestconftest.c 5 configure:3417: $? = 0 configure:3444: result: configure:3450: checking for suffix of object files configure:3471: gcc -c conftest.c 5 configure:3474: $? = 0 configure:3498: result: o configure:3502: checking whether we are using the GNU C compiler configure:3526: gcc -c conftest.c 5 configure:3532: $? = 0 configure:3536: test -z || test ! -s conftest.err configure:3539: $? = 0 configure:3542: test -s conftest.o configure:3545: $? = 0 configure:3558: result: yes configure:3564: checking whether gcc accepts -g configure:3585: gcc -c -g conftest.c 5 configure:3591: $? = 0 configure:3595: test -z || test ! -s conftest.err configure:3598: $? = 0 configure:3601: test -s conftest.o configure:3604: $? = 0 configure:3615: result: yes configure:3632: checking for gcc option to accept ANSI C configure:3702: gcc -c -g -O2 conftest.c 5 configure:3708: $? = 0 configure:3712: test -z || test ! -s conftest.err configure:3715: $? = 0 configure:3718: test -s conftest.o configure:3721: $? = 0 configure:3739: result: none needed configure:3757: gcc -c -g -O2 conftest.c 5 conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'me' configure:3763: $? = 1 configure: failed program was: | #ifndef __cplusplus | choke me | #endif configure:3948: checking for g++ configure:3964: found /usr/local/bin/g++ configure:3974: result: g++ configure:3990: checking for C++ compiler version configure:3993: g++ --version /dev/null 5 g++ (GCC) 4.4.3 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-26 12:24 --- Severity should be normal and a testcase is needed to reproduce the problem. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Summary|g++: Internal error:|g++: Internal error: |Segmentation fault (program |Segmentation fault (program |cc1plus)|cc1plus) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #2 from gabriel at vibesec dot com 2010-01-26 12:28 --- The error occurs when building ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) with gcc 4.4.3 -- gabriel at vibesec dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug tree-optimization/42250] [4.5 Regression] segfault in ipa-type-escape.c for several cpu2000 tests
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-26 12:29 --- Subject: Bug 42250 Author: rguenth Date: Tue Jan 26 12:29:09 2010 New Revision: 156244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156244 Log: 2010-01-26 Richard Guenther rguent...@suse.de PR tree-optimization/42250 * ipa-type-escape.c (type_escape_execute): Do not analyze clones. * gcc.dg/pr42250.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr42250.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-type-escape.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42250
[Bug tree-optimization/42250] [4.5 Regression] segfault in ipa-type-escape.c for several cpu2000 tests
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-26 12:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42250
[Bug middle-end/37448] [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function
--- Comment #33 from rguenth at gcc dot gnu dot org 2010-01-26 12:33 --- The whole early-inlining stuff is made ugly because we jump through hoops to handle callgraph cycles where some callees may not yet be in SSA form. If we do not want to go the route to go into SSA for all functions before starting early IPA passes then we at least should do so for callgraph SCCs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug tree-optimization/42806] -fcompare-debug failure (length) at -O1 in recent builds
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-26 12:36 --- We decided to do different inlining. Huh. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-26 12:36:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-26 12:39 --- Created an attachment (id=19710) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19710action=view) gcc45-ppc64-pr42861.patch Untested patch that cures this testcase. Not sure if the constant pool special casing is needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug libgomp/42872] New: [4.5 regression] Revision 156232 failed many libgomp tests
On Linux/ia32, revision 156232: http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00700.html caused: FAIL: libgomp.fortran/allocatable1.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/allocatable1.f90 -Os (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/allocatable2.f90 -Os (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.38.1.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.40.1.f90 -O (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/character1.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/character1.f90 -Os (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/character2.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/character2.f90 -Os (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/crayptr1.f90 -Os (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/crayptr2.f90 -Os (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/lib1.f90 -Os (test for excess errors) FAIL: libgomp.fortran/lib2.f -O0 (test for excess errors) FAIL: libgomp.fortran/lib2.f
[Bug libgomp/42872] [4.5 regression] Revision 156232 failed many libgomp tests
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-26 13:06:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-26 13:26 --- Please provide a self-contained pre-processed (*.ii) file, per: http://gcc.gnu.org/bugs/#report -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug tree-optimization/42806] -fcompare-debug failure (length) at -O1 in recent builds
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-26 13:30 --- Because unsplit_all_eh () does sth different for # BLOCK 2 # PRED: ENTRY (fallthru,exec) S2::m (this_1(D)); # SUCC: 4 (eh,exec) 3 (fallthru,exec) # BLOCK 3 # PRED: 2 (fallthru,exec) L2: L0: return; # SUCC: EXIT # BLOCK 4 # PRED: 2 (eh,exec) L1: # DEBUG D#2 = this_1(D)-s1 # DEBUG this = D#2 # SUCC: 5 [100.0%] (fallthru,exec) # BLOCK 5 # PRED: 4 [100.0%] (fallthru,exec) L3: resx 1 # SUCC: compared to w/o debug insns. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-26 12:36:39 |2010-01-26 13:30:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug tree-optimization/42806] [4.5 Regression] -fcompare-debug failure (length) at -O1 in recent builds
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Summary|-fcompare-debug failure|[4.5 Regression] -fcompare- |(length) at -O1 in recent |debug failure (length) at - |builds |O1 in recent builds Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug libgomp/42872] [4.5 regression] Revision 156232 failed many libgomp tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872
[Bug libgomp/42872] [4.5 regression] Revision 156232 failed many libgomp tests
-- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|2010-01-26 13:06:30 |2010-01-26 13:45:02 date|| Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-26 13:49 --- Removing that special casing of CONSTANT_POOL_ADDRESS_P leads to invalid debug info, which points to a bug in dwarf2out.c :(, he difference is: .8byte .LVL7-.Ltext0 # Location list begin address (*.LLST3) .8byte .LVL9-1-.Ltext0 # Location list end address (*.LLST3) -.2byte 0xa # Location expression size +.2byte 0x9 # Location expression size .byte 0x3 # DW_OP_addr .8byte d -.byte 0x9f # DW_OP_stack_value .8byte 0x0 # Location list terminator begin (*.LLST3) .8byte 0x0 # Location list terminator end (*.LLST3) The problem is a weird optimization in mem_loc_descriptor for SYMBOL_REF. Replacing a SYMBOL_REF with a SYMBOL_REF get_pool_constant returned doesn't look right, because that is one indirection away. Say if get_pool_constant on .LC2 symbol returns d symbol, it means (mem (symbol_ref .LC2)) is (symbol_ref d), not that (symbol_ref .LC2) is the same as (symbol_ref d). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug libgomp/42872] [4.5 regression] Revision 156232 failed many libgomp tests
--- Comment #1 from bonzini at gnu dot org 2010-01-26 13:55 --- Testing this: Index: configure.ac === --- configure.ac(revision 156244) +++ configure.ac(working copy) @@ -146,7 +146,8 @@ case `echo $GFORTRAN` in -* | no* ) FC=no ;; *) -if test -x $GFORTRAN; then +set dummy $GFORTRAN; ac_word=$2 +if test -x $ac_word; then FC=$GFORTRAN else FC=no -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-26 14:04 --- Created an attachment (id=19711) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19711action=view) patch Candidate fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-26 14:05 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-21 16:47:22 |2010-01-26 14:05:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-26 14:11 --- Created an attachment (id=19712) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19712action=view) gcc45-constant_pool.patch Patch that cures this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug c++/42820] [4.5 Regression] ICE in tree-check, accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9868
--- Comment #3 from dodji at gcc dot gnu dot org 2010-01-26 14:12 --- Indeed. *** This bug has been marked as a duplicate of 42713 *** -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42820
[Bug c++/42713] [4.5 Regression] ICE - segfault in tsubst
--- Comment #5 from dodji at gcc dot gnu dot org 2010-01-26 14:12 --- *** Bug 42820 has been marked as a duplicate of this bug. *** -- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||marc dot glisse at ||normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42713
[Bug tree-optimization/42873] New: [4.5 Regression] deadlock in var tracking in recent builds
This can be related to pr41371, but I think it is not duplicate. This one ends in endless loop, as can be seen from -fdump-rtl-vartrack dumps - there are about 50 lines periodically repeating. I thought it's a dup of pr41371, but the compilation (of nonreduced testcase) didn't finish even after one week. Reduced testcase compilation finishes in miliseconds with -fno-var-tracking, but takes forever without it. It's not slowly eating memory, so it never crashes. Command line: gcc -O3 -g -fgcse-sm -ftracer testcase.c Tested revisions (x86_64): r156217 - fail r156038 - fail r155945 - fail (x86) r155920 - fail r155917 - fail r155902 - OK r155844 - OK (x86) r155833 - OK r155363 - OK r154886 - OK r153685 - OK 4.4 branch, r155365 - OK Output (manually terminated): $ time /mnt/svn/gcc-trunk/binary-155920-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 -v -O3 -g -fgcse-sm -ftracer testcase.c ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /mnt/svn/gcc-trunk/binary-155920-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /mnt/svn/gcc-trunk/binary-155920-lto/include /mnt/svn/gcc-trunk/binary-155920-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /mnt/svn/gcc-trunk/binary-155920-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. baz bar foo Analyzing compilation unit Performing interprocedural optimizations visibility *free_lang_data early_local_cleanups whole-program cp inline static-var pure-constAssembling functions: foo^C real76m32.295s user74m33.830s sys 0m0.730s -- Summary: [4.5 Regression] deadlock in var tracking in recent builds Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86(_64)-pc-linux-gnu GCC target triplet: x86(_64)-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42873
[Bug tree-optimization/42873] [4.5 Regression] deadlock in var tracking in recent builds
--- Comment #1 from zsojka at seznam dot cz 2010-01-26 14:19 --- Created an attachment (id=19713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19713action=view) reduced testcase Command line: gcc -O3 -g -fgcse-sm -ftracer pr42873.c -c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42873
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-26 14:25 --- I'm not completely sure that the tr1 version actually includes indirectly std::swap. Please check that and in case just add bits/move.h, is enough and works also in non-C++0x mode. Otherwise, you are cleared to commit at your ease (please remember to update the dependencies) Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #11 from rguenther at suse dot de 2010-01-26 14:34 --- Subject: Re: Revisit std::function for aliasing issues On Tue, 26 Jan 2010, paolo dot carlini at oracle dot com wrote: --- Comment #10 from paolo dot carlini at oracle dot com 2010-01-26 14:25 --- I'm not completely sure that the tr1 version actually includes indirectly std::swap. Please check that and in case just add bits/move.h, is enough and works also in non-C++0x mode. Otherwise, you are cleared to commit at your ease (please remember to update the dependencies) Actually the tr1 version does but the std version does not. I'll adjust that instead. What dependencies do you mean? richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-26 14:37 --- Are you sure? The std version should be fine, via utility (remember the std version is enabled *only* in C++0x mode). I mean the depends on and blocks fields. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #13 from rguenther at suse dot de 2010-01-26 14:57 --- Subject: Re: Revisit std::function for aliasing issues On Tue, 26 Jan 2010, paolo dot carlini at oracle dot com wrote: --- Comment #12 from paolo dot carlini at oracle dot com 2010-01-26 14:37 --- Are you sure? The std version should be fine, via utility (remember the std version is enabled *only* in C++0x mode). Ah, with -std=c++0x it's there indeed. I mean the depends on and blocks fields. Ok Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libgomp/42872] [4.5 regression] Revision 156232 failed many libgomp tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872
[Bug debug/42873] [4.5 Regression] deadlock in var tracking in recent builds
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |debug Ever Confirmed|0 |1 Known to fail||4.5.0 Known to work||4.4.3 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2010-01-26 15:02:37 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42873
[Bug tree-optimization/42806] [4.5 Regression] -fcompare-debug failure (length) at -O1 in recent builds
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-26 15:10 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug tree-optimization/42806] [4.5 Regression] -fcompare-debug failure (length) at -O1 in recent builds
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-26 15:10 --- Subject: Bug 42806 Author: rguenth Date: Tue Jan 26 15:09:43 2010 New Revision: 156249 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156249 Log: 2010-01-26 Richard Guenther rguent...@suse.de PR middle-end/42806 * tree-eh.c (unsplit_eh): Skip debug insns. * g++.dg/other/pr42806.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/other/pr42806.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug tree-optimization/42685] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops (2)
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-26 15:15 --- I have an extremely lame patch that fixes both testcases. s/INSN_P/NONDEBUG_INSN_P/ -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-18 17:00:13 |2010-01-26 15:15:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug libgomp/29986] testsuite failures
--- Comment #5 from ro at gcc dot gnu dot org 2010-01-26 15:35 --- I've found that the problem doesn't occur when assembler patch 118683-03 is installed. If I compare the relocations produced by as from patch 118683-02 with those produced by patch 118683-03, I find some differences (elfdump -r output): --- /vol/gcc/obj/gcc-4.5.0-20100107/10-gcc/sparc-sun-solaris2.10/libgomp/testsuite/ctor-5.elfdump-r 2010-01-26 16:19:54.304447900 +0100 +++ ctor-5.elfdump-r2010-01-26 16:19:48.584176600 +0100 @@ -21,10 +21,10 @@ R_SPARC_LO10 0x90 0 .rela.text _ZN1B5countE R_SPARC_HI22 0xc4 0 .rela.text _ZN1B8expectedE R_SPARC_LO10 0xc8 0 .rela.text _ZN1B8expectedE - R_SPARC_TLS_LE_HIX22 0xcc 0 .rela.text .tbss (section) - R_SPARC_TLS_LE_LOX10 0xd0 0 .rela.text .tbss (section) - R_SPARC_TLS_LE_HIX22 0xdc 0 .rela.text .tbss (section) - R_SPARC_TLS_LE_LOX10 0xe0 0 .rela.text .tbss (section) + R_SPARC_TLS_LE_HIX22 0xcc 0 .rela.text _ZL3thr + R_SPARC_TLS_LE_LOX10 0xd0 0 .rela.text _ZL3thr + R_SPARC_TLS_LE_HIX22 0xdc 0 .rela.text _ZL3thr + R_SPARC_TLS_LE_LOX10 0xe0 0 .rela.text _ZL3thr R_SPARC_HI22 0xf0 0x1a0 .rela.text .text (section) R_SPARC_LO10 0xf4 0x1a0 .rela.text .text (section) R_SPARC_WDISP30 0x100 0 .rela.text GOMP_parallel_start @@ -47,8 +47,8 @@ R_SPARC_WDISP30 0x1e0 0 .rela.text omp_get_num_threads R_SPARC_HI22 0x1ec 0 .rela.text _ZL8nthreads R_SPARC_LO10 0x1f0 0 .rela.text _ZL8nthreads - R_SPARC_TLS_LE_HIX22 0x208 0 .rela.text .tbss (section) - R_SPARC_TLS_LE_LOX10 0x20c 0 .rela.text .tbss (section) + R_SPARC_TLS_LE_HIX22 0x208 0 .rela.text _ZL3thr + R_SPARC_TLS_LE_LOX10 0x20c 0 .rela.text _ZL3thr R_SPARC_WDISP30 0x21c 0 .rela.text _ZN1BaSERKS_ Relocation Section: .rela.eh_frame In the broken object, the relocations are relative to the .tbss section, in the working one, they are relative to a symbol. I strongly suppose this is due to the fix for 6728528 assembler does not handle __thread code correctly although http://bugs.sun.com/view_bug.do?bug_id=6728528 doesn't provide much detail. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug c/42874] New: Error on correct code
The following testcase fails with:
sorry, unimplemented: function foo can never be copied because it uses
variable sized variables
When compiled with at least -O1. It works fine with GCC 4.4.3.
void __attribute__ ((always_inline))
foo (const unsigned long *addr, unsigned long size)
{
typedef struct
{
long x[size];
} addrtype;
addrtype *a = (void *) addr;
}
Unfortunately these patterns are quite common in the Linux kernel - at least
for S/390. They always used to compile but mainline currently is not able to
build the kernel.
--
Summary: Error on correct code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: krebbel at gcc dot gnu dot org
GCC build triplet: s390x-ibm-linux
GCC host triplet: s390x-ibm-linux
GCC target triplet: s390x-ibm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug c/42875] New: gcc disallows named initializers for anonymous unions
gcc-4.4.3 lets you statically initialize named fields, and lets you assign to
anonymous union members, but you cannot statically initialize a named member of
an anonymous union. This inconsistency between assignment and initialization
is surprising, and breaks some code I am porting from an EDG-based compiler to
gcc-4.4.3.
Let me emphasize that I don't claim this violates any official standard, since
these are language extensions. But it does violate the principle of least
surprise, since one would expect that the assignment and initialization
field namespaces would be the same, as with EDG.
Here is an example:
// Union with anonymous member.
union my_union
{
int my_int;
struct
{
short a, b;
};
};
// Works: gcc lets you initialize named fields.
union my_union
initialize_int()
{
union my_union x = { .my_int = 3 };
return x;
}
// Works: gcc lets you assign to anonymous union members.
union my_union
assign_anonymous_union(union my_union x)
{
x.a = 3;
return x;
}
// Fails: gcc does not let you initialize named members in anonymous unions.
union my_union
initialize_anonymous_union()
{
// Does not compile,
//
// foo.c: In function initialize_anonymous_union:
// foo.c:33: error: unknown field a specified in initializer
union my_union x = { .a = 3 };
return x;
}
--
Summary: gcc disallows named initializers for anonymous unions
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mat at lcs dot mit dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42875
[Bug middle-end/37448] [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function
--- Comment #34 from hubicka at ucw dot cz 2010-01-26 16:05 --- Subject: Re: [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function The whole early-inlining stuff is made ugly because we jump through hoops to handle callgraph cycles where some callees may not yet be in SSA form. Hmm, it don't seem to me that keeping the reverse postorder is bad idea here (not that going to SSA earlier would not be good idea for different reasons). Still top-down inliner needs to deal with cycles one way or another. I will take a look what is taking quadratic time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug c/42875] gcc disallows named initializers for anonymous unions
--- Comment #1 from mat at lcs dot mit dot edu 2010-01-26 16:25 --- *** This bug has been marked as a duplicate of 10676 *** -- mat at lcs dot mit dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42875
[Bug c/10676] Using unnamed fields in initializers
--- Comment #12 from mat at lcs dot mit dot edu 2010-01-26 16:25 --- *** Bug 42875 has been marked as a duplicate of this bug. *** -- mat at lcs dot mit dot edu changed: What|Removed |Added CC||mat at lcs dot mit dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug tree-optimization/42685] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops (2)
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-26 16:27 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug tree-optimization/42685] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops (2)
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-26 16:27 --- Subject: Bug 42685 Author: rguenth Date: Tue Jan 26 16:27:34 2010 New Revision: 156252 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156252 Log: 2010-01-26 Richard Guenther rguent...@suse.de PR rtl-optimization/42685 * web.c (web_main): Ignore DEBUG_INSNs. * gcc.dg/pr42685.c: New testcase. * g++.dg/other/pr42685.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/other/pr42685.C trunk/gcc/testsuite/gcc.dg/pr42685.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/web.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug c/10676] Using unnamed fields in initializers
--- Comment #13 from mat at lcs dot mit dot edu 2010-01-26 16:28 --- This bug is causing me difficulty porting from an EDG-based compiler to gcc-4.4.3. EDG implemented assignment and initialization as having the same namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug libgomp/29986] testsuite failures
--- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-26 16:31 --- (In reply to comment #5) I've found that the problem doesn't occur when assembler patch 118683-03 is installed. If this issue is fixed, perhaps you could add a note to: http://gcc.gnu.org/install/specific.html#x-x-solaris2 describe the bug and mention which patch fixes it, then close this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug c/10676] Using unnamed fields in initializers
--- Comment #14 from jsm28 at gcc dot gnu dot org 2010-01-26 16:32 --- C1x anonymous structures and unions will likely require a fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug c/4784] Anonymous structs issues
--- Comment #6 from jsm28 at gcc dot gnu dot org 2010-01-26 16:33 --- C1x anonymous structures and unions will likely require a fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4784
[Bug libgomp/29986] testsuite failures
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-26 16:38 --- Subject: Re: testsuite failures --- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-26 16:31 --- (In reply to comment #5) I've found that the problem doesn't occur when assembler patch 118683-03 is installed. If this issue is fixed, perhaps you could add a note to: http://gcc.gnu.org/install/specific.html#x-x-solaris2 describe the bug and mention which patch fixes it, then close this PR? Sure, will do. It's on my list. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug c/42876] New: Missed aliasing warnings
Hello, With the attached sample program I would expect aliasing warnings from the compiler (in function myfunc), which are not produced by GCC 4.4.3, as follows: $ gcc -Wall -Wextra vbsl.c -o vbsl -O0 [no message] $ ./vbsl vec4: vec[0]=0.00 vec[1]=0.00 vec4: vec[0]=2.10 vec[1]=2.20 $ gcc -Wall -Wextra vbsl.c -o vbsl -O3 vbsl.c: In function 'myfunc': vbsl.c:41: warning: 'result' is used uninitialized in this function [actually, 'result' is written to, so this warning is incorrect] $ ./vbsl vec4: vec[0]=0.00 vec[1]=0.00 vec4: vec[0]=0.00 vec[1]=0.00 [the result is different from -O0, as the compiler optmized the code] $ gcc -Wall -Wextra vbsl.c -o vbsl -O3 -Wstrict-aliasing vbsl.c: In function 'myfunc': vbsl.c:41: warning: 'result' is used uninitialized in this function [same message as above, while there are aliasing issues, which should be reported] $ gcc -Wall -Wextra vbsl.c -o vbsl -O3 -fmudflap -lmudflap [no message, ie mudflap cancels the 'unintialized' warning] $ ./vbsl vec4: vec[0]=0.00 vec[1]=0.00 vec4: vec[0]=2.10 vec[1]=0.00 [yet another different output, but no warning from mudflap] But: $ valgrind ./vbsl [using valgrind 3.5.0] vec4: vec[0]=0.00 vec[1]=0.00 vec4: vec[0]=2.10 ==27973== Conditional jump or move depends on uninitialised value(s) ==27973==at 0x30C754400C: __printf_fp (in /lib64/tls/libc-2.3.4.so) ==27973==by 0x30C754191A: vfprintf (in /lib64/tls/libc-2.3.4.so) ==27973==by 0x4A2005E: __mfwrap_printf (in xxx/lib64/libmudflap.so.0.0.0) ==27973==by 0x4011DB: main (in /home/lyon/tmp/bug-gcc/vbsl) The interactions between all these variants are a bit confusing. -- Summary: Missed aliasing warnings Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe dot lyon at st dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42876
[Bug c/42876] Missed aliasing warnings
--- Comment #1 from christophe dot lyon at st dot com 2010-01-26 17:02 --- Created an attachment (id=19714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19714action=view) Sample input code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42876
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-26 17:11 --- Created an attachment (id=19715) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19715action=view) gcc45-ppc-delegitimize.patch Updated ppc delegitimize patch (after the dwarf2out.c change there is no need to duplicate parts of avoid_constant_pool_reference there). I've bootstrapped/regtested this on the redhat/gcc-4_4-branch so far on powerpc64-linux --with-cpu=default32, all other arches pending. I'm also bootstrapping now the trunk on powerpc64-linux --with-cpu=default32 with Alexandre's patch to see whether the same issue can be reproduced on the trunk. bootstrap. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #19710|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-26 17:12 --- Created an attachment (id=19716) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19716action=view) gcc45-s390-delegitimize.patch And s390 patch I'm bootstrapping/regtesting too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug c++/42877] New: ICE when checking the type of a lambda
gcc-trunk (20100115)
template typename T struct toff;
template typename TR, typename... TA struct toffTR (*)(TA...) {
typedef TR type;
};
template typename TR, typename TC, typename... TA struct toffTR
(TC::*)(TA...) const {
typedef TR type;
};
template typename TR, typename TC, typename... TA struct toffTR
(TC::*)(TA...) {
typedef TR type;
};
template typename T void dem(T op) {
typedef typename toffdecltype(T::operator ())::type r_type;
}
int main(int argc, char *argv[]) {
dem([](int x){ return x; });
return 0;
}
$ g++ -std=gnu++0x br.cpp
br.cpp: In function 'void dem(T) [with T = main(int, char**)::lambda(int)]':
br.cpp:29:31: instantiated from here
br.cpp:23:64: internal compiler error: canonical types differ for identical
type
s int(int) and int(int)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE when checking the type of a lambda
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] ICE when checking the type of a lambda
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-26 17:29 --- probably a dup of Bug 42082 or Bug 42737 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] ICE when checking the type of a lambda
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-01-26 17:35 --- (In reply to comment #1) probably a dup of Bug 42082 or Bug 42737 Yes, it could be the case. BTW, Jason, is the presented way of discovering of the lambda function's return type correct in C++0x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #26 from aldot at gcc dot gnu dot org 2010-01-26 17:44 --- ping. Although nick's ChangeLog in comment #c15 mentiones the Use for MULTILIB_DEFAULTS the hunk in comment #22 and #24 did not end up in svn: * config/arm/linux-elf.h (TARGET_ENDIAN_DEFAULT): Define based on TARGET_BIG_ENDIAN_DEFAULT. Use for MULTILIB_DEFAULTS. (TARGET_DEFAULT): Set according to TARGET_ENDIAN_DEFAULT. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||pbrook at gcc dot gnu dot ||org Last reconfirmed|2005-01-12 01:47:12 |2010-01-26 17:44:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug c++/42877] [C++0x] ICE when checking the type of a lambda
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-26 17:58
---
The below is enough. I'm adding in CC Jason, in case the fix for these three
open issues turns out to be safe enough for 4.5.0.
//
template typename T struct toff;
template typename TR, typename TA struct toffTR (*)(TA)
{
typedef TR type;
};
template typename T void dem(T op)
{
typedef typename toffdecltype(T::operator ())::type r_type;
}
int main()
{
dem([](int x){ return x; });
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] [C++0x] ICE when checking the type of a lambda
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-01-26 18:07 --- I assume the original version is also intended to work with non-empty captures, when operator() is non-static -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] [C++0x] ICE when checking the type of a lambda
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-26 18:12 --- My hope is that the problem with canonical types is the same and localized in the C++0x bits of the front-end, across all the issues of this family, thus, to repeat, PR42082 and PR42737 too. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-26 18:12:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug tree-optimization/42878] New: -fcompare-debug failure at -O1 (2)
Command line: gcc -O1 -fcompare-debug -c testcase.c Tested revisions: r156253 - crash r155920 - crash r155833 - crash r155363 - crash r154886 - crash r154830 - OK r153685 - OK Output: $ /mnt/svn/gcc-trunk/binary-156253-lto/bin/gcc -O1 -fcompare-debug -c testcase.c gcc: testcase.c: -fcompare-debug failure -- Summary: -fcompare-debug failure at -O1 (2) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #1 from zsojka at seznam dot cz 2010-01-26 18:46 --- Created an attachment (id=19717) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19717action=view) reduced testcase Reduced from gcc/builtins.c Command line: gcc -O1 -fcompare-debug -c pr42878.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug c++/42768] ICE: libstdc++-v3/libsupc++/vec.cc:354
--- Comment #4 from peter at empeg dot com 2010-01-26 19:29 --- I get the same error on host=build=x86_64-linux, target=i586-mingw32. At least in my case, this is a regression in 4.4.3, as 4.4.2 worked fine. -- peter at empeg dot com changed: What|Removed |Added CC||peter at empeg dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug tree-optimization/42878] -fcompare-debug failure at -O1 (2)
--- Comment #2 from zsojka at seznam dot cz 2010-01-26 19:30 --- Created an attachment (id=19718) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19718action=view) different reduced testcase Reduced from gcc/builtins.c as well This testcase started failing between r154830 and r154886 as well, so I am not creating separate bugport for it. All tested revisions fail at -O1, -O2 and -O3. Command line: gcc -O1 -fcompare-debug -c pr42878-2.c or gcc -O2 -fcompare-debug -c pr42878-2.c or gcc -O3 -fcompare-debug -c pr42878-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42878
[Bug debug/42873] [4.5 Regression] deadlock in var tracking in recent builds
--- Comment #2 from zsojka at seznam dot cz 2010-01-26 19:41 --- Since http://gcc.gnu.org/viewcvs?view=revisionrevision=155917 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42873
[Bug c++/42877] [C++0x] ICE when checking the type of a lambda
--- Comment #6 from piotr dot wyderski at gmail dot com 2010-01-26 20:09 --- (In reply to comment #4) I assume the original version is also intended to work with non-empty captures, when operator() is non-static Yes, that's the purpose of the first two specializations. But that part works correctly, only the function ptr variant ICEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42870] [4.5 regression] __attribute__ ((dllexport)) produces broken linkage
--- Comment #3 from jojelino at gmail dot com 2010-01-26 22:02 --- Created an attachment (id=19719) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19719action=view) given __attribute__ ((visibility (default))) and test result (given __attribute__ ((dllexport)) ) $ gcc test.cpp -shared -o test.dll -Wl,--out-implib,test.dll.a -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-thr eads=posix --enable-languages=c,c++ --with-win32-nlsapi=unicode --enable-tls --d isable-bootstrap --enable-shared --disable-sjlj-exceptions Thread model: posix gcc version 4.5.0 20100126 (experimental) (GCC) COLLECT_GCC_OPTIONS='-shared' '-o' 'test.dll' '-v' '-mtune=generic' /usr/libexec/gcc/i686-pc-cygwin/4.5.0/cc1plus.exe -quiet -v -D__CYGWIN32__ -D__ CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.0 /../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../. ./../i686-pc-cygwin/lib/../../include/w32api test.cpp -quiet -dumpbase test.cpp -mtune=generic -auxbase test -version -o /cygdrive/d/Temp/cache/ccyU7ymf.s GNU C++ (GCC) version 4.5.0 20100126 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.5.0 20100120 (experimental), GMP version 4.3 .1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686 -pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../include/c++/4.5.0 /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../include/c++/4.5.0/i686-pc-cygwin /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../include/c++/4.5.0/backward /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.5.0/include /usr/lib/gcc/i686-pc-cygwin/4.5.0/include-fixed /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686-pc-cygwin/include /usr/include /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../include/w32api End of search list. GNU C++ (GCC) version 4.5.0 20100126 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.5.0 20100120 (experimental), GMP version 4.3 .1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: fb963511c7be306a48675197d8d9d6d7 COLLECT_GCC_OPTIONS='-shared' '-o' 'test.dll' '-v' '-mtune=generic' /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686-pc-cygwin/bin/as -o /cygdriv e/d/Temp/cache/ccbLebdC.o /cygdrive/d/Temp/cache/ccyU7ymf.s COMPILER_PATH=/usr/libexec/gcc/i686-pc-cygwin/4.5.0/:/usr/libexec/gcc/i686-pc-cy gwin/4.5.0/:/usr/libexec/gcc/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/4.5.0/: /usr/lib/gcc/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686- pc-cygwin/bin/ LIBRARY_PATH=/usr/lib/gcc/i686-pc-cygwin/4.5.0/:/usr/lib/gcc/i686-pc-cygwin/4.5. 0/../../../../i686-pc-cygwin/lib/:/usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../:/l ib/:/usr/lib/ COLLECT_GCC_OPTIONS='-shared' '-o' 'test.dll' '-v' '-mtune=generic' /usr/libexec/gcc/i686-pc-cygwin/4.5.0/collect2.exe --wrap _Znwj --wrap _Znaj -- wrap _ZdlPv --wrap _ZdaPv --wrap _ZnwjRKSt9nothrow_t --wrap _ZnajRKSt9nothrow_t --wrap _ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t --shared -Bdynamic --ena ble-auto-image-base -e __cygwin_dll_en...@12 --dll-search-prefix=cyg -tsaware -o test.dll /usr/lib/gcc/i686-pc-cygwin/4.5.0/crtbegin.o -L/usr/lib/gcc/i686-pc-cy gwin/4.5.0 -L/usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686-pc-cygwin/lib -L /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../.. /cygdrive/d/Temp/cache/ccbLebdC.o --o ut-implib test.dll.a -lgcc_s -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshe ll32 -lgcc_s -lgcc /usr/lib/gcc/i686-pc-cygwin/4.5.0/crtend.o Creating library file: test.dll.a and for test2.dll $ gcc test2.cpp -shared -o test2.dll -Wl,--out-implib,test2.dll.a -v -L. -ltest Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-thr eads=posix --enable-languages=c,c++ --with-win32-nlsapi=unicode --enable-tls --d isable-bootstrap --enable-shared --disable-sjlj-exceptions Thread model: posix gcc version 4.5.0 20100126 (experimental) (GCC) COLLECT_GCC_OPTIONS='-shared' '-o' 'test2.dll' '-v' '-L.' '-mtune=generic' /usr/libexec/gcc/i686-pc-cygwin/4.5.0/cc1plus.exe -quiet -v -D__CYGWIN32__ -D__ CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.0 /../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../. ./../i686-pc-cygwin/lib/../../include/w32api test2.cpp -quiet -dumpbase test2.cp p -mtune=generic -auxbase test2 -version -o /cygdrive/d/Temp/cache/ccjQ1IbV.s GNU C++ (GCC) version 4.5.0 20100126
[Bug middle-end/42874] [4.5 Regression] Error on correct code: sorry, unimplemented: function �foo� can never be copied because it uses
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-26 22:32 --- We can't inline it. The sorry() is from #0 sorry ( gmsgid=0x8be6a24 function %q+F can never be copied because it uses variable sized variables) at /home/richard/src/trunk/gcc/diagnostic.c:639 #1 0x087dde5e in tree_inlinable_function_p (fn=0xb77a6e00) at /home/richard/src/trunk/gcc/tree-inline.c:3041 #2 0x087a2dc6 in compute_inline_parameters (node=0xb773b2e0) at /home/richard/src/trunk/gcc/ipa-inline.c:1865 #3 0x087a2ec0 in compute_inline_parameters_for_current () at /home/richard/src/trunk/gcc/ipa-inline.c:1882 #4 0x0842644f in execute_one_pass (pass=0x8d22d80) at /home/richard/src/trunk/gcc/passes.c:1561 just drop the always_inline attribute. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||rejects-valid Summary|Error on correct code: |[4.5 Regression] Error on |sorry, unimplemented: |correct code: sorry, |function foo can never be |unimplemented: function |copied because it uses |foo can never be copied ||because it uses Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-26 22:33 --- The trunk powerpc64-linux --with-cpu=default32 bootstrap died too, this time in libsupc++/eh_alloc.cc compilation with -m64, again because of .8byte .l...@toc in .debug_loc. I'm going to bootstrap/regtest the patches on the trunk/powerpc64-linux now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug testsuite/41701] scan-assembler-not has false positives
--- Comment #1 from meissner at gcc dot gnu dot org 2010-01-26 23:46 --- Created an attachment (id=19720) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19720action=view) Patch to fix my particular problem with builtins-58.c This patch fixes the particular problem I ran into that causes gcc.dg/builtins-58.c to fail when the pathname to the compiler contains the string 'pow' as in .../power7-meissner/ which is the sandbox that I use for power7 work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41701
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #15 from iwamatsu at nigauri dot org 2010-01-26 23:54 --- (In reply to comment #10) (In reply to comment #9) So I took the opportunity to cleanup every other occurrences of the same idioms in the file. OK ? OK. Thanks! Thanks for your patch! I confirmed that problem on other program was fixed with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42879] New: Replace tst r3, 1 with lsl r3, r3, 31 in thumb2
Compile the following c++ code with options -march=armv7-a -mthumb -Os
struct A
{
bool v:1;
};
bool bar();
bool foo(struct A* p)
{
if (p-v)
return true;
return bar();
}
Gcc generates
_Z3fooP1A:
push{r3, lr}
.save {r3, lr}
.LCFI0:
ldrbr3, [r0, #0]@ zero_extendqisi2
tst r3, #1
bne .L3
bl _Z3barv
b .L2
.L3:
movsr0, #1
.L2:
pop {r3, pc}
The tst r3, #1 is a 32 bit instruction, it can be replaced by a 16 bit
instruction lsl r3, r3, 31 while still retain the original semantics.
--
Summary: Replace tst r3, 1 with lsl r3, r3, 31 in thumb2
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #4 from gabriel at vibesec dot com 2010-01-27 07:11 --- Created an attachment (id=19721) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19721action=view) self-contained pre-processed (Sets.ii) in TAR GZ format -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
