[Bug c++/50671] New: NSDMI not parsed correctly for multiple-data-member declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50671
Bug #: 50671
Summary: NSDMI not parsed correctly for multiple-data-member
declarations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
The new NSDMI support seems to work generally, but the following gives a syntax
error:
struct X { int i = 3, j = 4; };
$ g++-snapshot -c -std=c++0x i.cc
i.cc:1:21: error: expected ';' before ',' token
It certainly seems like this _should_ be valid code, and the clang trunk
compiles it fine.
If I split the declaration, like struct X { int i = 3; int j = 4; }, gcc
compiles it as expected.
$ g++-snapshot --version
g++ (Debian 20111008-1) 4.7.0 20111008 (experimental) [trunk revision 179709]
Thanks,
-miles
[Bug tree-optimization/50622] [4.7 Regression] ICE: verify_gimple failed for std::complexdouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
Severity|normal |blocker
--- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-10-09 08:40:07 UTC ---
reduced to this (no std)
typedef __complex__ double Value;
struct LorentzVector
{
LorentzVector operator+=(const LorentzVector a) {
theX += a.theX;
theY += a.theY;
theZ += a.theZ;
theT += a.theT;
return *this;
}
Value theX;
Value theY;
Value theZ;
Value theT;
};
inline LorentzVector
operator+(LorentzVector a, const LorentzVector b) {
return a += b;
}
Value ex, et;
LorentzVector sum() {
LorentzVector v1; v1.theX =ex; v1.theY =ex+et; v1.theZ =ex-et; v1.theT =et;
return v1+v1;
}
c++ -O2 -c ice47c.cc
ice47c.cc: In function ‘LorentzVector sum()’:
ice47c.cc:24:15: error: invalid rhs for gimple memory store
a$theX
v1$theX
# .MEM_53 = VDEF .MEM_13
a$theX = v1$theX;
ice47c.cc:24:15: error: invalid rhs for gimple memory store
a$theY
v1$theY
# .MEM_54 = VDEF .MEM_53
a$theY = v1$theY;
ice47c.cc:24:15: error: invalid rhs for gimple memory store
a$theZ
v1$theZ
# .MEM_55 = VDEF .MEM_54
a$theZ = v1$theZ;
ice47c.cc:24:15: error: invalid rhs for gimple memory store
a$theT
v1$theT
# .MEM_56 = VDEF .MEM_55
a$theT = v1$theT;
ice47c.cc:24:15: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/50671] [C++0x] NSDMI not parsed correctly for multiple-data-member declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50671 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 09:15:17 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 50563 ***
[Bug c++/50563] [C++0x] Weird syntax acceptance rules for non-static data members initialized in place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50563 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||miles at gnu dot org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 09:15:17 UTC --- *** Bug 50671 has been marked as a duplicate of this bug. ***
[Bug target/50603] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x32 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg00547.htm ||l Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2011-10-09 09:30:09 UTC --- (In reply to comment #6) It doesn't work since we fail to decompose subreg. The question here is, why combine creates: Failed to match this instruction: (set (mem:SI (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4])) 0) (subreg:DI (reg:SI 106) 0)) (const_int 4294967292 [0xfffc])) [0 MEM[symbol: x, index: D.2741_1, step: 4, offset: 4294967292B]+0 S4 A32]) (reg/v:SI 85 [ i ])) Considering that this is in fact zero-extension, the optimized pattern is worse than sticking subreg to the whole address, i.e. (and:DI (subreg:DI (plus:SI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4])) (reg:SI 106)) 0) (const_int 4294967295 [0x])) Please note that we have registers in two different modes in the former pattern. The later pattern would be recognized by i386.c code. Anyway, the original problem is solved, instead of hijacking exisiting PR, please open a new PR (IMO, RTL optimization).
[Bug fortran/43829] Scalarization of reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #44 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com 2011-10-09 09:48:00 UTC ---
Dear Mikael,
I have duly loaded up your patch - it looks very slick and
professional; it even works as intended!
This is included in the patch in comment #41. Unfortunately, it makes the test
(comment #42) fail with -Os in the testsuite. I don't know yet how I will
handle it. I would like to avoid forcing one optimization level if possible.
Any idea?
I confirm you finding:
FAIL: gfortran.dg/function_optimize_7.f90 -O scan-tree-dump-times
original sum_r4 1
FAIL: gfortran.dg/inline_sum_1.f90 -Os (test for excess errors)
FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
FAIL: gfortran.dg/select_type_12.f03 -O (test for excess errors)
Running /svn/trunk/gcc/testsuite/gfortran.dg/gomp/gomp.exp ...
Running /svn/trunk/gcc/testsuite/gfortran.dg/graphite/graphite.exp ...
Running /svn/trunk/gcc/testsuite/gfortran.dg/guality/guality.exp ...
Running /svn/trunk/gcc/testsuite/gfortran.dg/lto/lto.exp ...
Running /svn/trunk/gcc/testsuite/gfortran.dg/vect/vect.exp ...
Running /svn/trunk/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp
...
Running /svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp
...
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2
-fomit-frame-pointer -finline-functions -funroll-loops
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2
-fbounds-check
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O3 -g
FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2
-ftree-vectorize -msse2
The function_optimize_7.f90 failure is obviously trivial. Both the
select_type_12.f03 and the entry_4.f90 failures have crept in during
the last few days and appear to be some middle-end fault.
As for your inline_sum_1.f90: The failure here is dues to extra
temporary array warnings with -Os. I tried switching on and off the
extra optimizations in Os versus O2 but could not identify the
culprit. That said, the test runs correctly with -Os.
What I would do is to double up the test; one with { dg-do compile }
and -Warray-temporaries and trhe other with { dg-do run } only.
Cheers
Paul
[Bug c++/50672] New: ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Bug #: 50672 Summary: ice: verify_ssa failed: no immediate_use list Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 25448 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25448 C++ source code I just tried to compile the ddd-3.3.12 package on latest trunk snapshot 20111008 on an AMD x86_64 box. The compiler said ArcGraphE.C: In member function 'void ArcGraphEdge::makeLine(Widget, const BoxRegion, std::ostream, const GraphGC) const': ArcGraphE.C:97:6: error: no immediate_use list for SSA_NAME: .MEM_986 in statement: # .MEM_597 = VDEF .MEM_986 LineGraphEdge::drawLine (D.34902_152, w_151(D), exposed_153(D), gc_154(D)); ArcGraphE.C:97:6: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required.
[Bug c++/50660] warning about pass NULL to non pointer argument happens twice for template function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 10:20:24 UTC --- On it.
[Bug libobjc/49883] clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:29:54 UTC --- Author: nicola Date: Sun Oct 9 10:29:50 2011 New Revision: 179721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179721 Log: In libobjc/: 2011-10-09 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49883 * init.c (__objc_exec_class): Work around a bug in clang's code generation. Clang sets the class-info field to values different from 0x1 or 0x2 (the only allowed values in the traditional GNU Objective-C runtime ABI) to store some additional information, but this breaks backwards compatibility. Wipe out all the bits in the fields other than the first two upon loading a class. 2011-10-09 Nicola Pero nicola.p...@meta-innovation.com * class.c (objc_lookup_class): Added back for compatibility with clang which seems to emit calls to it. Modified: trunk/libobjc/ChangeLog trunk/libobjc/class.c trunk/libobjc/init.c
[Bug libobjc/49883] clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:31:04 UTC --- Fixed in trunk. Thanks
[Bug c++/50660] warning about pass NULL to non pointer argument happens twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Summary|warning about pass NULL to |warning about pass NULL to
|non pointer argument|non pointer argument
|happens twice for template |happens twice
|function call |
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09
10:42:19 UTC ---
Note, happens twice also for non-template:
int g(const int);
int m2()
{
return g(__null);
}
[Bug libobjc/50003] -[Protocol respondsTo:] does not work with Clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50003
Nicola Pero nicola at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:47:11
UTC ---
With GCC trunk (pre-4.7.0), the code reported can't be used because it's using
the Traditional Objective-C runtime API and not the Modern one.
The right implementation with the Modern API is:
+ (BOOL)conformsToProtocol: (Protocol*)protocol
{
Class c;
for (c = self; c != Nil; c = class_getSuperclass (c))
if (class_conformsToProtocol (c, protocol))
return YES;
return NO;
}
I tested this with both GCC and clang, and it seems to work fine with both.
Thanks
[Bug libobjc/50368] Implicit, precision losing cast in objc/objc-api.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50368 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nicola at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:50:47 UTC --- Florian, thanks a lot for your report. You are right that there is a loss-precision cast in there. :-) But the function class_get_version() was part of the Traditional API, which was deprecated in GCC 4.6.1 and has been removed in trunk (ie, GCC 4.7.0). So, the function class_get_version() (and the entire file objc/objc-api.h) will no longer exist in GCC 4.7.0, which implicitly fixes your problem. :-) Thanks again!
[Bug libfortran/50673] New: very slow I/O with trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50673 Bug #: 50673 Summary: very slow I/O with trailing spaces Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following testcase (derived from CP2K, which required 20min to read a 600Mb file) is about 100x times slower with gfortran than with ifort (12.0.4) CHARACTER(LEN=40480) :: line=O 0.12456789 0.123456789 0.123456789 CHARACTER(LEN=2) :: AA REAL*8 :: vec(3) DO i=1,1 read(line,*) AA,vec ENDDO END The issue seems related to how efficient the trailing spaces are handled in both compilers. 4.7 is a bit (20%) slower than 4.3, but nothing fundamental. Profiling the code shows that most time is spent in next_char, mem_read, memcpy, eat_spaces.
[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 --- Comment #12 from janus at gcc dot gnu.org 2011-10-09 11:34:25 UTC --- Author: janus Date: Sun Oct 9 11:34:21 2011 New Revision: 179723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179723 Log: 2011-10-09 Janus Weil ja...@gcc.gnu.org PR fortran/50659 * expr.c (replace_symbol): Only do replacement if the symbol is a dummy. 2011-10-09 Janus Weil ja...@gcc.gnu.org PR fortran/50659 * gfortran.dg/proc_decl_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c/50669] no warning for unused globals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50669 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-09 11:38:34 UTC --- The variable is exported, so it is not known to be unused.
[Bug lto/50666] bad error reporting for TMPDIR full
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50666 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-09 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-09 11:40:30 UTC --- Confirmed. collect2 has similar issues.
[Bug bootstrap/50665] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50665 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/50667] [4.7 Regression] FAIL: gcc.c-torture/execute/vshuf-* on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50667 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-09 11:41:21 UTC --- Looks like a dup of PR50665.
[Bug bootstrap/50674] New: [4.7 Regression] profiledbootstrap broken: corrupted profile info: sum_all is smaller than sum_max
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50674 Bug #: 50674 Summary: [4.7 Regression] profiledbootstrap broken: corrupted profile info: sum_all is smaller than sum_max Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de On x86_64-pc-linux-gnu I get bootstrap errors with --with-build-config=bootstrap-lto and make profiledbootstrap: /var/tmp/gcc_build_dir/./prev-gcc/g++ -B/var/tmp/gcc_build_dir/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/gcc/libstdc++-v3/libsupc++ -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -march=native -O2 -pipe -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -DHAVE_CONFIG_H -I. -Ic-family -I../../gcc/gcc -I../../gcc/gcc/c-family -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber../../gcc/gcc/c-family/stub-objc.c -o c-family/stub-objc.o ../../gcc/gcc/c-family/stub-objc.c: In function ‘objc_maybe_warn_exceptions(unsigned int)’: ../../gcc/gcc/c-family/stub-objc.c:463:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/gcc/c-family/stub-objc.c: In function ‘objc_finish_function()’: ../../gcc/gcc/c-family/stub-objc.c:463:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/gcc/c-family/stub-objc.c: In function ‘objc_check_format_arg(tree_node*, tree_node*)’: ../../gcc/gcc/c-family/stub-objc.c:463:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/gcc/c-family/stub-objc.c: In function ‘objc_string_ref_type_p(tree_node*)’: ../../gcc/gcc/c-family/stub-objc.c:463:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/gcc/c-family/stub-objc.c: In function ‘objc_write_global_declarations()’: ... or: var/tmp/gcc_build_dir/./prev-gcc/g++ -B/var/tmp/gcc_build_dir/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/gcc/libstdc++-v3/libsupc++ -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -march=native -O2 -pipe -flto=jobserver -frandom-seed=1 -fprofile-use -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o init.o -MT init.o -MMD -MP -MF .deps/init.Tpo ../../gcc/libcpp/init.c /usr/bin/gmsgfmt --statistics -o po/zh_TW.gmo ../../gcc/libcpp/po/zh_TW.po 210 translated messages. 178 translated messages, 23 fuzzy translations, 9 untranslated messages. ../../gcc/libcpp/init.c: In function ‘post_options(cpp_reader*)’: ../../gcc/libcpp/init.c:734:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/libcpp/init.c: In function ‘cpp_finish(cpp_reader*, _IO_FILE*)’: ../../gcc/libcpp/init.c:734:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/libcpp/init.c: In function ‘read_original_directory(cpp_reader*)’: ../../gcc/libcpp/init.c:734:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/libcpp/init.c: In function ‘read_original_filename(cpp_reader*)’: ../../gcc/libcpp/init.c:734:1: error: corrupted profile info: sum_all is smaller than sum_max ../../gcc/libcpp/init.c: In function ‘cpp_read_main_file(cpp_reader*, char const*)’: ...
[Bug libfortran/50673] very slow I/O with trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50673 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-10-09 12:04:55 UTC --- Actually, since eating the trailing spaces is the issue (seems to be implemented very generally in libfortran), the following is a practical workaround in this case: read(line(1:LEN_TRIM(line)),*) AA,vec maybe something along these lines could be done in the runtime ?
[Bug c/50675] New: master and single OpenMP constructs broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50675
Bug #: 50675
Summary: master and single OpenMP constructs broken
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: markflorisso...@gmail.com
single and master do not work properly in loops. They are either not executed
as often as they should, or the program deadlocks entirely:
#include stdio.h
int main(int argc, char **argv) {
int i;
#pragma omp parallel
{
for (i = 0; i 10; i++) {
#pragma omp single
puts(hello);
}
}
return 0;
}
This program deadlocks in gcc 4.4 and 4.6, whereas in 4.2 is is only executed 4
times (which is the number of cores on my machine). The same goes for the
master construct.
[Bug c++/50672] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-09 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 12:31:46 UTC --- Can you try to reduce the testcase somewhat, maybe helping yourself with 'delta'? http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction Thanks.
[Bug c++/48665] type of const member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 12:33:43 UTC --- Ian, can I have your opinion about this patch? Thanks in advance!
[Bug tree-optimization/50622] [4.7 Regression] ICE: verify_gimple failed for std::complexdouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 12:42:38 UTC --- Thanks Vincenzo. Doesn't happen for __complex__ float, doesn't happen for 4 components, thus seems related to the size of the struct.
[Bug lto/50676] New: Partitioning may fail with presence of static variables referring to function labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 Bug #: 50676 Summary: Partitioning may fail with presence of static variables referring to function labels Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org Noticed the bug while preparing -fno-topelvel-reorder patch for Andi. With WIP version of patch I got following failure building Mozilla: /tmp/ccPpJShB.ltrans29.ltrans.o:ccPpJShB.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.7094572: error: undefined reference to +'.L79667' /tmp/ccPpJShB.ltrans29.ltrans.o:ccPpJShB.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.7094572: error: undefined reference to +'.L79668' /tmp/ccPpJShB.ltrans29.ltrans.o:ccPpJShB.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.7094572: error: undefined reference to +'.L79669' /tmp/ccPpJShB.ltrans29.ltrans.o:ccPpJShB.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.7094572: error: undefined reference to +'.L79670' /tmp/ccPpJShB.ltrans29.ltrans.o:ccPpJShB.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.7094572: error: undefined reference to +'.L79671' We will need artificial testcase for that that is bit tricky because it involves putting function into one partition and its local static variable into another, but clearly ipa-reference is not recording the cases where address of local label is taken and thus partitioning happily breaks such code. Honza
[Bug rtl-optimization/50677] New: volatile forces load into register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677
Bug #: 50677
Summary: volatile forces load into register
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Host: x86_64-linux-gnu
Compiling this simple program (-Ofast):
void f(int volatile*i){++*i;}
produces this code:
movl(%rdi), %eax
addl$1, %eax
movl%eax, (%rdi)
(or incl %eax for the central line with -Os).
However, if I remove volatile, I get the nicer:
addl$1, (%rdi)
(or incl (%rdi) with -Os).
The second version seems legal to me even in the volatile case, is that wrong?
There might be a relation to this thread:
http://gcc.gnu.org/ml/gcc/2011-10/msg6.html
(no volatile there, but a failure to fuse load+add+store)
This is particularly noticable because people (wrongly) use volatile for
threaded code and the 3 instruction version is likely even more racy than the
one with a single instruction.
(sorry if the category is wrong, I just picked one with optimization in the
name...)
[Bug ada/50678] New: [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 Bug #: 50678 Summary: [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ebotca...@libertysurf.fr Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Between revisions 179635 (OK) and 179703 (fails) the acats test c52104y has started to fail on x86_64-apple-darwin10 (it is one of the three failing tests on powerpc-apple-darwin9). The failure is: splitting /opt/gcc/build_w/gcc/testsuite/ada/acats/tests/c5/c52104y.ada into: c52104y.adb BUILD c52104y.adb gnatmake --GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ -gnatws -O2 -fstack-check -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support c52104y.adb -largs --GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/build_w/gcc/xgcc -c -B/opt/gcc/build_w/gcc/ -gnatws -O2 -fstack-check -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support c52104y.adb gnatbind -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support -x c52104y.ali gnatlink c52104y.ali -O2 -fstack-check --GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ RUN c52104y ,.,. C52104Y ACATS 2.5 11-10-08 14:57:10 C52104Y CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS, THE LENGTHS MUST MATCH. - C52104Y NO CONSTRAINT_ERROR FOR NON-NULL ARRAY SUBTYPE WHEN ONE DIMENSION HAS INTEGER'LAST + 3 COMPONENTS. raised CONSTRAINT_ERROR : erroneous memory access FAIL: c52104y
[Bug lto/50676] Partitioning may fail with presence of static variables referring to function labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-10-09 13:04:28 UTC --- Have a look at PR50620. I can provide 30 different testcases for this issue ;-).
[Bug lto/50676] Partitioning may fail with presence of static variables referring to function labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2011-10-09 13:17:58 UTC --- Have a look at PR50620. I can provide 30 different testcases for this issue ;-). Those are different problems (i.e. not involving labels with address taken). I will look into that now. Honza
[Bug lto/50620] undefined reference errors / csmith lto testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50620 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-09 13:28:40 UTC --- The problem here is different than one in PR50620. What happens is that we ship constructors of const static variables into every partition that reffers to that to aid possible folding of loads from the var. The constructor of variable pointing to g_331 gets shipped to ltrans1 even when it is otherwise in other partition. Eventually we fold and place direct reference to g_331 into code, but the logic promoting symbols hidden doesn't really consider this posibility, so we end up with undefined reference. I guess the whole promotion code will need some cleanups and updating - first the logic is all duplicated in between lto.c and lto-cgraph.c and it is O(n^2), and second it is not really easy to tweak it to solve this problem - it is based on the fact that only funcions/variable sin the partition may cause promotion, while the variable pointing to g_331 is not in ltrans1. Honza
[Bug bootstrap/50674] [4.7 Regression] profiledbootstrap broken: corrupted profile info: sum_all is smaller than sum_max
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50674 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-10-09 13:35:26 UTC --- Git bisect points to Rev179701: f480372230f4bfc55d02b48322ed5c96e999d7e0 is the first bad commit commit f480372230f4bfc55d02b48322ed5c96e999d7e0 Author: rth rth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Oct 7 22:41:48 2011 + Rename vshuffle/vec_shuffle to vec_perm. * doc/extend.texi (__builtin_shuffle): Improve the description to include the modulus of the selector. Mention OpenCL. * doc/md.texi (vec_perm, vec_perm_const): Document named patterns. * tree.def (VEC_PERM_EXPR): Rename from VEC_SHUFFLE_EXPR. * genopinit.c (optabs): Rename vshuffle to vec_perm. * c-typeck.c (c_build_vec_perm_expr): Rename from c_build_vec_shuffle_expr. Update for name changes. * optabs.c (expand_vec_perm_expr_p): Rename from expand_vec_shuffle_expr_p. (expand_vec_perm_expr): Rename from expand_vec_shuffle_expr. * optabs.h (OTI_vec_perm): Rename from DOI_vshuffle. (vec_perm_optab): Rename from vshuffle_optab. * expr.c, gimple-pretty-print.c, gimple.c, gimplify.c, c-tree.h, c-parser.c, tree-cfg.c, tree-inline.c, tree-pretty-print.c, tree-ssa-operands.c, tree-vect-generic.c: Update for name changes. * config/i386/i386.c (ix86_expand_vec_perm): Rename from ix86_expand_vshuffle. * config/i386/i386-protos.h: Update. * config/i386/sse.md (VEC_PERM_AVX2): Rename from VSHUFFLE_AVX2. (vec_permVEC_PERM_AVX2): Rename from vshuffleVSHUFFLE_AVX2. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@179701 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/10200] Weird clash with same names in different scopes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #17 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:34:27 UTC --- Still happens with gcc 4.5.1.
[Bug c++/15272] lookup, dependent base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15272 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #7 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:36:06 UTC --- Still happens with gcc4.5.1.
[Bug c++/6936] member using binds wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6936 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #2 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:38:29 UTC --- Still happens with gcc4.5.1. Note that it doesn't matter which of the variables are accessed since it's a name lookup problem and name lookup happens before access control checking.
[Bug c/50675] master and single OpenMP constructs broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50675 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-09 13:41:54 UTC --- User error. The i variable is shared in your testcase, thus different threads may encounter #pragma omp single different number of times, which is invalid. Just use #pragma omp parallel private (i) or declare i inside of the #pragma omp parallel block instead.
[Bug c/50675] master and single OpenMP constructs broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50675 --- Comment #2 from markflorisson88 markflorisson88 at gmail dot com 2011-10-09 13:46:27 UTC --- Indeed, you are right. My apologies, I should teach myself to use default(none).
[Bug c++/11814] Code with missing template keyword wrongly accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #12 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:52:05 UTC --- Still happens with gcc4.5.1.
[Bug lto/50679] New: Linux kernel LTO tracking bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679 Bug #: 50679 Summary: Linux kernel LTO tracking bug Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Meta bug to track various problems encountered while building the Linux kernel with LTO
[Bug c++/10291] error referencing a static local from a local struct in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #9 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:55:10 UTC --- Still happens with gcc4.5.1.
[Bug c++/6936] member using binds wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6936 fabien at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2006-09-03 21:39:27 |2011-10-09 21:39:27 Known to fail||4.5.1, 4.6.0 --- Comment #3 from fabien at gcc dot gnu.org 2011-10-09 13:54:21 UTC --- (In reply to comment #2) Still happens with gcc4.5.1. ... And on 4.6, 4.7 as well.
[Bug c++/10852] Old for-scoping rules improperly used?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10852 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #6 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:59:42 UTC --- Still happens for gcc4.5.1.
[Bug c++/11814] Code with missing template keyword wrongly accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-09 14:01:26 UTC --- and 4.7.0
[Bug lto/50679] Linux kernel LTO tracking bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679 ak at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from ak at gcc dot gnu.org 2011-10-09 14:06:44 UTC --- urrently I have to revert 2 patches to get anywhere near a build and work around 50644. 32bit builds don't work at all because of the tree-nrv problem. 50620 causes incredly slow builds because partitioning has to be disabled
[Bug lto/50620] undefined reference errors / csmith lto testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50620 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot ||org --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-09 14:33:18 UTC --- I see a similar problem in a large LTO build (at least Honza thinks it's the same)
[Bug c++/42768] ICE: libstdc++-v3/libsupc++/vec.cc:354
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-09 CC|gcc-bugs at gcc dot gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 14:34:09 UTC --- Is this still an issue?
[Bug c++/43566] Debug information removed on last bracket of function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43566 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 14:35:37 UTC --- Jakub, can you help triaging this?
[Bug c++/44650] internal compiler error: in ei_container, at basic-block.h:687
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.0, 4.6.1, 4.7.0 Resolution||FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 14:39:35 UTC --- Works fine with 4.6.x.
[Bug c++/49912] [4.7 Regression] ICE from -freorder-blocks-and-partition : verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49912 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-09 CC||rguenth at gcc dot gnu.org Summary|ICE from|[4.7 Regression] ICE from |-freorder-blocks-and-partit |-freorder-blocks-and-partit |ion : verify_flow_info |ion : verify_flow_info |failed |failed Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 14:45:24 UTC --- This is a regression. Looking for a more appropriate Component categorization..
[Bug c++/50672] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 --- Comment #2 from dcb dcb314 at hotmail dot com 2011-10-09 14:55:29 UTC --- (In reply to comment #1) Can you try to reduce the testcase somewhat, maybe helping yourself with 'delta'? http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction I tried for an hour or so to get 'delta' to do something useful. I failed. Feel free to have a go yourself.
[Bug c++/49525] [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.0, 4.6.1, 4.7.0 Resolution||WORKSFORME --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:00:06 UTC --- Can't reproduce with current 4_4-branch, 4_5-branch, 4_6-branch, and mainline.
[Bug c++/46727] [4.4 Regression] ICE with -O3 and -ffast-math (in get_callee_fndecl, at tree.c:6857)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46727 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|spamverdacht at aon dot at | Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:01:59 UTC --- Fixed then.
[Bug c++/50672] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:04:34 UTC --- I already felt free, I asked because without a manageable testcase it gonna take more time, be warned.
[Bug tree-optimization/50635] ICE on valid: segfault in vectorize_loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50635 --- Comment #4 from irar at gcc dot gnu.org 2011-10-09 15:09:04 UTC --- Author: irar Date: Sun Oct 9 15:09:00 2011 New Revision: 179724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179724 Log: PR tree-optimization/50635 * tree-vect-patterns.c (vect_handle_widen_mult_by_const): Add DEF_STMT to the list of statements to be replaced by the pattern statements. (vect_handle_widen_mult_by_const): Don't check TYPE_OUT. Added: trunk/gcc/testsuite/gcc.dg/vect/pr50635.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug c++/43922] internal compiler error: in copy_body_r, at tree-inline.c:748 when compiling with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43922 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot | |gnu.org,| |stephan.ai...@fu-berlin.de | Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:10:22 UTC --- 4.3.x is not maintained anymore. Also, no *.ii
[Bug objc++/48394] ObjC exceptions cannot be caught in ObjC++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48394 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||nicola at gcc dot gnu.org Component|c++ |objc++ --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:16:27 UTC --- Nicola, this one was miscategorized as C++. Can you help triaging it?
[Bug c++/49976] Cross (Linux-AIX) GCC crashes with Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49976 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||dje at gcc dot gnu.org Severity|major |normal --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:18:49 UTC --- David, can you help triaging this? Or find somebody willing to?
[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:22:48 UTC --- Jason, I guess we need a final word about the triage of this.
[Bug c++/48686] ICE in extract_insn, at recog.c:2103 with -ftree-vectorize and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48686 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.0, 4.6.1, 4.7.0 Resolution||FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:27:38 UTC --- Works fine with current 4_5-branch, 4.6.x, mainline.
[Bug c++/50672] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-10-09 15:28:16 UTC ---
% cat test.ii
namespace std {
templateclass _CharT struct char_traits;
typedef struct __locale_struct {
}
*__locale_t;
templatetypename _CharT, typename _Traits = char_traits_CharT class
basic_ostream;
typedef basic_ostreamchar ostream;
}
class UniqueId {
};
typedef int BoxCoordinate;
typedef int BoxDimension;
const BoxDimension X = 0;
const BoxDimension Y = 1;
const BoxDimension NDimensions = 2;
class BoxPoint {
protected: BoxCoordinate point[NDimensions];
public: BoxPoint(BoxCoordinate x, BoxCoordinate y) {
}
bool isValid() const {
}
void operator += (const BoxPoint p) {
if (isValid() p.isValid()) {
point[X] += p.point[X];
}
}
BoxCoordinate operator [] (const BoxDimension dimension) {
return point[dimension];
}
};
class BoxSize: public BoxPoint {
};
class BoxRegion {
private: BoxPoint _origin;
BoxSize _space;
public: BoxRegion(const BoxPoint o, const BoxSize s) : _origin(o),
_space(s) {
}
BoxCoordinate origin(BoxDimension d) {
}
BoxCoordinate space(BoxDimension d) {
}
};
inline bool operator = (const BoxPoint p, const BoxRegion r) {
for (BoxDimension d = X;
d = Y;
d++) if (p[d] r.origin(d) || p[d] = r.origin(d) +
r.space(d)) return false;
return true;
}
extern C {
typedef struct _WidgetRec *Widget;
}
struct GraphGC {
BoxPoint offsetIfSelected;
};
class GraphNode;
class Graph;
class GraphEdge {
private: UniqueId _id;
GraphNode *_from;
GraphNode *_to;
bool _hidden;
GraphEdge *_nextFrom;
GraphEdge *_nextTo;
GraphEdge *_prevFrom;
GraphEdge *_prevTo;
GraphEdge *next;
GraphEdge *prev;
Graph *graph;
public: GraphEdge(GraphNode *f, GraphNode *t): _id(), _from(f),
_to(t), _hidden(false), _nextFrom(0), _nextTo(0),
_prevFrom(0), _prevTo(0), next(0), prev(0), graph(0) {
}
GraphNode *from() const {
}
GraphNode *to() const {
}
};
class LineGraphEdge: public GraphEdge {
protected: static void findLine(const BoxPoint c1, const BoxPoint c2,
const BoxRegion b1, const BoxRegion b2, BoxPoint p1, BoxPoi
nt p2, const GraphGC gc);
virtual void drawLine(Widget w, const BoxRegion exposed,
const GraphGC gc) const;
public: void _print(std::ostream os, const GraphGC gc) const;
};
class ArcGraphEdge: public LineGraphEdge {
static bool center(const BoxPoint p1, const BoxPoint p2,
const BoxPoint p3, double x, double y);
void makeLine(Widget w, const BoxRegion exposed, std::ostream
os, const GraphGC gc) const;
};
class GraphNode {
public: int count;
bool selected() {
}
GraphEdge *firstTo() const {
}
GraphEdge *nextTo(GraphEdge *ref) const;
virtual const BoxPoint pos() const = 0;
virtual const BoxRegion region(const GraphGC gc) const = 0;
virtual bool isHint() const {
}
};
class PosGraphNode: public GraphNode {
};
class RegionGraphNode: public PosGraphNode {
};
class HintGraphNode: public RegionGraphNode {
};
void ArcGraphEdge::makeLine(Widget w,const BoxRegion exposed,
std::ostream os,const GraphGC gc) const {
HintGraphNode *arc_hint = 0;
RegionGraphNode *arc_from = 0;
RegionGraphNode *arc_to = 0;
bool make_arc = true;
if (from()-isHint() to()-isHint()) {
make_arc = false;
}
else if (from()-isHint() from()-firstTo() != 0) {
if (arc_hint == 0 || arc_from == 0 || arc_to == 0 ||
arc_hint-nextTo(arc_hint-firstTo()) != 0) {
make_arc = false;
}
}
if (!make_arc) {
if (w != 0) LineGraphEdge::drawLine(w, exposed, gc);
else LineGraphEdge::_print(os, gc);
return;
}
BoxPoint pos_from = arc_from-pos();
BoxRegion region_from = arc_from-region(gc);
BoxPoint pos_to = arc_to-pos();
BoxRegion region_to = arc_to-region(gc);
BoxPoint pos_hint = arc_hint-pos();
if (arc_hint-selected()) {
pos_hint += gc.offsetIfSelected;
}
if (pos_hint =
[Bug c++/50672] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-10-09 15:31:43 UTC --- Created attachment 25449 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25449 reduced testcase Copy paste didn't work. Here is an attachment.
[Bug c++/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenther at suse dot de Summary|ice: verify_ssa failed: no |[4.7 Regression] ice: |immediate_use list |verify_ssa failed: no ||immediate_use list --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:38:39 UTC --- Thanks Markus. Looks like a regression, and should be better categorized.
[Bug c++/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW
[Bug c++/32614] -fmessage-length documentation and implementation disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32614 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 15:54:30 UTC --- Tom? If I don't hear from you, I'll go ahead and do what Manuel suggested... No point in keeping this open for 4 years!
[Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 16:00:17 UTC --- Not sure to understand which is the current status of this. Should it be simply *skipped* instead of *xfailed* on such targets?
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-09 16:00:41 UTC --- (In reply to comment #4) So, the best method is to disable front-end optimization within a forall loop. I assume the same holds for DO CONCURRENT. I think do concurrent is OK - here, the same as with a DO loop applies -- only the user has to guarantee that the loop will yield the same result independent of the execution order of the bounds. However, I think the current FE optimization might have problems with threadsafety. Assume: !$OMP parallel do default(share) do i = 1, 5 A(i) = 5*cos(B(i))+8*cos(B(i)) end do If one now transforms this into: !$OMP parallel do default(share) do i = 1, 5 tmp = cos(B(i)) A(i) = 5*tmp+8*tmp end do one has a problem as tmp is shared. Thus, one needs to make sure that all inserted temporary variables are thread private (DECL_THREAD_LOCAL_P).
[Bug fortran/43829] Scalarization of reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829 --- Comment #45 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-09 16:01:27 UTC --- Thanks. One comment: I think you will increase the binary size by inlining the reduction. Could you consider keeping the current libgfortran version and protecting the scalarization by if (!optimize_size) When compiling the test in comment #43 with -O2, the size of the a.out file is [macbook] f90/bug% ll a.out -rwxr-xr-x 1 dominiq staff 17752 Oct 9 17:55 a.out* with -Os it is [macbook] f90/bug% ll a.out -rwxr-xr-x 1 dominiq staff 30216 Oct 9 17:54 a.out* Are these numbers misleading, or once again compiling for size does not give the smallest size?
[Bug c++/43913] error: ‘expression error’ is not a valid template argument for type ‘int’ because it is a non-constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43913 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 16:08:23 UTC --- This is fixed in 4.6.x.
[Bug preprocessor/46444] termination of preprocessing by cpp when no include file is found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46444 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||tromey at gcc dot gnu.org Component|c++ |preprocessor --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 16:11:50 UTC --- I suspect this is not going to happen. In any case, a preprocessor issue.
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-09 16:14:43 UTC --- (In reply to comment #5) one has a problem as tmp is shared. Thus, one needs to make sure that all inserted temporary variables are thread private (DECL_THREAD_LOCAL_P). Actually, it probably works as one declares tmp as BLOCK in the DO loop, which presumably generates a thread-private variable.
[Bug tree-optimization/50680] New: -ftree-vectorizer-verbose does not report about basic block SLP (attempt of) vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50680
Bug #: 50680
Summary: -ftree-vectorizer-verbose does not report about
basic block SLP (attempt of) vectorization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in this example compiled with
c++ -Ofast -ftree-vectorizer-verbose=7 -c slp.cc -mtune=corei7 -msse4.2
it reports only about loop, voop,aoop, not about the equivalently
(not)-vectorized code in foo,voo,aoo
This makes debug/optmization of basic block SLP difficult
(it took me a while to understand why foo is not vectorized!)
float * __restrict__ x;
float * __restrict__ y;
float * __restrict__ z;
float v1[4],v2[4],v3[4];
struct A {
float a[4];
}; // __attribute__ ((aligned(16)));
A a1, a2, a3;
void foo ()
{
float * __restrict__ pin = x[0];
float * __restrict__ pout =y[0];
*pout++ = *pin++;
*pout++ = *pin++;
*pout++ = *pin++;
*pout++ = *pin++;
}
void voo() {
float * __restrict__ pin = v1[0];
float * __restrict__ pout =v2[0];
*pout++ = *pin++;
*pout++ = *pin++;
*pout++ = *pin++;
*pout++ = *pin++;
}
void aoo() {
float * __restrict__ pin = a1.a[0];
float * __restrict__ pout =a2.a[0];
*pout++ = *pin++;
*pout++ = *pin++;
*pout++ = *pin++;
*pout++ = *pin++;
}
void loop() {
for (int i=0;i!=4;++i) x[i]=y[i]+z[i];
}
void voop() {
for (int i=0;i!=4;++i) v1[i]=v2[i]+v3[i];
}
void aoop() {
for (int i=0;i!=4;++i) a1.a[i]=a2.a[i]+a3.a[i];
}
[Bug c++/39164] [C++0x] defaulted dtor redefinition not caught
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39164 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jason at gcc dot gnu.org| Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 16:16:01 UTC --- Fixed then.
[Bug c++/39043] C++ compiler doesn't optimize inlined function call for PIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39043 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 16:17:03 UTC --- Thus, invalid?
[Bug c/50669] no warning for unused globals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50669 --- Comment #2 from Jon Grant jg at jguk dot org 2011-10-09 16:44:18 UTC --- I could understand this for libraries. However, when linking as an executable binary, could the global really be still exported?
[Bug fortran/43829] Scalarization of reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829 --- Comment #46 from Mikael Morin mikael at gcc dot gnu.org 2011-10-09 16:44:19 UTC --- (In reply to comment #45) Are these numbers misleading, or once again compiling for size does not give the smallest size? Well, to begin with, I don't think the test is close to a real world case. It initializes a couple of arrays, and then applies to them various computations involving sum which it basically throws away afterwards. I wouldn't be surprised if some of the computations could be optimized away or shared between the different checks. I'm purely speculating here, but that would explain the size difference between inlined and then removed code vs kept around library call. Checks like this (for example) are good candidates for removal: if (any(sum(sum(a,1),1) /= sum(sum(a,2),1))) call abort
[Bug lto/50679] Linux kernel LTO tracking bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-10-09 17:11:52 UTC --- I've no problems building the kernel with LTO at the moment, but I use no modules and a fairly minimal config. I've seen a few strange segfaults while testing the LTO kernel however. For example: screen[1608]: segfault at 7fff42d73e98 ip 0040600a sp 7fff42d73ea0 error 6 in screen[40+55000] or zsh[1643]: segfault at 7f7980eb4000 ip 7f7981db6cb0 sp 7fff1f4b6dd8 error 7 in libc-2.14.90.so[7f7981d34000+15f000] But I'm not 100% sure, that they're really LTO related.
[Bug bootstrap/50674] [4.7 Regression] profiledbootstrap broken: corrupted profile info: sum_all is smaller than sum_max
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50674 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug rtl-optimization/50677] volatile forces load into register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-09 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-09 17:36:30 UTC --- Well, the issue is that most optimization passes just don't do anything for volatile qualified accesses. That's a safe thing. Deciding what kind of optimizations are allowed for volatile accesses might introduce bugs, and sofar the consensus was volatile? don't bother with optimization, it'll be slow anyway. It very likely is combine that gives up here.
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 17:36:12 UTC --- Fixed in 4.5.x.
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #7 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-10-09 18:10:37 UTC --- Am 09.10.2011 18:14, schrieb burnus at gcc dot gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #6 from Tobias Burnusburnus at gcc dot gnu.org 2011-10-09 16:14:43 UTC --- (In reply to comment #5) one has a problem as tmp is shared. Thus, one needs to make sure that all inserted temporary variables are thread private (DECL_THREAD_LOCAL_P). Actually, it probably works as one declares tmp as BLOCK in the DO loop, which presumably generates a thread-private variable. Could you supply a complete test case? I'd like to check this out, but# I don't use OpenMP myself.
[Bug fortran/50627] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Summary|[OOP] Error recovery: ICE |Error recovery: ICE in |in gfc_free_namespace after |gfc_free_namespace after |properly diagnosing bogus |diagnosing missing end of |SELECT TYPE in MODULE |construct --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-10-09 18:12:31 UTC --- Simpler test case: ig25@linux-fd1f:~/Krempel/OMP cat block.f90 program main block end program main ig25@linux-fd1f:~/Krempel/OMP gfortran block.f90 block.f90:3.3: end program main 1 Error: Expecting END BLOCK statement at (1) Error: Unexpected end of file in 'block.f90' f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3259 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/50681] New: A constexpr identifier in a header file generates undefined symbols in object code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50681
Bug #: 50681
Summary: A constexpr identifier in a header file generates
undefined symbols in object code.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fetrov...@gmail.com
kMaxValue in class template Cursor generates an undefined symbol in the object
code. Since the value isn't defined anywhere else, I get an undefined symbol
error from the linker.
templatetypename Type = int
class Cursor {
public:
typedef std::pairType, Type Pair;
private:
Pair _position;
public:
static Type constexpr kMaxValue =
std::numeric_limitsType::max();
Cursor(Pair const size = Pair(kMaxValue, kMaxValue)):
_position(size.first, size.first) {}
};
Example usage:
class UI {
private:
Cursor _cursor;
public:
virtual Cursor::Pair GetSize() {
return make_pair(0, 0);
}
};
int main() {
return UI().GetSize().first;
}
Linker message:
x.cpp:(.text._ZN2UIC2Ev[_ZN2UIC5Ev]+0x1c): undefined reference to
`Cursorint::kMaxValue'
x.cpp:(.text._ZN2UIC2Ev[_ZN2UIC5Ev]+0x21): undefined reference to
`Cursorint::kMaxValue'
[Bug c++/50681] A constexpr identifier in a header file generates undefined symbols in object code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50681 Feto Fetrovsky at gmail dot com changed: What|Removed |Added URL||http://ideone.com/kfs6n CC||Fetrovsky at gmail dot com Severity|normal |major
[Bug c++/50681] [C++0x] A constexpr identifier in a header file generates undefined symbols in object code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50681 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|A constexpr identifier in a |[C++0x] A constexpr |header file generates |identifier in a header file |undefined symbols in object |generates undefined symbols |code. |in object code. --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 18:37:56 UTC --- Yes, you still need a definition, constexpr or not.
[Bug tree-optimization/50682] New: [4.7 Regression] ICE: SIGSEGV in main_block_label with -O2 -fnon-call-exceptions -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50682 Bug #: 50682 Summary: [4.7 Regression] ICE: SIGSEGV in main_block_label with -O2 -fnon-call-exceptions -ftracer Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25450 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25450 reduced testcase Compiler output: $ gcc -O2 -fnon-call-exceptions -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce testcase.C ==3654== Invalid read of size 4 ==3654==at 0xB65233: main_block_label(tree_node*) (tree-cfg.c:1082) ==3654==by 0xB6965E: cleanup_dead_labels() (tree-cfg.c:) ==3654==by 0xBBA2EC: execute_cleanup_cfg_post_optimizing() (tree-optimize.c:162) ==3654==by 0xA62BF7: execute_one_pass(opt_pass*) (passes.c:2064) ==3654==by 0xA62F64: execute_pass_list(opt_pass*) (passes.c:2119) ==3654==by 0xBBACFD: tree_rest_of_compilation(tree_node*) (tree-optimize.c:420) ==3654==by 0x815EE5: cgraph_expand_function(cgraph_node*) (cgraphunit.c:1805) ==3654==by 0x817E2B: cgraph_optimize() (cgraphunit.c:1864) ==3654==by 0x818219: cgraph_finalize_compilation_unit() (cgraphunit.c:1312) ==3654==by 0x64266A: cp_write_global_declarations() (decl2.c:4008) ==3654==by 0xB58803: toplev_main(int, char**) (toplev.c:581) ==3654==by 0x674ED2C: (below main) (in /lib64/libc-2.12.2.so) ==3654== Address 0x50 is not stack'd, malloc'd or (recently) free'd ==3654== testcase.C: In function 'void test01()': testcase.C:29: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. Tested revisions: r179711 - crash r178498 - crash 4.6 r177922 - OK
[Bug fortran/50627] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2011-10-09 19:11:14 UTC --- For the problem in comment #0: As we parse select type, we create a new namespace. The statement is (correctly) rejected, but we don't free the namespace. Then we are back parsing module content, and the code doing that assumes that gfc_current_namespace points to the module namespace, which is not the case anymore (it points to the select namespace). I assume that the problem in comment #3 is of the same kind: We parse some block content, encounter end of file, then are back at parsing the main program unit with gfc_current_ns still pointing to the block namespace.
[Bug c++/31147] increased size of debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 19:27:19 UTC --- I don't see why we should keep this open.
[Bug c++/33758] g++: Internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33758 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-09 19:29:40 UTC --- Closing.
[Bug c/50669] no warning for unused globals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50669 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-09 19:34:48 UTC --- (In reply to comment #2) I could understand this for libraries. However, when linking as an executable binary, could the global really be still exported? Yes. In fact this is how plugins work in GCC.
[Bug fortran/45044] Different named COMMON block size: No warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-09 19:37:52 UTC --- Author: burnus Date: Sun Oct 9 19:37:47 2011 New Revision: 179729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179729 Log: 2011-10-09 Tobias Burnus bur...@net-b.de PR fortran/45044 * trans-common.c (translate_common): Fix -Walign-commons check. 2011-10-09 Tobias Burnus bur...@net-b.de PR fortran/45044 * gfortran.dg/common_14.f90: Compile with -Wno-align-commons. * gfortran.dg/common_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/common_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/common_14.f90
[Bug rtl-optimization/50677] volatile forces load into register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-09 19:48:39 UTC --- This is a dup of an older bug too though I cannot find it right now. Also it is related to bug 49807.
[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Comment #4 from janus at gcc dot gnu.org 2011-10-09 20:31:34 UTC ---
How about this?
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 179723)
+++ gcc/fortran/expr.c (working copy)
@@ -4635,7 +4635,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe
sym-name, context, e-where);
return FAILURE;
}
- if (!pointer !is_pointer)
+ if (!pointer !sym-attr.pointer)
{
if (context)
gfc_error (Dummy argument '%s' with INTENT(IN) in variable
[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-09 20:39:47 UTC --- (In reply to comment #4) How about this? Looks as if should work (for comment 0). (I think the test case in comment 2 is a completely different issue, which needs a separate fix.)
[Bug rtl-optimization/34791] [avr] optimisation of 8-bit logic sometimes fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34791
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target|avr-*-* |avr
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-09
20:40:51 UTC ---
Compiled the following code from commant #0 and commant #1 with avr-gcc 4.7
(SVN 179594)
#define uint8_t unsigned char
#define PORTC (*((uint8_t volatile*) 0x28))
extern uint8_t data[64];
uint8_t bar(uint8_t x, uint8_t y) {
return data[y ^ (x 0x0f)];
}
uint8_t bar2(uint8_t x, uint8_t y) {
return data[(y ^ x) 0x0f];
}
void foo(void) {
static unsigned char count;
if (++count 0x3f) {
PORTC = ~0x01;
} else {
PORTC |= 0x01;
}
}
With -Os -dp yields the following result:
bar:
andi r24,lo8(15)
eor r24,r22
mov r30,r24
ldi r31,lo8(0)
subi r30,lo8(-(data))
sbci r31,hi8(-(data))
ld r24,Z
ret
bar2:
eor r22,r24
andi r22,lo8(15)
mov r30,r22
ldi r31,lo8(0)
subi r30,lo8(-(data))
sbci r31,hi8(-(data))
ld r24,Z
ret
foo:
lds r24,count.1232
subi r24,lo8(-(1))
sts count.1232,r24
andi r24,lo8(63)
breq .L4
cbi 40-0x20,0
ret
.L4:
sbi 40-0x20,0
ret
Thus, closing this PR as FIXED because the code is optimal and nothing remains
to be improved.
[Bug target/34789] [avr] sometimes the compiler keeps addresses in registers unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34789 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target|avr-*-* |avr Status|NEW |RESOLVED CC||gjl at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-09 20:49:20 UTC --- This is compiled with avr-gcc-4.7.0 -Os -mmcu=avr4 as expected: bar: lds r30,a lds r31,a+1 lsl r30 rol r31 subi r30,lo8(-(data)) sbci r31,hi8(-(data)) ld r24,Z ldd r25,Z+1 rcall foo movw r30,r24 lsl r30 rol r31 subi r30,lo8(-(data)) sbci r31,hi8(-(data)) ld r24,Z ldd r25,Z+1 rjmp foo Thus closing this PR as RESOLVED. For the tail call, see PR34790.
[Bug middle-end/34792] [avr] c++ worse than c compiler at 8-bit optimisations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34792 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target|avr-*-* |avr Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-09 20:52:54 UTC --- Cosed as fixed in 4.7.0. With -Os -mmcu=avr4 both avr-gcc and avr-g++ compile to the same, optimal code: bar2: eor r22,r24 andi r22,lo8(15) mov r30,r22 ldi r31,lo8(0) subi r30,lo8(-(data)) sbci r31,hi8(-(data)) ld r24,Z ret _Z4bar2hh: eor r22,r24 andi r22,lo8(15) mov r30,r22 ldi r31,lo8(0) subi r30,lo8(-(data)) sbci r31,hi8(-(data)) ld r24,Z ret
[Bug ada/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-09 20:59:46 UTC --- It is one of the 6 stack checking tests so this isn't totally unexpected. Fixing this probably requires low-level fiddling with the OS (e.g. see ada/init.c) so I cannot help for Darwin.
[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-09 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-10-09 21:06:34 UTC --- (In reply to comment #6) Right. I was surprised by this, but conversion of out-of-range values between integral types is treated differently in the standard from overflow in arithmetic operations. 4.7: If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined. So, the testcase is OK. I think this bug is actually closely related to 49855, as the fix for that bug also fixes this one for me.
[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #6 from janus at gcc dot gnu.org 2011-10-09 21:15:20 UTC ---
(In reply to comment #5)
How about this?
Looks as if should work (for comment 0).
It does. I'll check for regressions.
(I think the test case in comment 2 is a completely different issue, which
needs a separate fix.)
Agreed. Separate, though related. I think the error message is a bug indeed. A
way to fix it might be:
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 179722)
+++ gcc/fortran/check.c (working copy)
@@ -458,7 +458,8 @@ variable_check (gfc_expr *e, int n, bool allow_pro
if (e-expr_type == EXPR_VARIABLE
e-symtree-n.sym-attr.intent == INTENT_IN
(gfc_current_intrinsic_arg[n]-intent == INTENT_OUT
- || gfc_current_intrinsic_arg[n]-intent == INTENT_INOUT))
+ || gfc_current_intrinsic_arg[n]-intent == INTENT_INOUT)
+ !(e-symtree-n.sym-attr.pointer e-ref))
{
gfc_error ('%s' argument of '%s' intrinsic at %L cannot be INTENT(IN),
gfc_current_intrinsic_arg[n]-name, gfc_current_intrinsic,
[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570 --- Comment #7 from janus at gcc dot gnu.org 2011-10-09 23:08:04 UTC --- (In reply to comment #6) (In reply to comment #5) How about this? Looks as if should work (for comment 0). It does. I'll check for regressions. Unfortunately it fails on: FAIL: gfortran.dg/pointer_intent_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pointer_intent_3.f90 -O (test for excess errors) FAIL: gfortran.dg/pointer_intent_4.f90 -O0 (test for excess errors)
