[Bug c++/44855] Static members not initialised in explicit template instances of library
--- Comment #6 from hlprasu at gmail dot com 2010-07-25 06:35 --- Subject: Re: Static members not initialised in explicit template instances of library Output of gcc -v is given below. I'm using Fedora 13 (with updates till July 24, 2010). The error still persists. === Using built-in specs. Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) === On 25 July 2010 07:43, pinskia at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org  2010-07-25 02:13 --- Works for me on the trunk and in 4.3.2. Can you give the output of gcc -v? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44855
[Bug objc/44887] [4.6 regression] All Objective-C execution tests fail on Solaris 2/SPARC
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-07-25 07:09 --- On Solaris 8: === objc Summary === # of expected passes1983 # of expected failures 15 # of unsupported tests 28 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
[Bug c++/45064] New: friends of nested classes don't see outer classes
This code:
class f1 {
class f2 {
class f3;
friend
void bar(f1::f2::f3 arg);
class f3 {};
};
};
voidbar(f1::f2::f3 arg) {}
gets you:
foo.cc: In function void bar(f1::f2::f3):
foo.cc:2: error: class f1::f2 is private
foo.cc:9: error: within this context
If I change it to:
class f1 {
friend
void bar(f1::f2::f3 arg);
class f2 {
class f3;
class f3 {};
};
};
voidbar(f1::f2::f3 arg) {}
I of course get:
foo.cc:4: error: f1::f2::f3 has not been declared
foo.cc: In function void bar(f1::f2::f3):
foo.cc:5: error: class f1::f2 is private
foo.cc:10: error: within this context
foo.cc:7: error: class f1::f2::f3 is private
foo.cc:10: error: within this context
Changing the friend to:
friend
void ::bar(f1::f2::f3 arg);
doesn't change anything.
Seems to me that a friend of an inner class should see anything that class can
see, including outer classes. The friend declaration might be expecting that
bar is a member function of f1, but explicit ::bar to tell the compiler that
it's global doesn't work either.
Is this a bug or have I found another language feature?
--
Summary: friends of nested classes don't see outer classes
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45064
[Bug c++/45065] New: -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base.
Compiling with -fvisibility=hidden and -fvisibility-inlines-hidden.
I have a Base class with default visibility which contains two virtual methods,
one inlined and the other not. A Derived class with hidden visibility overrides
the non-inlined method and doesn't touch the inlined one. If the declaration of
the overridden method appears *before* the Derived's virtual destructor then
the object file for Derived weakly exports the Base class's inlined method. But
if the declaration appears *after* Derived's virtual destructor then the object
for Derived doesn't export the Base class's inlined method at all.
Given that I'm compiling with -fvisibility-inlines-hidden I *think* that means
that the Base class's inlined method should never be exported. Even if I'm
wrong about that, surely it should not matter the order in which the Derived
class's methods are declared.
Here's an example which demonstrates the problem:
class __attribute__ ((visibility(default))) Base
{
public:
Base();
virtual ~Base();
virtual void func() const;
virtual void inlineFunc() {}
};
class Derived : public Base
{
public:
Derived();
void func() const;
virtual ~Derived();
};
void Derived::func() const
{}
Compiled on OSX 10.6.4 with g++ 4.2.1, using the following command:
g++-4.2 -Wall -c -arch x86_64 -fvisibility=hidden -fvisibility-inlines-hidden
-O3 -m64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -o
Derived.o Derived.cpp
Looking at the object file using 'nm -m Derived.o | grep inlineFunc' gives:
0010 (__TEXT,__textcoal_nt) weak private external
__ZN6Common10inlineFuncEv
0098 (__TEXT,__eh_frame) weak private external
__ZN6Common10inlineFuncEv.eh
If I move the declaration of Derived::func() so that it comes after ~Derived()
then 'nm -m Derived.o | grep inlineFunc' returns nothing.
I see similar behaviour on GNU/Linux (2.6.30.9-96.fc11.x86_64) using g++ 4.4.1.
Compiling with this command:
g++ -Wall -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 -m64 -o
Derived.o Derived.cpp
and using 'objdump -t Derived.o | grep inlineFunc' to inspect the result gives
this when Derived::func() is declared before ~Derived():
ld .text._ZN4Base10inlineFuncEv
.text._ZN4Base10inlineFuncEv
wF .text._ZN4Base10inlineFuncEv 0002
.hidden _ZN4Base10inlineFuncEv
and gives nothing when Derived::func() is declared after ~Derived().
--
Summary: -fvisibility-inlines-hidden: Decl order in derived class
affects visibility of inlines in base.
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deane at gooroos dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45065
[Bug c++/45065] -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base.
--- Comment #1 from deane at gooroos dot com 2010-07-25 08:04 --- Created an attachment (id=21305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21305action=view) Complete example demonstrating bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45065
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #21 from dominiq at lps dot ens dot fr 2010-07-25 10:03 --- With the patch in comment #18, I see all the failures reported in comment #19, plus FAIL: gfortran.dg/whole_file_9.f90 -O (internal compiler error) FAIL: gfortran.dg/g77/13037.f -O3 -g (internal compiler error) With -fwhole-program -O3 -g, most of the polyhedron tests fail either with internal compiler error: in output_die, at dwarf2out.c:11046 or with a segmentation fault. In addition without any option, I see several failures for codes with recursive functions, such as (from pr27613): program test interface function bad_stuff(n) integer :: bad_stuff (2) integer :: n(2) end function bad_stuff recursive function rec_stuff(n) result (tmp) integer :: n(2), tmp(2) end function rec_stuff end interface integer :: res(2) res = bad_stuff((/-19,-30/)) print *, res if (any (res .ne. (/25,25/))) call abort () if (any (rec_stuff((/-19,-30/)) .ne. (/25,25/))) call abort () end program test recursive function bad_stuff(n) integer :: bad_stuff (2) integer :: n(2), tmp(2) bad_stuff = rec_stuff (n) if((maxval (n)0).and.(maxval (n) 2)) then bad_stuff = bad_stuff + bad_stuff (maxval (n)+1) endif entry rec_stuff(n) result (tmp) tmp=1 if(maxval (n) 5) then tmp = tmp + rec_stuff (n+1) endif end function bad_stuff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #70 from burnus at gcc dot gnu dot org 2010-07-25 10:11 --- Are there still remaining issues, and if so which? I think this PR gets too long to have an overview... I only found the one in comment 47: Works -fno-whole-file but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021. With the patch of PR 40873 comment 18 applied, all tests seem to work with -fwhole-program -O3 - except of the comment 47 failure and an additional one for comment 0 test (4) (cf. PR 40873 comment 21) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #22 from burnus at gcc dot gnu dot org 2010-07-25 10:14 --- The patch in comment 18 causes a segfault (in gfc_generate_function_code for cfun-function_end_locus = input_location [Invalid write of size 4]) for the test case in PR 40011 comment 0 (the one after Your patch fixes some Segmentation faults (a couple)) - the test case works otherwise. No -fwhole-program is needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
--- Comment #50 from dominiq at lps dot ens dot fr 2010-07-25 10:20 --- Between revisions 162269 and 162477 this pr has been fixed for -m64 (but not for -m32). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug tree-optimization/43940] DOM doesn't propagate constants properly
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-25 10:29 --- VRP does this with ASSERT_EXPRs. DOM does not optimize this because bb4 has two predecessors, and record_equivalences_from_incoming_edge only records from a single predecessor. This should probably be handled record_equivalences_from_phis by looking at the value of the incoming argument, before calling operand_equal_for_phi_arg_p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] safe conversion from unsigned to signed char gives broken code
--- Comment #6 from mikpe at it dot uu dot se 2010-07-25 10:56 --- My bisection identified r114057 as the cause or trigger for this bug: http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00661.html The assembly code diff for the test case with r114056 and r114057 is: --- char-neg.s-r114056 2010-07-25 12:22:25.0 +0200 +++ char-neg.s-r114057 2010-07-25 12:22:31.0 +0200 @@ -57,9 +57,10 @@ movl%edi, %eax xorl%ebx, %ebx cmpb$-128, %al + movl%edi, %eax sete%bl negl%eax - movsbl %al,%eax + subl$256, %eax movl%ebx, 8(%esp) movl%eax, 4(%esp) movl%edi, (%esp) which looks completely broken. (This is the inlined code for foo() in the loop in test_neg().) r114057 was backported to 4.1.2, but for some reason the bug doesn't trigger there. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Known to fail|4.3.2 |4.3.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug fortran/45066] New: ICE in namelist read in snapshot of 7/24/2010
When I compile the following file with the snapshot of July 24, 2010: MODULE GA_commons INTEGER :: nichflg(2) END MODULE GA_commons PROGRAM gafortran USE GA_commons NAMELIST /ga/ nichflg READ (23, nml=ga) END PROGRAM gafortran I get the following message: g.f90: In function gafortran: g.f90:7:0: 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. -- Summary: ICE in namelist read in snapshot of 7/24/2010 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug libstdc++/45060] Wreorder warning in bits/hashtable.h
-- redi 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-07-25 11:22:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
[Bug libstdc++/45060] Wreorder warning in bits/hashtable.h
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-25 11:41 --- do you have a small testcase to reproduce the problem? -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-07-25 11:22:01 |2010-07-25 11:41:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
[Bug libstdc++/45060] Wreorder warning in bits/hashtable.h
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-25 12:28 --- don't worry about the testcase - obviously just explicitly instantiating unordered_map is sufficient to produce the warning. I'm running the testsuite and I'll apply a fix today -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
[Bug bootstrap/45067] New: [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
4.6-20100724 (r162503) fails to bootstrap on arm-linux-gnueabi in stage 2: make[3]: Entering directory `/home/mikpe/objdir46/libdecnumber' source='/home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c' object='decNumber.o' libtool=no /home/mikpe/objdir46/./prev-gcc/xgcc -B/home/mikpe/objdir46/./prev-gcc/ -B/home/mikpe/temp/armv5tel-brewer-linux-gnueabi/bin/ -B/home/mikpe/temp/armv5tel-brewer-linux-gnueabi/bin/ -B/home/mikpe/temp/armv5tel-brewer-linux-gnueabi/lib/ -isystem /home/mikpe/temp/armv5tel-brewer-linux-gnueabi/include -isystem /home/mikpe/temp/armv5tel-brewer-linux-gnueabi/sys-include -I/home/mikpe/gcc-4.6-20100724/libdecnumber -I. -g -O2 -gtoggle -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror -I/home/mikpe/gcc-4.6-20100724/libdecnumber -I. -c /home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c /home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c: In function 'decDivideOp': /home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c:4456:15: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [decNumber.o] Error 1 make[3]: Leaving directory `/home/mikpe/objdir46/libdecnumber' make[2]: *** [all-stage2-libdecnumber] Error 2 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 The previous weekly snapshot (4.6-20100717) did bootstrap Ok (with r162270 reverted). gcc-4.6 was configured: /home/mikpe/gcc-4.6-20100724/configure --prefix=/home/mikpe/temp --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale --build=armv5tel-brewer-linux-gnueabi --with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin --disable-lto --disable-libmudflap -- Summary: [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC build triplet: armv5tel-unknown-linux-gnueabi GCC host triplet: armv5tel-unknown-linux-gnueabi GCC target triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #1 from mikpe at it dot uu dot se 2010-07-25 13:02 --- Created an attachment (id=21306) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21306action=view) preprocessed source for decNumber.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-07-25 14:26 --- Confirmed. Works with -fno-whole-file. -- jvdelisle 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-07-25 14:26:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug testsuite/45068] New: g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64
On Linux/ia64, I got FAIL: g++.dg/debug/dwarf2/nested-2.C scan-assembler [^\n\r]*\\(DIE[^\n\r]*DW_TAG _structure_type\\)[\n\r]+[^\n\r]*S0[ \t]+#[ \t]+DW_AT_name[\n\r]+(.*)?\\(D IE[^\n\r]*DW_TAG_structure_type\\)[\n\r]+[^\n\r]*Tint0[ \t]+(.*)?\\(DIE[ ^\n\r]*DW_TAG_template_type_param\\)[\n\r]+[^\n\r]*[\n\r]+[^\n\r]*[\n\r]+[^\n\r] *#[ \t]+end of children of DIE[^\n\r]*[\n\r]+[^\n\r]*end of children of DIE[^\n\ r]* Linux/ia64 doesn't always use # as comment. -- Summary: g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45068
[Bug testsuite/45068] g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64
--- Comment #1 from hjl at gcc dot gnu dot org 2010-07-25 14:54 --- Subject: Bug 45068 Author: hjl Date: Sun Jul 25 14:54:03 2010 New Revision: 162511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162511 Log: Support // as assembler comments. 2010-07-25 H.J. Lu hongjiu...@intel.com PR testsuite/45068 * g++.dg/debug/dwarf2/nested-2.C: Support // as comments. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45068
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-07-25 15:04 --- This patchlet at least works for the reduce test case. Assuming there is nothing left to translate. I am not sure this is the right approach, bu the -fdump-tree-original matches for with and without -fno-whole-file. Index: trans-io.c === --- trans-io.c (revision 162507) +++ trans-io.c (working copy) @@ -1499,6 +1499,9 @@ gcc_assert (sym || c); + if (base_addr == NULL) +return; + /* Build the namelist object name. */ string = gfc_build_cstring_const (var_name); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-25 15:08 --- Subject: Bug 42852 Author: jvdelisle Date: Sun Jul 25 15:07:45 2010 New Revision: 162512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162512 Log: 2010-07-25 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/42852 * scanner.c (gfc_next_char_literal): Move check for truncation earlier in the function so that it does not get missed by early exits. (load_line): Add checks for quoted strings and free form comments to disable warnings on comments. Add check for ampersand as first character after truncation and don't warn for this case, but warn if there are subsequent non-whitespace characters. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #33 from paolo dot carlini at oracle dot com 2010-07-25 15:19
---
(In reply to comment #31)
1/ Use -nostdinc++ just as native compilers do. Like said in comment #28, it
may break if used cross-compiler is incompatible with in-tree c++ headers (can
gcc be built that way ?)
This seems like the most reasonable way. Can you try adding -nostdinc++ to
PCHFLAGS in libstdc++-v3/include/Makefile.am and attach a patch to this PR if
it works for your setup?
2/ Do not use in-tree headers when using a cross-compiler. Not sure it is a
good solution and it may break if cross-compiler does not provide correct c++
headers.
And it wouldn't get bugfixes from uninstalled headers.
3/ Use -I=\${includedir} just as when doing canadian cross compilations (see
comment #17). Note that I am building a native compiler that runs on another
host that the one building it (is that also canadian cross compilation no ?)
so
-I\${includedir} should be included.
Let's investigate this in more detail if (1) fails to solve the issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-07-25 15:35 --- Subject: Bug 42852 Author: jvdelisle Date: Sun Jul 25 15:35:04 2010 New Revision: 162514 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162514 Log: 2010-07-25 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/42852 * gfortran.dg/wtruncate_fix.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/wtruncate_fix.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-07-25 15:38 --- Closing as fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-07-25 15:44 --- On the SPARC as well. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug c++/45069] New: Instruction wrong with graphite on i486 geode
With this options: -floop-block -floop-interchange -fgraphite In: CFLAGS=-march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer On i486 geode, I have instruction error. And that's for all compiling program (proftpd, samba, ...) I have no instruction error on core i7 into chroot, and the generated binary work perfectly if it compiled on core i7 for geode. [ocde]i486-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer -floop-block -floop-interchange -fgraphite -Wall -c pr_fnmatch.c i486-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer -floop-block -floop-interchange -fgraphite -Wall -c sstrncpy.c i486-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer -floop-block -floop-interchange -fgraphite -Wall -c strsep.c i486-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer -floop-block -floop-interchange -fgraphite -Wall -c vsnprintf.c i486-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer -floop-block -floop-interchange -fgraphite -Wall -c glibc-glob.c i486-pc-linux-gnu-gcc: Internal error: Illegal instruction (program cc1)[/code] Due to slow cpu and env of prod, I can't switch to debug. Other info thanks to grsec: [codegrsec: From 192.168.0.10: Illegal instruction occurred at af6940fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:6464] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:6463] uid/euid:0/0 gid/egid:0/0 grsec: From 192.168.0.10: Illegal instruction occurred at 9df840fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:8961] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:8960] uid/euid:0/0 gid/egid:0/0 grsec: From 192.168.0.10: Illegal instruction occurred at a92460fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:12561] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:12560] uid/euid:0/0 gid/egid:0/0 grsec: From 192.168.0.10: Illegal instruction occurred at 434480fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:14089] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:14088] uid/euid:0/0 gid/egid:0/0 grsec: From 192.168.0.10: Illegal instruction occurred at 42ca70fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:14092] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:14091] uid/euid:0/0 gid/egid:0/0 grsec: From 192.168.0.10: Illegal instruction occurred at 493790fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:14101] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:14100] uid/euid:0/0 gid/egid:0/0 grsec: From 192.168.0.10: Illegal instruction occurred at 493790fa in /usr/libexec/gcc/i486-pc-linux-gnu/4.4.4/cc1[cc1:14101] uid/euid:0/0 gid/egid:0/0, parent /usr/i486-pc-linux-gnu/gcc-bin/4.4.4/i486-pc-linux-gnu-gcc[i486-pc-linux-g:14100] uid/euid:0/0 gid/egid:0/0[/code] -- Summary: Instruction wrong with graphite on i486 geode Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alpha_one_x86 at first-world dot info GCC host triplet: i486 geode/x86_64 core i7 into chroot but i486 arch GCC target triplet: i486 geode http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45069
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2010-07-25 16:12 --- The patchlet also works for the full-size problem (Ga170.f90 from Alan Miller's ga.zip) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #2 from mikpe at it dot uu dot se 2010-07-25 16:14 --- Created an attachment (id=21307) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21307action=view) reduced test case Attaching reduced 9-line test case. The ICE reproduces with a 4.6 cross hosted on i686-linux: gcc/xgcc -Bgcc/ -O2 -S /tmp/pr45067.c /tmp/pr45067.c: In function 'decDivideOp': /tmp/pr45067.c:6:6: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-07-25 16:21 --- Naturally the patch in #2 breaks everything else for namelists at run time unless I messed up something else here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #11 from bugs at 59A2 dot org 2010-07-25 16:23 --- Will this be applied to 4.5.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug tree-optimization/43940] DOM doesn't propagate constants properly
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-25 16:25 --- cprop_into_successor_phis only propagates SSA_NAME_VALUEs, but not conditional copies/constants. May be a better place to fix this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #5 from michael dot a dot richmond at nasa dot gov 2010-07-25 16:25 --- At runtime it produces the message: At line 1200 of file ga170.f90 (unit = 23, file = 'ga.inp') Fortran runtime error: Missing format for FORMATTED data transfer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug testsuite/45068] g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64
--- Comment #2 from mikpe at it dot uu dot se 2010-07-25 16:44 --- Also fails on sparc64-linux, which uses !' (bang) as comment character. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45068
[Bug libstdc++/45060] Wreorder warning in bits/hashtable.h
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-25 16:44 --- Subject: Bug 45060 Author: redi Date: Sun Jul 25 16:44:38 2010 New Revision: 162515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162515 Log: 2010-07-25 Jonathan Wakely jwakely@gmail.com PR libstdc++/45060 * include/bits/hashtable.h (_Hashtable::_Hashtable(_Hashtable)): Reorder mem-initializers. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #10 from mikpe at it dot uu dot se 2010-07-25 16:45 --- This test fails on powerpc64-linux and sparc64-linux. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug libstdc++/45060] Wreorder warning in bits/hashtable.h
--- Comment #4 from redi at gcc dot gnu dot org 2010-07-25 16:46 --- Fixed on trunk, thanks for the report -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #11 from borntraeger at de dot ibm dot com 2010-07-25 16:54
---
Something like the following should do the trick.
Is endian.h available on all supported platforms?
*** gcc.c-torture/execute/pr45017.c.orig
--- gcc.c-torture/execute/pr45017.c
***
*** 1,9
--- 1,17
+ #include endian.h
+
int tester(char *bytes)
{
union {
struct {
+ # if __BYTE_ORDER == __BIG_ENDIAN
+ unsigned int r2:4;
+ unsigned int r1:4;
+ # endif
+ # if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int r1:4;
unsigned int r2:4;
+ # endif
} fmt;
char value[1];
} ovl;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
--- Comment #19 from mikael at gcc dot gnu dot org 2010-07-25 17:01 --- Subject: Bug 44660 Author: mikael Date: Sun Jul 25 17:01:15 2010 New Revision: 162516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162516 Log: 2010-07-25 Mikael Morin mik...@gcc.gnu.org PR fortran/44660 * gfortran.h (gfc_namespace): New field old_equiv. (gfc_free_equiv_until): New prototype. * match.c (gfc_free_equiv_until): New, renamed from gfc_free_equiv with a parameterized stop condition. (gfc_free_equiv): Use gfc_free_equiv_until. * parse.c (next_statement): Save equivalence list. (reject_statement): Restore equivalence list. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-07-25 17:02 --- I doubt I would be allowed since 4.5.1 is at release candidate 1 phase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-25 17:13 --- Subject: Re: miscompile with bitfield and optimization Is endian.h available on all supported platforms? It is not available on HP-UX. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #13 from mikpe at it dot uu dot se 2010-07-25 17:15 --- endian.h is non-standard. For instance, Solaris 10 doesn't have it. Does the test case really require explicit bit fields? Does it work (as in show the miscompile before the fix) with shift mask operations instead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-07-25 17:37
---
Here is another possibility. Only one namelist regression with this on.
Index: trans-io.c
===
--- trans-io.c (revision 162507)
+++ trans-io.c (working copy)
@@ -1759,8 +1759,11 @@ build_dt (tree function, gfc_code * code)
dt_parm = var;
for (nml = dt-namelist-namelist; nml; nml = nml-next)
- transfer_namelist_element (block, nml-sym-name, nml-sym,
- NULL, NULL);
+ {
+ if (nml-sym-backend_decl)
+ transfer_namelist_element (block, nml-sym-name, nml-sym,
+ NULL, NULL);
+ }
}
else
set_parameter_const (block, var, IOPARM_common_flags, mask);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug fortran/45066] ICE in namelist read in snapshot of 7/24/2010
--- Comment #7 from michael dot a dot richmond at nasa dot gov 2010-07-25 18:01 --- It compiles but doesn't run, as with your Comment #2 patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug target/44031] [4.4/4.5/4.6 Regression] ice in subst_reloads, at reload.c:6327
--- Comment #5 from ubizjak at gmail dot com 2010-07-25 18:06 --- *** Bug 44816 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031
[Bug target/44816] [4.5/4.6 Regression] ice in subst_reloads, at reload.c:6328
--- Comment #4 from ubizjak at gmail dot com 2010-07-25 18:06 --- This is duplicate of PR 44031. *** This bug has been marked as a duplicate of 44031 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44816
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2010-07-25 19:10 --- Subject: Bug 42852 Author: jvdelisle Date: Sun Jul 25 19:10:09 2010 New Revision: 162518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162518 Log: 2010-07-25 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/42852 * scanner.c (gfc_next_char_literal): Enable truncation warning for free-form ''. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #14 from bugs at 59A2 dot org 2010-07-25 19:23 --- Okay, thanks for the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #3 from mikpe at it dot uu dot se 2010-07-25 19:24 --- It's caused by r162431: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00785.html -- mikpe at it dot uu dot se changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug fortran/40628] Assignment using = trim(string): Optimize trim away
--- Comment #3 from tkoenig at gcc dot gnu dot org 2010-07-25 19:31 --- Subject: Bug 40628 Author: tkoenig Date: Sun Jul 25 19:31:37 2010 New Revision: 162519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162519 Log: 2010-07-25 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/40628 * Make-lang.in: Add fortran/frontend-passes.o. * gfortran.h: Add prototype for gfc_run_passes. * resolve.c (gfc_resolve): Call gfc_run_passes. * frontend-passes.c: New file. 2010-07-25 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/40628 * trim_optimize_1.f90: New test. * character_comparision_1.f90: New test. Added: trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/gfortran.dg/character_comparison_1.f90 trunk/gcc/testsuite/gfortran.dg/trim_optimize_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40628
[Bug fortran/45066] [4.6 Regression] ICE in namelist read in snapshot of 7/24/2010
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in namelist read in |[4.6 Regression] ICE in |snapshot of 7/24/2010 |namelist read in snapshot of ||7/24/2010 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug fortran/40628] Assignment using = trim(string): Optimize trim away
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-07-25 19:37 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40628
[Bug target/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-07-25 21:32 --- Subject: Bug 44484 Author: ebotcazou Date: Sun Jul 25 21:32:16 2010 New Revision: 162520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162520 Log: PR target/44484 * config/sparc/predicates.md (memory_reg_operand): Delete. * config/sparc/sync.md (sync_compare_and_swap): Minor tweaks. (*sync_compare_and_swap): Encode the address form in the pattern. (*sync_compare_and_swapdi_v8plus): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/predicates.md trunk/gcc/config/sparc/sync.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug target/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-07-25 21:35 --- At long last. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||07/msg01999.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug target/44707] operand requires impossible reload
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-07-25 21:46 --- Subject: Bug 44707 Author: ebotcazou Date: Sun Jul 25 21:46:32 2010 New Revision: 162521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162521 Log: PR target/44707 * config/sparc/sparc-protos.h (sparc_legitimize_reload_address): New. * config/sparc/sparc.c: Include reload.h. (legitimize_tls_address): Rename into... (sparc_legitimize_tls_address): ...this. (legitimize_pic_address): Rename into... (sparc_legitimize_pic_address): ...this. (sparc_expand_move): Adjust to above renaming. (sparc_tls_referenced_p): Likewise. (sparc_legitimize_tls_address): Likewise. (sparc_legitimize_pic_address): Likewise. (sparc_legitimize_address): Likewise. (sparc_output_mi_thunk): Likewise. (sparc_legitimize_reload_address): New global function. Recognize (lo_sum (high ...) ...) patterns generated by earlier passes. * config/sparc/sparc.h (LEGITIMIZE_RELOAD_ADDRESS): Use above function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc-protos.h trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707
[Bug testsuite/44873] array function not fully defined
--- Comment #2 from zeccav at gmail dot com 2010-07-25 22:14 --- Subject: Re: array function not fully defined The undefined elements of test are accessed at instruction a = test(6, 5) - a however. It is just that the code probably violates any Fortran standard. If the test case is fine with you it is fine with me, anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44873
[Bug testsuite/44873] array function not fully defined
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-07-25 22:24 --- Generally, the gfortran testsuite test cases are testing specific features and not necessarily strict Standard compliance. There is no need to submit PRs for test cases unless they fail unexpectedly or the specific behavior being tested is accepting wrong results. That does happen occasionally, but I think in this case its a does not matter Also, the compiler is required to detect certain wrong programs, but a lot of the time, it is up to the programmer to get it right or suffer the undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44873
[Bug testsuite/44873] array function not fully defined
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-07-25 22:45 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44873
[Bug c++/45070] New: Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
Compilation: arm-unknown-linux-gnueabi-g++ -Os -mcpu=cortex-a8 -o test test.cpp Expected results: ./test 65534 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Real results (some garbage data): ./test 544 544 544 544 544 544 544 544 544 544 544 544 544 544 544 544 Note: This is not a big practical issue because Qt 4.7 does not use packed attribute for QChar anymore (a good idea because using this packed attribute results in a horribly slow code): http://qt.gitorious.org/qt/qt/commit/1ec8acd77b6c048f5a68887ac7750b0764ade598 -- Summary: Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: siarhei dot siamashka at gmail dot com GCC target triplet: arm-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug c++/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-07-25 23:25 --- Created an attachment (id=21308) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21308action=view) packed-testcase.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
