[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-07 07:32 --- As usual we would need preprocessed source as a testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug c/37755] Mistaken Segmentation fault
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-07 07:37 --- As Joseph said. Invalid for -std=c89, worksforme for -std=c99. No changes needed for -std=c1x. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37755
[Bug tree-optimization/37756] ICE building object file with -O3 and -combine
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-07 07:38 --- Unlikely to be fixed. -combine is an obscure feature. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug target/37757] When -Os is enabled, gcc generates a loop where there is none
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-07 07:42 --- I don't see a loop. Also the testcase doesn't link. Can you clarify what you think is the bug? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
[Bug inline-asm/37758] Assembler failure: Error: syntax error; found `,' but expected `('
--- Comment #5 from schwab at suse dot de 2008-10-07 07:55 --- Invalid asm constraints, so not a gcc bug. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
[Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
--- Comment #1 from david dot rosenborg at pantor dot com 2008-10-07 08:42 --- Created an attachment (id=16474) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16474&action=view) Preprocessed program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-07 08:46 --- Do you have evidence that this is a bug given the detailed specifications of the ABI document: http://www.codesourcery.com/public/cxx-abi/ ??? I have trouble believing it, and just checked that other compilers conforming to the multi-vendor standard ABI behave exactly the same as GCC... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #47 from sherpya at netfarm dot it 2008-10-07 11:50 --- ffmpeg uses aligned vars inside an object from an external nasm/yasm compiled module, so it's very unlikely gcc can be aware of this, the patch should solve "implicit" sse code generation, but I think there are no solution for external references. Probably the best way is to pass -fno-common when there is sse code in the project I'll test your patch for the first post of the bugreport, and I'll test also ffmpeg but I'm almost sure that this TARGET_SSE is not true in this specific case with -fno-common I had no problems with make test (when using sse code) all of the stuff in this bugreport is not really definitive, we have a patch for local and for global using commons but there is no way to propagate this data in pe/coff object why not adding an extensions for intermediate coffs? there isn't space anywhere in coff files? yes one can use -fno-common or the fix to avoid crashes when gcc vectorize but it does not cover all cases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #50 from brian at dessent dot net 2008-10-07 12:46 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 Oh, I see what you mean now. Yeah, predicating it on just TARGET_SSE isn't sufficient. I'm starting to think the idea of a PE/COFF-specific convention to record the alignment isn't such a crazy idea. It could just be a section with a specific name e.g. .gnu.note.aligncomm. The PE assembler could then accept the 3-argument form of .comm and store the info there, and the linker would be able to consume it. When linking with a non-GNU linker the section would just be silently ignored and the alignment info discarded, which isn't any worse than the current situation where it's also discarded, so you'd just be back to requiring -fno-common. Of course that's a much more ambitious change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #5 from sherpya at netfarm dot it 2008-10-07 12:48 --- *** This bug has been marked as a duplicate of 37750 *** -- sherpya at netfarm dot it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #5 from sherpya at netfarm dot it 2008-10-07 12:48 --- *** Bug 37584 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug libfortran/37753] [4.4 Regression] Convert="BIG_ENDIAN" reverses character
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37753
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-07 13:22 --- I think the warning is desirable, the code isn't portable to non-32bit int targets. Wonder if we just shouldn't give a TYPE_NAME to uint32_type_node and uint64_type_node (__builtin_uint32_t and __builtin_uint64_t or something similar), then c-format would print that instead and the warning would be clearer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #6 from sherpya at netfarm dot it 2008-10-07 13:23 --- first bt, (pls tell me if you need output of leave temps, generated asm preprocessed or other stuff) Program received signal SIGSEGV, Segmentation fault. 0x0092c4c2 in _alloca () (gdb) bt #0 0x0092c4c2 in _alloca () #1 0x005c7462 in get_dc (s=0x6230030, mb_x=0, mb_y=0, plane_index=0) at libavcodec/snow.c:2426 #2 0x005cff6a in iterative_me (s=0x6230030) at libavcodec/snow.c:3126 #3 0x005d7467 in encode_blocks (s=0x6230030, search=1) at libavcodec/snow.c:2074 #4 0x005d7a2a in encode_frame (avctx=0x5aa3f90, buf=0x5fe06c0 ""..., buf_size=262144, data=0x22eda8) at libavcodec/snow.c:4268 #5 0x00499513 in avcodec_encode_video (avctx=0x5aa3f90, buf=0x5fe06c0 ""..., buf_size=262144, pict=0x22eda8) at libavcodec/utils.c:894 #6 0x00405626 in output_packet (ist=0x5ed6450, ist_index=0, ost_table=0x5aa4390, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:954 #7 0x00409269 in av_encode (output_files=0xb6b378, nb_output_files=1, input_files=0xb6a608, nb_input_files=1, stream_maps=0xb6b3c8, nb_stream_maps=0) at ffmpeg.c:2116 #8 0x00409761 in main (argc=Cannot access memory at address 0x0 ) at ffmpeg.c:3888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #8 from sherpya at netfarm dot it 2008-10-07 13:29 --- another crash in snow, this time argc/argv is not screwed Program received signal SIGSEGV, Segmentation fault. 0x0092c4c2 in _alloca () (gdb) bt #0 0x0092c4c2 in _alloca () #1 0x005d7de7 in encode_frame (avctx=0x5aa3f20, buf=0x5fda480 ""..., buf_size=405504, data=0x22eda8) at libavcodec/snow.c:2426 #2 0x00499513 in avcodec_encode_video (avctx=0x5aa3f20, buf=0x5fda480 ""..., buf_size=405504, pict=0x22eda8) at libavcodec/utils.c:894 #3 0x00405626 in output_packet (ist=0x5ed6450, ist_index=0, ost_table=0x5cd6470, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:954 #4 0x00409269 in av_encode (output_files=0xb6b378, nb_output_files=1, input_files=0xb6a608, nb_input_files=1, stream_maps=0xb6b3c8, nb_stream_maps=0) at ffmpeg.c:2116 #5 0x00409761 in main (argc=95043360, argv=0x3f4998) at ffmpeg.c:3888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #9 from sherpya at netfarm dot it 2008-10-07 13:35 --- sqv1 Program received signal SIGSEGV, Segmentation fault. 0x0092c4c2 in _alloca () (gdb) bt #0 0x0092c4c2 in _alloca () #1 0x005e3338 in svq1_encode_plane (s=0x5a9f2c0, plane=, src_plane=0x5ac9fa0 ""..., ref_plane=0x6063010 '\200' ..., decoded_plane=0x6089300 '\200' ..., width=352, height=288, src_stride=352, stride=416) at libavcodec/svq1enc.c:363 #2 0x005e467a in svq1_encode_frame (avctx=0x5aa3eb0, buf=0x5fe05a0 "", buf_size=405504, data=0x22eda8) at libavcodec/svq1enc.c:541 #3 0x00499513 in avcodec_encode_video (avctx=0x5aa3eb0, buf=0x5fe05a0 "", buf_size=405504, pict=0x22eda8) at libavcodec/utils.c:894 #4 0x00405626 in output_packet (ist=0x5ed6450, ist_index=0, ost_table=0x5ac9e00, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:954 #5 0x00409269 in av_encode (output_files=0xb6b378, nb_output_files=1, input_files=0xb6a608, nb_input_files=1, stream_maps=0xb6b3c8, nb_stream_maps=0) at ffmpeg.c:2116 #6 0x00409761 in main (argc=Cannot access memory at address 0x100 ) at ffmpeg.c:3888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37757] When -Os is enabled, gcc generates a loop where there is none
--- Comment #5 from rick at efn dot org 2008-10-07 13:55 --- (In reply to comment #4) > I don't see a loop. Also the testcase doesn't link. Can you clarify what you > think is the bug? > You are right, there is no loop. The optimizer managed to make me think there was one... Very sorry about the noise. -- rick at efn dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
[Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
--- Comment #4 from paolo dot carlini at oracle dot com 2008-10-07 09:48 --- (In reply to comment #3) > Now, in layman's terms, is the reason for the padding that no two distinct > instances of Empty may share the same address? If that is the case, it would > explain the padding and this is not a bug. Yes, that is a very basic requirement that EBO cannot circumvent. About layman' explanations of the basic logic, I suggest paragraph 16.2 of "C++ Templates: The Complete Guide". -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug c++/37561] [4.2/4.3/4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-07 14:08 --- As all compilers starting with 4.0 behave the same way, this is not a new 4.4 regression. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] Revision |[4.2/4.3/4.4 Regression] |140405 caused g++.old- |Revision 140405 caused |deja/g++.mike/warn1.C |g++.old- ||deja/g++.mike/warn1.C http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug driver/36312] should refuse to overwrite input file with output file
--- Comment #5 from sam at gcc dot gnu dot org 2008-10-07 10:53 --- A warning would be of no use, as it would be too late to recover the input file. Having GCC refuse to run in this case would be great. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #45 from nickc at redhat dot com 2008-10-07 11:37 --- Created an attachment (id=16475) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16475&action=view) Enable -fno-common with -msse for Cygwin/Mingw -- nickc at redhat dot com changed: What|Removed |Added Attachment #16458|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #46 from nickc at redhat dot com 2008-10-07 11:38 --- Hi Brian, > IMHO, we should just have gcc automatically enable -fno-common on PE if > SSE is enabled. That's what the MS tools do, AFAICT. Something like the newly uploaded patch ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug debug/37098] [vta] ICE in expand_debug_expr, at cfgexpand.c:2519
--- Comment #6 from aoliva at gcc dot gnu dot org 2008-10-07 09:28 --- Today's commits to the VTA branch fix the undefined references in libgfortran, and other Fortran code containing complex constants referenced in debug info. The patch that fixes it is here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00215.html -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37098
[Bug c++/37376] [4.4 Regression] No standard mangling for char16/32_t yet
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-07 14:18 --- The trunk now mangles char16_t as Ds and char32_t as Di. Can this be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37376
[Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
--- Comment #5 from pinskia at gmail dot com 2008-10-07 10:45 --- Subject: Re: Member variable of empty base optimized (EBO) class appears on wrong offset Iirc there are some pod vs non pod issues here dealing wit padding and the c++ standard and not even the abi. Sent from my iPhone On Oct 7, 2008, at 2:31 AM, "david dot rosenborg at pantor dot com" <[EMAIL PROTECTED] > wrote: > > > --- Comment #3 from david dot rosenborg at pantor dot com > 2008-10-07 09:31 --- > Ah, no, I wasn't aware of that document. I just thought that gcc was > treating > the Good and Bad cases inconsitently. > > Now, in layman's terms, is the reason for the padding that no two > distinct > instances of Empty may share the same address? If that is the case, > it would > explain the padding and this is not a bug. > > Sorry, should have investigated more before hitting the commit button. > > /David > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #48 from brian at dessent dot net 2008-10-07 12:01 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 sherpya at netfarm dot it wrote: > I'll test your patch for the first post of the bugreport, and I'll test also > ffmpeg but I'm almost sure that this TARGET_SSE is not true in this specific > case You said you used -march=core2 to compile. This implicitly includes -msse2 (and -msse) so yes it will be set. > yes one can use -fno-common or the fix to avoid crashes when gcc vectorize > but it does not cover all cases What cases would it not cover? When placing items directly in bss or data the required alignment can be unambiguously conveyed to the assembler so I don't see how it would get lost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #44 from nickc at redhat dot com 2008-10-07 10:57 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
sherpya at netfarm dot it wrote:
> I mean that with -fno-common alignment works, even with non patched 4.2, my
> question is due to the fact that it's not so clear for me what no-common does
-fno-common stops uninitialized variables declared in C and C++ programs
from being treated in the same way as common variables declared in
FORTRAN programs.
> and adding -fno-common what are side effects?
Essentially there are two side effects: The first is that you will get
a link time error if you declare the same uninitialized variable twice
in two different source files, without using the 'extern' keyword on one
of them. eg:
% cat foo.c
int a;
% cat bar.c
int a;
int main (void) { return 0; }
% gcc foo.c bar.c
% gcc -fno-common foo.c bar.c
multiple definition of `a'
This is often a problem with badly written header files which declare
variables without using 'extern'. eg:
% cat header.h
int a;
% cat foo.c
#include "header.h"
int a;
% cat bar.c
#include "header.h"
int main (void) { return 0; }
% gcc -fno-common foo.c bar.c
multiple definition of `a'
The other side-effect, and the one that is more interesting for our
purposes, is that it forces uninitialised variables to be placed into
the .bss section. This is important because symbols in the PE/COFF file
format do not have an alignment attribute of their own. Instead the
alignment is inherited by the containing section, with the maximum
alignment of any symbol inside a section being taken as the section's
alignment as a whole. Symbols are placed inside the section on suitably
aligned boundaries, so that providing that the section itself is placed
on an alignment boundary everything will work. eg:
% cat foo.c
int normal_align;
int aligned_16 __attribute__((aligned(16)));
% gcc -fno-common -c foo.c
% objdump --syms foo.o
[ 8](sec 3)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x _normal_align
[ 9](sec 3)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0010 _aligned_16
Note how the 'aligned_16' variable starts at an offset of
0010 from the start of section 3, whereas 'normal_align'
starts at an offset of . Ie there is a gap of 12
bytes from offset 0004 to 000f.
% objdump -h foo.o
Idx Name Size VMA LMA File off Algn
2 .bss 0020 2**4
Note that the .bss section has been given an alignment of 2^4.
This is because it contains 'aligned_16'. If that variable had
not been declared then the .bss section would have been given
its default alignment of 2^2.
Also note that section numbering differs between the two uses
of objdump. Ie "(sec 3)" in the "objdump --syms" output refers
to the third declared section which is the section with an
index of 2 in the "objdump -h" output.
% cat bar.c
int a;
% gcc -fno-common bar.c foo.o
% nm a.exe
00402000 B _a
00402020 B _aligned_16
00402010 B _normal_align
So after linking 'aligned_16' still has a 16-bit alignment
because of the 2^4 alignment of the .bss section in the foo.o
object file.
The reason that all of this is important is that when common variables
are stored in a PE/COFF object file they are not assigned to any
section. Since only sections, not symbols, have an alignment attribute
in PE/COFF object files, any alignment requirements of common symbols
are lost. This is what has been causing the problems that you have
experienced. eg:
% cat foo.c
int normal_align;
int aligned_16 __attribute__((aligned(16)));
% gcc -c foo.c
% objdump --syms foo.o
[ 8](sec 0)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0004 _normal_align
[ 9](sec 0)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0004 _aligned_16
Note how the variables are assigned to "(sec 0)" which does not
exist and that there is no field or flag specifying the alignment
for either of them.
You may ask why common variables are not assigned to the .bss section.
The reason is that if there are multiple declarations of the same
variable and all but one of which are common, then the non-common
declaration takes precedence. eg:
% cat foo.c
int a;
% cat bar.c
int a = 1;
% gcc foo.c bar.c
% nm a.exe
00402000 D _a
Ie the 'a' variable has been placed in the .data section and not the
.bss section, despite the fact that it was declared uninitialised in
foo.c.
So common variables are not assigned to a section until the final link
takes places. If there are no non-common definitions of a variable to
specify where they should be placed then they are assigned to the .bss
section, but by then it is too late - the alignment requirements of the
symbol have been lost.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/sh
[Bug fortran/37746] string copy fails, due to changed intent(in) parameter
--- Comment #3 from kloedej at knmi dot nl 2008-10-07 11:23 --- Hi, thanks for this discussion. I do agree now that this code was invalid. I was thinking otherwise because no compiletime or runtime error was issued by any of the compilers that I tried. Checking this during compilation should at least be possible when the interface of the subroutine is known, so when it is defined inside a module, but gfortran also accepts that case without complaining. best regards, Jos de Kloe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug target/36635] [4.4 Regression] cc1 segfault from svn 137122
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-07 14:57 --- This one isn't reproducible for me on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36635
[Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
--- Comment #3 from david dot rosenborg at pantor dot com 2008-10-07 09:31 --- Ah, no, I wasn't aware of that document. I just thought that gcc was treating the Good and Bad cases inconsitently. Now, in layman's terms, is the reason for the padding that no two distinct instances of Empty may share the same address? If that is the case, it would explain the padding and this is not a bug. Sorry, should have investigated more before hitting the commit button. /David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #4 from sherpya at netfarm dot it 2008-10-07 09:38 --- unfortunately snow.c is a very big file, I'll try to find a shorter example, but if the problem is in alloca() the generated asm will not be so usefull -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #7 from sherpya at netfarm dot it 2008-10-07 13:27 --- compile flags OPTFLAGS=-O3 -fno-common -g3 -march=native -mtune=native -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -fasm -std=c99 -fomit-frame-pointer -DPTW32_STATIC_LIB -g3 -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -O2 -fno-math-errno -fno-signed-zeros -O3 -fno-common -march=native -mtune=native -pipe where added by me (-fno-common is needed to avoid crash in sse code) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
Re: [Bug c++/37762] Member variable of empty base optimized (EBO) class appears on wrong offset
Iirc there are some pod vs non pod issues here dealing wit padding and the c++ standard and not even the abi. Sent from my iPhone On Oct 7, 2008, at 2:31 AM, "david dot rosenborg at pantor dot com" <[EMAIL PROTECTED] > wrote: --- Comment #3 from david dot rosenborg at pantor dot com 2008-10-07 09:31 --- Ah, no, I wasn't aware of that document. I just thought that gcc was treating the Good and Bad cases inconsitently. Now, in layman's terms, is the reason for the padding that no two distinct instances of Empty may share the same address? If that is the case, it would explain the padding and this is not a bug. Sorry, should have investigated more before hitting the commit button. /David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug c++/37762] New: Member variable of empty base optimized (EBO) class appears on wrong offset
A member variable of a class that utilizes EBO and has a type that also
utilizes EBO appears to be laid out at the wrong offset.
In the example below, the only difference between the classes Good and Bad is
that the member of Bad inherits from a class with no members. The sizeof
printouts show that EBO is in play, but the Bad class gets an extra four byte
padding before the member. There's no reason Bad should be any larger than
Good.
Kind Regards
/David
#include
struct Empty { };
struct Member { int extent; };
struct MemberWithEBO : public Empty { int extent; };
struct Good : public Empty { Member m; }; // OK
struct Bad : public Empty { MemberWithEBO m; }; // Broken, see below
#define PRINT(x) printf ("%-25s %d\n", # x ":", (x))
template long int offsetOf (T C::*m)
{
C proto;
return (long int)(void*)&(proto.*m) - (long int)(void *)&proto;
}
int
main (int argc, char ** argv)
{
PRINT (sizeof (Member));
PRINT (sizeof (Good));
PRINT (offsetOf (&Good::m));
PRINT (sizeof (MemberWithEBO));
PRINT (sizeof (Bad));
PRINT (offsetOf (&Bad::m));
}
// Printout:
//
// sizeof (Member): 4
// sizeof (Good):4
// offsetOf (&Good::m): 0
// sizeof (MemberWithEBO): 4
// sizeof (Bad): 8 <-- Should be 4
// offsetOf (&Bad::m): 4 <-- Should be 0
> g++ -v -save-temps ebo_bug.cc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc431
--with-pkgversion=gcc431 --enable-languages=c,c++
Thread model: posix
gcc version 4.3.1 (gcc431)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/local/gcc431/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/cc1plus -E -quiet
-v -D_GNU_SOURCE ebo_bug.cc -mtune=generic -fpch-preprocess -o ebo_bug.ii
ignoring nonexistent directory
"/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/x86_64-unknown-linux-gnu
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward
/usr/local/include
/usr/local/gcc431/include
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/local/gcc431/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/cc1plus
-fpreprocessed ebo_bug.ii -quiet -dumpbase ebo_bug.cc -mtune=generic -auxbase
ebo_bug -version -o ebo_bug.s
GNU C++ (gcc431) version 4.3.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.1.4, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4926fc16e15403c044148a60354159ba
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
as -V -Qy -o ebo_bug.o ebo_bug.s
GNU assembler version 2.17.50.0.6-6.el5 (x86_64-redhat-linux) using BFD version
2.17.50.0.6-6.el5 20061020
COMPILER_PATH=/usr/local/gcc431/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/:/usr/local/gcc431/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/:/usr/local/gcc431/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/:/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/:/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/local/gcc431/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/crtbegin.o
-L/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1
-L/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../.. ebo_bug.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/gcc431/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/crtend.o
/usr/lib/../lib64/crtn.o
--
Summary: Member variable of empty base optimized (EBO) class
appears on wrong offset
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot rosenborg at pantor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37762
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #49 from sherpya at netfarm dot it 2008-10-07 12:15 --- not exactly, Simon Sasburg compiled with -march=core2 I'm not explicitly telling to gcc to compile sse code, arch is i686 and opt is -O2 so there is no sse code generated by gcc, ffmpeg declares aligned vars in fft.c and uses them in asm sse code, file fft_mmx.asm that is generated by yasm so gcc is unable to known that those vars will be used by sse code, this case will not covered by the last patch gcc should emit a warning when compiling align declared vars on win32 version 3.x had a similar warning but only if using align > 16 with current state of compiler/toolchain even 16-bytes aligned is not possible without explicit -fno-common compile switch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug middle-end/37713] [4.4 Regression] ice for legal code with -O3 on 20080926
--- Comment #7 from irar at il dot ibm dot com 2008-10-07 11:25 --- This seems to be similar to the failure in PR 37385 (in set_mem_alias_set, at emit-rtl.c:1789). There the ICE was because the lhs and the element type of rhs did not alias. -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37713
[Bug fortran/37747] [4.4 Regression]: Errors when printing real(16)
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-07 16:01 --- > Was this fixed by: ... The problem is no longer here at revision 140915. So the answer is probably yes, but I am not ready to dig any further. So this pr can probably closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
[Bug target/24765] TARGET_USE_BIT_TEST is never used
--- Comment #2 from hjl at gcc dot gnu dot org 2008-10-07 16:01 --- Subject: Bug 24765 Author: hjl Date: Tue Oct 7 16:00:30 2008 New Revision: 140938 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140938 Log: 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR target/24765 * config/i386/i386.c (initial_ix86_tune_features): Remove X86_TUNE_USE_BIT_TEST. * config/i386/i386.h (ix86_tune_indices): Likewise. (TARGET_USE_BIT_TEST): Removed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24765
[Bug fortran/37748] [4.4 Regression]: FAIL: gfortran.dg/random_3.f90
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-07 16:03 --- The problem is no longer here at revision 140915. It had probably the same origin as pr37747 and can be closed at the same time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37748
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-10-07 16:04 --- Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail ebotcazou at gcc dot gnu dot org writes: > I think that we should assemble some C code with CFI directives and see > whether > the resulting .eh_frame is read-only; if so, HAVE_GAS_CFI_DIRECTIVE must be > set > to 0 instead of 1. This should discriminate between 2.18 and upcoming 2.19. That's what I did in my patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00249.html I could just take the current test code for gcc_cv_as_cfi_directive as is and inspect the object file with objdump on Solaris. Using C code directly with gcc -fexceptions -fdwarf2-cfi-asm didn't work since it relies upon the bootstrap compiler being gcc and sufficiently recent to support -fdwarf2-cfi-asm, leading to comparions failures upon a mismatch. > That the non-C compilers still emit .eh_frame directly is unexpected I'd > think. I think I'll raise a separate PR for that and add rth to the Cc:. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug target/24765] TARGET_USE_BIT_TEST is never used
--- Comment #3 from hjl dot tools at gmail dot com 2008-10-07 16:10 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24765
[Bug target/36635] [4.4 Regression] cc1 segfault from svn 137122
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-07 16:16 --- I've reproduced PR37341 though. And I believe your patch is an overkill, as cse_cc_succs only recurses if edge destination has a single predecessor. So IMHO you don't need to keep a bitmap of visited blocks, as the only way to reach endless recursion is if you eventually reach the original bb cse_condition_code_reg called cse_cc_succs with, as if there is a smaller loop there would be some bb with more than one predecessor. To fix this, we can either add an extra argument to cse_cc_succs (the original bb) and bail if e->dest is equal to orig_bb; IMHO this is the cheapest variant), or we could call find_unreachable_blocks () if tem > 0 before cse_condition_code_reg and disregard (bb->flags & BB_REACHABLE) == 0 bb's (or delete_unreachable_blocks ()). -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-26 10:25:28 |2008-10-07 16:16:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36635
[Bug c++/37761] [4.4 Regression]: Revision 140916 caused libstdc++ failures
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-07 16:51:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37761
[Bug c/37763] New: bad interaction of -O3 -pg and -mcu=arm920t ??
Are there known issues among the -pg and -O3 and -mcu=arm9020t options ? I am using Gcc 3.3.5 on Debian 1:3.3.5-13, running on a Technologic systems TS-7200 board with an Arm920T processor. Compiling a medium size program (~ 1.5mb source code) with flags -O3 -mcu=arm920t -Wall I get no errors/warnings, and the program runs to completion w/o error Yet compiling with the flags -O3 -pg -mcu=arm920t -Wall produces no errors/warnings, butproduces Segment errors at runtime -- the location of the error varies; which is unusual as the program is deterministic. And compiling with the flags -O3 -g -mcu=arm920t -Wall produces no errors/warnings, and runs to completion (either at command line or inside gdb) w/o error. fiy ... compiling the program with these sets of flags -mcu-arm920t -Wall and -03 -mcu=arm920t -Wall compile with no errors/warnings, run to completion w/o error, and and produces identical large (~2gB) regression test output. If there are no known issues among these flags, I'll work to get a smaller code base which will reproduce the bug. thanks... -- Summary: bad interaction of -O3 -pg and -mcu=arm920t ?? Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steven dot paul at monotypeimaging dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37763
[Bug c++/37376] [4.4 Regression] No standard mangling for char16/32_t yet
--- Comment #5 from jason at gcc dot gnu dot org 2008-10-07 17:50 --- Yep. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37376
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-07 18:15 --- Subject: Bug 37738 Author: jakub Date: Tue Oct 7 18:14:16 2008 New Revision: 140944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140944 Log: PR debug/37738 * dwarf2out.c (common_block_die_table): New variable. (common_block_die_table_hash, common_block_die_table_eq): New functions. (gen_variable_die): Look up a DW_TAG_common_block die for a particular COMMON block in the current scope rather than globally. Optimize DW_OP_addr SYMBOL_REF DW_OP_plus_uconst off into DW_OP_addr SYMBOL_REF+off. * gfortran.dg/debug/pr37738.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/debug/pr37738.f Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] long long may not work correctly on 32bit host
--- Comment #11 from hjl at gcc dot gnu dot org 2008-10-07 18:47 --- Subject: Bug 37731 Author: hjl Date: Tue Oct 7 18:45:56 2008 New Revision: 140947 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140947 Log: gcc/ 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR middle-end/37731 * expmed.c (expand_mult): Properly check DImode constant in CONST_DOUBLE. gcc/testsuite/ 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR middle-end/37731 * gcc.dg/torture/pr37731-1.c: New. * gcc.dg/torture/pr37731-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr37731-1.c trunk/gcc/testsuite/gcc.dg/torture/pr37731-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-07 18:50 --- Subject: Bug 37616 Author: jakub Date: Tue Oct 7 18:48:40 2008 New Revision: 140948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140948 Log: PR debug/29609 PR debug/36690 PR debug/37616 * basic-block.h (struct edge_def): Add goto_block field. * cfglayout.c (fixup_reorder_chain): Ensure that there is at least one insn with locus corresponding to edge's goto_locus if !optimize. * profile.c (branch_prob): Copy edge's goto_block. * cfgrtl.c (force_nonfallthru_and_redirect): Use goto_locus for emitted jumps. (cfg_layout_merge_blocks): Emit a nop with edge's goto_locus locator in between the merged basic blocks if !optimize and needed. * cfgexpand.c (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator. For unconditional jump use that locator for the jump insn. (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator for all remaining edges. For unconditional jump use that locator for the jump insn. * cfgcleanup.c (try_forward_edges): Avoid the optimization if there is more than one edge or insn locator along the forwarding edges and !optimize. If there is just one, set e->goto_locus. * tree-cfg.c (make_cond_expr_edges, make_goto_expr_edges): Set also edge's goto_block. (move_block_to_fn): Adjust edge's goto_block. * gcc.dg/debug/pr29609-1.c: New test. * gcc.dg/debug/pr29609-2.c: New test. * gcc.dg/debug/pr36690-1.c: New test. * gcc.dg/debug/pr36690-2.c: New test. * gcc.dg/debug/pr36690-3.c: New test. * gcc.dg/debug/pr37616.c: New test. * gcc.dg/debug/dwarf2/pr29609-1.c: New test. * gcc.dg/debug/dwarf2/pr29609-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-1.c: New test. * gcc.dg/debug/dwarf2/pr36690-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-3.c: New test. * gcc.dg/debug/dwarf2/pr37616.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr37616.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/pr37616.c Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/cfgcleanup.c trunk/gcc/cfgexpand.c trunk/gcc/cfglayout.c trunk/gcc/cfgrtl.c trunk/gcc/profile.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-07 18:50 --- Subject: Bug 36690 Author: jakub Date: Tue Oct 7 18:48:40 2008 New Revision: 140948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140948 Log: PR debug/29609 PR debug/36690 PR debug/37616 * basic-block.h (struct edge_def): Add goto_block field. * cfglayout.c (fixup_reorder_chain): Ensure that there is at least one insn with locus corresponding to edge's goto_locus if !optimize. * profile.c (branch_prob): Copy edge's goto_block. * cfgrtl.c (force_nonfallthru_and_redirect): Use goto_locus for emitted jumps. (cfg_layout_merge_blocks): Emit a nop with edge's goto_locus locator in between the merged basic blocks if !optimize and needed. * cfgexpand.c (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator. For unconditional jump use that locator for the jump insn. (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator for all remaining edges. For unconditional jump use that locator for the jump insn. * cfgcleanup.c (try_forward_edges): Avoid the optimization if there is more than one edge or insn locator along the forwarding edges and !optimize. If there is just one, set e->goto_locus. * tree-cfg.c (make_cond_expr_edges, make_goto_expr_edges): Set also edge's goto_block. (move_block_to_fn): Adjust edge's goto_block. * gcc.dg/debug/pr29609-1.c: New test. * gcc.dg/debug/pr29609-2.c: New test. * gcc.dg/debug/pr36690-1.c: New test. * gcc.dg/debug/pr36690-2.c: New test. * gcc.dg/debug/pr36690-3.c: New test. * gcc.dg/debug/pr37616.c: New test. * gcc.dg/debug/dwarf2/pr29609-1.c: New test. * gcc.dg/debug/dwarf2/pr29609-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-1.c: New test. * gcc.dg/debug/dwarf2/pr36690-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-3.c: New test. * gcc.dg/debug/dwarf2/pr37616.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr37616.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/pr37616.c Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/cfgcleanup.c trunk/gcc/cfgexpand.c trunk/gcc/cfglayout.c trunk/gcc/cfgrtl.c trunk/gcc/profile.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] long long may not work correctly on 32bit host
--- Comment #12 from hjl at gcc dot gnu dot org 2008-10-07 18:50 --- Subject: Bug 37731 Author: hjl Date: Tue Oct 7 18:48:59 2008 New Revision: 140949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140949 Log: gcc/ 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> Backport from mainline: 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR middle-end/37731 * expmed.c (expand_mult): Properly check DImode constant in CONST_DOUBLE. gcc/testsuite/ 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> Backport from mainline: 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR middle-end/37731 * gcc.dg/torture/pr37731-1.c: New. * gcc.dg/torture/pr37731-2.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr37731-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr37731-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/expmed.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug middle-end/29609] [4.2/4.3/4.4 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #9 from jakub at gcc dot gnu dot org 2008-10-07 18:50 --- Subject: Bug 29609 Author: jakub Date: Tue Oct 7 18:48:40 2008 New Revision: 140948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140948 Log: PR debug/29609 PR debug/36690 PR debug/37616 * basic-block.h (struct edge_def): Add goto_block field. * cfglayout.c (fixup_reorder_chain): Ensure that there is at least one insn with locus corresponding to edge's goto_locus if !optimize. * profile.c (branch_prob): Copy edge's goto_block. * cfgrtl.c (force_nonfallthru_and_redirect): Use goto_locus for emitted jumps. (cfg_layout_merge_blocks): Emit a nop with edge's goto_locus locator in between the merged basic blocks if !optimize and needed. * cfgexpand.c (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator. For unconditional jump use that locator for the jump insn. (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator for all remaining edges. For unconditional jump use that locator for the jump insn. * cfgcleanup.c (try_forward_edges): Avoid the optimization if there is more than one edge or insn locator along the forwarding edges and !optimize. If there is just one, set e->goto_locus. * tree-cfg.c (make_cond_expr_edges, make_goto_expr_edges): Set also edge's goto_block. (move_block_to_fn): Adjust edge's goto_block. * gcc.dg/debug/pr29609-1.c: New test. * gcc.dg/debug/pr29609-2.c: New test. * gcc.dg/debug/pr36690-1.c: New test. * gcc.dg/debug/pr36690-2.c: New test. * gcc.dg/debug/pr36690-3.c: New test. * gcc.dg/debug/pr37616.c: New test. * gcc.dg/debug/dwarf2/pr29609-1.c: New test. * gcc.dg/debug/dwarf2/pr29609-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-1.c: New test. * gcc.dg/debug/dwarf2/pr36690-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-3.c: New test. * gcc.dg/debug/dwarf2/pr37616.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr37616.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/pr37616.c Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/cfgcleanup.c trunk/gcc/cfgexpand.c trunk/gcc/cfglayout.c trunk/gcc/cfgrtl.c trunk/gcc/profile.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] long long may not work correctly on 32bit host
--- Comment #13 from hjl at gcc dot gnu dot org 2008-10-07 18:52 --- Subject: Bug 37731 Author: hjl Date: Tue Oct 7 18:50:46 2008 New Revision: 140950 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140950 Log: gcc/ 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> Backport from mainline: 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR middle-end/37731 * expmed.c (expand_mult): Properly check DImode constant in CONST_DOUBLE. gcc/testsuite/ 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> Backport from mainline: 2008-10-07 H.J. Lu <[EMAIL PROTECTED]> PR middle-end/37731 * gcc.dg/torture/pr37731-1.c: New. * gcc.dg/torture/pr37731-2.c: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr37731-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr37731-2.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/expmed.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] long long may not work correctly on 32bit host
--- Comment #14 from hjl dot tools at gmail dot com 2008-10-07 18:56 --- Fixed for 4.2.5, 4.3.3 and 4.4.0. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-07 19:00 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-07 19:01 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug middle-end/29609] [4.2/4.3/4.4 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #10 from jakub at gcc dot gnu dot org 2008-10-07 19:01 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug c++/37761] [4.4 Regression]: Revision 140916 caused libstdc++ failures
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-07 19:13 --- Confirmed fixed by: http://gcc.gnu.org/ml/gcc-cvs/2008-10/msg00144.html -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37761
[Bug fortran/37747] [4.4 Regression]: Errors when printing real(16)
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-07 19:16 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
[Bug fortran/37748] [4.4 Regression]: FAIL: gfortran.dg/random_3.f90
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-07 19:16 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37748
[Bug debug/37726] [4.4 Regression] Even at -O0 -g debuginfo for vars mentioned in nested fns is not emitted
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-07 20:04 --- This test does not work for darwin for some reason, I have not looked why though, I bet it is due to the way dwarf2 is outputted there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37726
[Bug target/37763] bad interaction of -O3 -pg and -mcu=arm920t ??
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-07 20:35 --- First 3.3.5 is so old that it is hard to reproduce the issue. Also the ARM back-end has been improved and there has been a big ABI change (over to a standard ABI). We also need the preprocessed source where the issue is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||arm-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37763
[Bug target/37759] powerpc option -mno-spe still generates SPE instructions
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-07 20:38 --- I think this is by design, you did not change the ABI to be a non SPE based one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
[Bug c++/37761] [4.4 Regression]: Revision 140916 caused libstdc++ failures
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37761
[Bug tree-optimization/37756] ICE building object file with -O3 and -combine
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-07 20:40 --- (In reply to comment #2) > Unlikely to be fixed. -combine is an obscure feature. Except it might not be a -combine issue :). Until the bug gets reduced/analyzed we cannot say it will unlikely be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug libfortran/37753] [4.4 Regression] Convert="BIG_ENDIAN" reverses character
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-10-07 20:41 --- (In reply to comment #1) > Thomas, any ideas and do you have time to investigate this? The problem is right at the beginning of write_unformatted and read_unformatted. I think we need to select the normal write/read on kind==1, not on size==1, but I will need to do some more thinking on this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-07 20:41:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37753
[Bug middle-end/37742] ICE when compile mpich2-1.1.0a1
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-10-07 20:45 --- Reducing ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug debug/27574] [4.2/4.3/4.4 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
-- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||dodji at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-01 07:11:38 |2008-10-07 20:51:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug c/35437] [4.2/4.3/4.4 regression] ICE with struct containing incomplete type
--- Comment #3 from simartin at gcc dot gnu dot org 2008-10-07 20:58 --- Subject: Bug 35437 Author: simartin Date: Tue Oct 7 20:56:53 2008 New Revision: 140953 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140953 Log: gcc/ 2008-10-07 Simon Martin <[EMAIL PROTECTED]> PR c/35437 * expr.c (count_type_elements): Handle ERROR_MARK. gcc/testsuite/ 2008-01-07 Simon Martin <[EMAIL PROTECTED]> PR c/35437 * gcc.dg/struct-parse-2.c: New test. * g++.dg/parse/struct-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/struct-4.C trunk/gcc/testsuite/gcc.dg/struct-parse-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35437
[Bug middle-end/37576] [4.4 Regression] -v --help ICEs
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-07 21:03 --- Subject: Bug 37576 Author: jakub Date: Tue Oct 7 21:02:21 2008 New Revision: 140955 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140955 Log: PR middle-end/37576 * opts.h (CL_SAVE): Move up to flags range. (CL_PARAMS, CL_WARNING, CL_OPTIMIZATION, CL_TARGET, CL_COMMON): Renumber. (CL_MIN_OPTION_CLASS): Set to CL_PARAMS. * opts.c (common_handle_option): Revert last change. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c trunk/gcc/opts.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37576
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer to struct
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-10-07 21:04 ---
Reduced testcase:
typedef struct {
float re;
float im;
} d_complex;
void MPIR_SUM ( d_complex * __restrict a, d_complex * __restrict b, int len)
{
int i;
for ( i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer to struct
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-10-07 21:04 --- Also happens on powerpc64-linux-gnu with -maltivec. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i?86-*-* x86_64-*-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-07 21:05 --- Also ICEs the same way on spu-elf. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i686-*-*|i686-*-*, spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37730
[Bug fortran/36581] Fortran compiler does not pass the tests
--- Comment #3 from frobles at inmegen dot gob dot mx 2008-10-07 21:20 --- Created an attachment (id=16476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16476&action=view) configure: error: GNU Fortran is not working; I don't understand why not work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36581
[Bug fortran/36581] Fortran compiler does not pass the tests
--- Comment #4 from kargl at gcc dot gnu dot org 2008-10-07 22:13 --- (In reply to comment #3) > Created an attachment (id=16476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16476&action=view) [edit] > configure: error: GNU Fortran is not working; > > I don't understand > why not work? > Please read the instructions for installing GCC. Your log file has $ ./configure --prefix=/gpfs2/shares/affimetrix/software/gcc-4.3.2 --with-mpfr=/gpfs2/shares/affimetrix/software/mpfr-2.3.1 --with-gmp=/gpfs2/shares/affimetrix/software/gmp-4.2.3 --disable-nls --enable-shared --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-threads=posix --with-gnu-as --with-cpu-64=x86-64 --disable-multilib --enable-languages=fortran This suggest that you tried to build GCC in its source directory. Don't do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36581
[Bug target/37759] powerpc option -mno-spe still generates SPE instructions
--- Comment #3 from patrick at motec dot com dot au 2008-10-07 22:14 --- Created an attachment (id=16477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16477&action=view) preprocessed source Setting -mabi=no-spe corrects the the first example. The new prexeth.i example still generates evldd/evstdd even with -mabi=no-spe, adding the -mno-spe flag makes no difference. -- patrick at motec dot com dot au changed: What|Removed |Added Attachment #16472|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
[Bug target/37759] powerpc option -mno-spe still generates SPE instructions
--- Comment #4 from patrick at motec dot com dot au 2008-10-07 22:15 --- Forgot to add -v output: powerpc-eabispe-gcc -DLWIP_DEBUG -Iprex/include -Ilwip/src/include -Ilwip/src/include/ipv4 -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include -nostdinc -fsingle-precision-constant -mabi=no-spe -gdwarf-2 -Os -ansi -fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -std=gnu99 -fno-stack-protector -Wno-variadic-macros -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -fno-omit-frame-pointer -DDEBUG -g -Wsign-compare -Werror-implicit-function-declaration -v -save-temps -MD -MT prex/prexeth.o -MP -MF .prexeth.d -I/home/patrick/src/e7/prex/dev/include -c -o prex/prexeth.o prex/prexeth.c Using built-in specs. Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.3.2/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c --disable-nls --disable-multilib --disable-werror --without-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2 --with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp Thread model: single gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-DLWIP_DEBUG' '-Iprex/include' '-Ilwip/src/include' '-Ilwip/src/include/ipv4' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'prex/prexeth.o' '-MP' '-MF' '.prexeth.d' '-I/home/patrick/src/e7/prex/dev/include' '-c' '-o' 'prex/prexeth.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -E -quiet -nostdinc -v -Iprex/include -Ilwip/src/include -Ilwip/src/include/ipv4 -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/dev/include -MD prex/prexeth.d -MF .prexeth.d -MP -MT prex/prexeth.o -DLWIP_DEBUG -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -DDEBUG prex/prexeth.c -mabi=no-spe -ansi -std=gnu99 -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -fworking-directory -Os -fpch-preprocess -o prexeth.i #include "..." search starts here: #include <...> search starts here: prex/include lwip/src/include lwip/src/include/ipv4 /home/patrick/src/e7/prex /home/patrick/src/e7/prex/usr/include /home/patrick/src/e7/prex/include /home/patrick/src/e7/prex/dev/include End of search list. COLLECT_GCC_OPTIONS='-DLWIP_DEBUG' '-Iprex/include' '-Ilwip/src/include' '-Ilwip/src/include/ipv4' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-v' '-save-temps' '-MD' '-MT' 'prex/prexeth.o' '-MP' '-MF' '.prexeth.d' '-I/home/patrick/src/e7/prex/dev/include' '-c' '-o' 'prex/prexeth.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.2/cc1 -fpreprocessed prexeth.i -quiet -dumpbase prexeth.c -mabi=no-spe -ansi -auxbase-strip prex/prexeth.o -gdwarf-2 -g -Os -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -ansi -std=gnu99 -version -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -o prexeth.s GNU C (GCC) version 4.3.2 (powerpc-eabispe) compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7), GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c30b16423d0b6addaa52d5eb1153852d COLLECT_GCC_OPTIONS='-DLWIP_DEBUG' '-Iprex/include' '-Ilwip/src/include' '-Ilwip/src/include/ipv4' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-p
[Bug c/37764] New: Macro is not passed to openmp pragma when preprocessor is used
The following openmp test case will not compile when it is first separating
processed by the preprocessor:
$ cat bug2885b.c
#include
#include
#define NT 4
int actual_num_threads;
int main(){
#pragma omp parallel default(none) shared(actual_num_threads) num_threads(NT)
{
#pragma omp master
{
actual_num_threads = omp_get_num_threads();
}
}
printf("actual_num_threads: %d\n",actual_num_threads);
printf("num_threads NT: %d\n",NT);
return 0;
}
$ gcc --version
gcc (GCC) 4.3.1 20080606 (rpm:5)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
$ gcc -fopenmp bug2885b.c; ./a.out
actual_num_threads: 4
num_threads NT: 4
$
$ gcc -E -fopenmp bug2885b.c > bug.c
$ gcc -fopenmp bug.c
bug2885b.c: In function 'main':
bug2885b.c:7: error: 'NT' undeclared (first use in this function)
bug2885b.c:7: error: (Each undeclared identifier is reported only once
bug2885b.c:7: error: for each function it appears in.)
bug2885b.c:7: error: expected integer expression before end of line
$
--
Summary: Macro is not passed to openmp pragma when preprocessor
is used
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37764
[Bug c/37764] Macro is not passed to openmp pragma when preprocessor is used
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-07 22:51 --- *** This bug has been marked as a duplicate of 37023 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37764
[Bug c/37023] Macro replacement for openmp not working if file is preprocessed then compiler
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-10-07 22:51 --- *** Bug 37764 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37023
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
--- Comment #5 from patrick at motec dot com dot au 2008-10-07 23:00 --- This looks like an option parsing problem. Building with the deprecated -mspe=no option suppresses all SPE instructions, which is what I expect/want. There seems to be no need to specify -mabi=no-spe if -mspe=no is set. -mno-spe seems to be broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759
[Bug libstdc++/37718] Demangling of variadic functions
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-10-07 23:10 --- FYI I find at least this specific reported testcase as already fixed by Jason: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00729.html http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00189.html GCC now even produces different mangled names: GNU C++ (GCC) version 4.4.0 20081007 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081007 (experimental), GMP version 4.2.2, MPFR version 2.3.1. 004005c3 w F .text 003f _Z1fIdIiEEiT_DpT0_ 00400602 w F .text 0012 _Z1fIiIEEiT_DpT0_ 00400584 w F .text 003f _Z1fIiIdiEEiT_DpT0_ 004005c3 w F .text 003f int f(double, int) 00400602 w F .text 0012 int f(int, ) 00400584 w F .text 003f int f(int, double, int) -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718
[Bug c/37745] Segmentation Fault Exception with -O and signed array index
--- Comment #3 from gcc at jme dot de 2008-10-07 23:29 ---
Hi Joseph,
because the the problem occurs only with the compiler switch -O.
And the problem occurs not if I place a "printf("xx")" between
the two statements "if" and "for". Therefore, I thought it was a
more target independend optimization problem.
But now I'd checked this behaviour with i386 Linux
(after installing g++ with "apt-get install g++")
-> "gcc-Version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)"
and it works correct there.
I'll post the bug report to the AVR32 Linux site.
Sorry about wasting your time. This was my 1st bug post.
Next time I'll compare the behaviour on my Linux PC before posting.
Thanx,
Joe.(In reply to comment #1)
> Subject: Re: New: Segmentation Fault Exception with -O and
> signed array index
>
> On Mon, 6 Oct 2008, gcc at jme dot de wrote:
>
> > The following code produces a segmentation fault when compiled with -O.
> > Environment is GCC V4.2.2 (also tested with 4.1.2) on AVR32 Linux target.
>
> FSF GCC does not currently support AVR32, so you need to report this bug
> to whoever you got your modified compiler with that support from. The bug
> reporting instructions at say:
>
> What we do not want
>
> ...
>
> * Bugs in releases or snapshots of GCC not issued by the GNU
>Project. Report them to whoever provided you with the release
>
(In reply to comment #1)
> Subject: Re: New: Segmentation Fault Exception with -O and
> signed array index
>
> On Mon, 6 Oct 2008, gcc at jme dot de wrote:
>
> > The following code produces a segmentation fault when compiled with -O.
> > Environment is GCC V4.2.2 (also tested with 4.1.2) on AVR32 Linux target.
>
> FSF GCC does not currently support AVR32, so you need to report this bug
> to whoever you got your modified compiler with that support from. The bug
> reporting instructions at say:
>
> What we do not want
>
> ...
>
> * Bugs in releases or snapshots of GCC not issued by the GNU
>Project. Report them to whoever provided you with the release
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37745
[Bug c++/36665] g++: Internal error: Killed (program cc1plus)
--- Comment #3 from gergio at live dot it 2008-10-07 23:38 --- (In reply to comment #2) > This means GCC is running out of memory. > yes it's true, i have the same problem with ubuntu 8.04 on a thinkpad x60 with 1GB of RAM if usethe system monitor it's clear that it goes out of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36665
[Bug tree-optimization/37756] ICE building object file with -O3 and -combine
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-10-08 00:29 ---
Reduced testcase.
FILE 1:
struct dns_ctx {
int dnsc_serv[6];
unsigned dnsc_nserv;
};
struct dns_ctx dns_defctx;
int dns_add_serv(int t) {
struct dns_ctx *ctx = &dns_defctx;
ctx->dnsc_serv[t] = 0;
}
--- CUT ---
FILE 2:
extern struct dns_ctx dns_defctx;
--- CUT ---
Though I am still figuring out if this is valid code or not really,
dns_defctx's type is incomplete.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-10-08 00:29:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug tree-optimization/37756] ICE building object file with -O3 and -combine
--- Comment #5 from zlynx at acm dot org 2008-10-08 00:54 ---
I think you missed some of your explanation.
Do you mean that it may not be valid to take the address of a global struct
with partial definition? For example in udns_init.c which does not define
dns_defctx, but has this code:
int dns_init(struct dns_ctx *ctx, int do_open) {
if (!ctx)
ctx = &dns_defctx;
[...]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function
--- Comment #24 from zadeck at gcc dot gnu dot org 2008-10-08 02:53 --- Subject: Bug 37448 Author: zadeck Date: Wed Oct 8 02:52:28 2008 New Revision: 140960 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140960 Log: 2008-10-07 Kenneth Zadeck <[EMAIL PROTECTED]> PR rtl-optimization/37448 alloc_pool_desc (elt_size): New field. alloc_pool_desc (created, allocated, current, peak): Make unsigned long. output_info (count): Renamed total_created and made unsigned long. output_info (size): Renamed total_allocated and made unsigned long. alloc-pool.c (create_alloc_pool, empty_alloc_pool, pool_alloc, pool_free): Properly keep track of desc->size. (print_statistics, dump_alloc_pool_statistics): Enhance the printing of statistics to print the number of elements and to use unsigned longs. Modified: trunk/gcc/ChangeLog trunk/gcc/alloc-pool.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function
--- Comment #25 from lucier at math dot purdue dot edu 2008-10-08 03:37 --- I'm sorry, I haven't been reading gcc-patches recently, but this is quite similar to my patch suggested here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html which also "fixed" the counters for bitmaps. The consensus seemed to be to use HOST_WIDEST_INT for the counters (for 64-bit Windows, pointers are 64-bit and longs are 32-bit). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug c/35437] [4.2/4.3/4.4 regression] ICE with struct containing incomplete type
--- Comment #4 from simartin at gcc dot gnu dot org 2008-10-08 04:18 --- Subject: Bug 35437 Author: simartin Date: Wed Oct 8 04:17:27 2008 New Revision: 140961 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140961 Log: gcc/ 2008-10-08 Simon Martin <[EMAIL PROTECTED]> PR c/35437 * expr.c (count_type_elements): Handle ERROR_MARK. gcc/testsuite/ 2008-10-08 Simon Martin <[EMAIL PROTECTED]> PR c/35437 * gcc.dg/struct-parse-2.c: New test. * g++.dg/parse/struct-4.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/struct-4.C branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/struct-parse-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35437
[Bug c/35437] [4.2 regression] ICE with struct containing incomplete type
--- Comment #5 from simartin at gcc dot gnu dot org 2008-10-08 04:29 --- Fixed on 4.3 and 4.4. -- simartin at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.3 4.4.0 Summary|[4.2/4.3/4.4 regression] ICE|[4.2 regression] ICE with |with struct containing |struct containing incomplete |incomplete type |type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35437
[Bug c++/37765] New: Printf of typed null pointer causes a run-time error
#include
int main()
{
printf("%s\n", (char*)0); // run-time error for g++ 4.3.2,
} // while ok for g++ 3.4.4
run-time error:
10 [main] a 1808 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack) Segmentation fault (core dumped)
expexted behavior:print nothing or (null)
workaround: use cout
comment:
Many people still prefer printf to cout. The disabled function make
printf almost useless.
--
Summary: Printf of typed null pointer causes a run-time error
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hosoda-t at palette dot plala dot or dot jp
GCC host triplet: Microsoft Windows XP
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37765
[Bug c++/37766] New: [C++0x] ICE with function's default reference template parameter
The following piece of code:
=
#include
const std::string space(" ");
template
void f()
{
}
int main()
{
f<>();
}
=
leads to a compiler internal error:
=
$ g++ -std=c++0x main.cpp space.cpp
main.cpp: In function 'int main()':
main.cpp:3: internal compiler error: Segmentation fault
=
This bug occurs with any reference template parameter (i.e. not only
std::string&).
I hope my reports are helpful :)
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages='c c++' --disable-nls :
(reconfigured) ../gcc/configure --enable-languages='c c++' : (reconfigured)
../gcc/configure --enable-languages='c c++' --enable-shared --disable-static
--disable-nls
Thread model: posix
gcc version 4.4.0 20081005 (experimental) (GCC)
--
Summary: [C++0x] ICE with function's default reference template
parameter
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: florian dot goujeon at wanadoo dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37766
[Bug c++/37766] [C++0x] ICE with function's default reference template parameter
--- Comment #1 from florian dot goujeon at wanadoo dot fr 2008-10-08 05:42 --- Sorry, bad command line: = $ g++ -std=c++0x main.cpp main.cpp: In function 'int main()': main.cpp:3: internal compiler error: Segmentation fault = -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37766
