New Failure in GCC testsuite from PR35318
Hi Jakub, You recently added gcc.c-torture/compile/pr35318.c to the gcc testsuite. This has introduced a new group of failures for the m32c port because of this error message: pr35318.c: In function 'foo': pr35318.c:7: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' pr35318.c:7: error: 'asm' operand has impossible constraints Looking at the test it appears to assume that a double can be put into register class r, but this is not true for the m32c (and probably other 16-bit ports as well), since doubles occupy two registers. I can add an xfail for the m32c, but I was wondering if it would break the importance of the test if the double type was changed to float ? This would allow the test to pass for the m32c as well. Cheers Nick
The Linux binutils 2.19.51.0.2 is released
This is the beta release of binutils 2.19.51.0.2 for Linux, which is
based on binutils 2009 0204 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.19.51.0.2 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.1:
1. Update from binutils 2009 0204.
2. Support AVX Programming Reference (January, 2009)
3. Improve .s suffix support in x86 disassembler.
4. Add --prefix/--prefix-strip for objdump -S. PR 9784.
5. Change ld --as-needed to resolve undefined references in DSO.
6. Add -Ttext-segment to ld to set address of text segment.
7. Fix ld -r --gc-sections --entry crash with COMDAT group. PR 9727.
8. Improve linker compatibility for g++ 3.4 `.gnu.linkonce.r.*.
9. Add VMS/ia64 support.
10. Improve arm support.
11. Improve cris support.
12. Improve m68k support.
13. Improve mips support.
14. Improve spu support.
Changes from binutils 2.19.50.0.1:
1. Update from binutils 2009 0106.
2. Support AVX Programming Reference (December, 2008)
2. Encode AVX insns with 2byte VEX prefix if possible.
4. Add .s suffix support to swap register operands to x86 assembler.
5. Properly select NOP insns for code alignment in x86 assembler.
6. Fix 2 symbol visibility linker bugs. PRs 9676/9679.
7. Fix an ia64 linker relaxation bug. PR 7036.
8. Fix a symbol versioning bug. PR 7047.
9. Fix unitialized data in linker. PR 7028.
10. Avoid a linker crash on bad input. PR 7023.
11. Fix a linker memory leak. PR 7012.
12. Fix strip/objcopy crash on PT_GNU_RELRO. PR 7011.
13. Improve MacOS support.
14. Fix a COFF linker bug. PR 6945.
15. Add LM32 support.
16. Fix various arm bugs.
17. Fix various avr bugs.
18. Fix various CR16 bugs.
19. Fix various cris bugs.
20. Fix various m32c bugs.
21. Fix various m68k bugs.
22. Fix various mips bugs.
23. Fix various ppc bugs.
24. Fix various s390 bugs.
25. Fix various sparc bugs.
26. Fix various spu bugs.
27. Fix various xtensa bugs.
The file list:
1. binutils-2.19.51.0.2.tar.bz2. Source code.
2. binutils-2.19.50.1.1-2.19.51.0.2.diff.bz2. Patch against the
previous beta source code.
3. binutils-2.19.51.0.2.i686.tar.bz2. IA-32 binary tar ball for RedHat
EL 4.
4. binutils-2.19.51.0.2.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 4.
5. binutils-2.19.51.0.2.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the
invalid may be used uninitialized warning with g++ current
The following code
int bar(int *global)
{
int local;
if(local != global)
return 0;
return local;
}
compiled with gcc/x86/Linux version 4.4.0 20090204 (experimental)
[trunk revision 143938]
trigger warning:
# g++ -Wall -O2 -c test4.cpp
test4.cpp: In function 'int bar(int*)':
test4.cpp:6: warning: 'local' may be used uninitialized in this function
gcc-3.4.6/FreeBSD/x86 and gcc-4.1.2/FedoraCore8/x86 does not warning.
I was tried to find anything similar in bugzilla (including #24639), but fail.
I miss something or I need to file bug report?
Dmitry
Re: Creating imaginary inf/nan in GCC
From: Richard Guenther richard.guent...@gmail.com Thanks, I do want to test the middle-end. However I need to do more than just create the complex expression. I also have to pass it to a builtin that evaluates using MPC like __builtin_csin(). The fortran frontend evaluates complex transcendentals in fortran/simplify.c, not in the middle-end. So it wouldn't test what I want AFAICT. It's not a big deal, the nan cases are error paths that should *avoid* folding via MPC. If you go through memory the compiler should promote that to a register and constant propagate the result, isn't that enough? All the previous tests of this nature were in gcc.dg/torture/builtin-math-*.c and are done at all opt levels including -O0. I think your suggestion works, but only when optimizing. Also, I think it doesn't work with -fdump-tree-original, I'd have to inspect a different dump file. (Any thoughts on which one?) The obsessive part of my brain wants to keep everything the same as the other tests. :-) But I suppose it would work, I just have to tweek it with these things in mind. --Kaveh
Re: invalid may be used uninitialized warning with g++ current
On Wed, Feb 4, 2009 at 1:18 PM, Дмитрий Дьяченко dim...@gmail.com wrote:
The following code
int bar(int *global)
{
int local;
if(local != global)
return 0;
return local;
}
The issue is that GCC does not figure that global cannot point to
local so it does not optimize away the if statement.
Thanks,
Andrew Pinski
Re: invalid may be used uninitialized warning with g++ current
Thanks,
Sorry, but I don't understood - is it impossible to fix, so there are
no needs in bug report?
Or PR about this issue already exists?
Or it's not a bug?
Dmitry
2009/2/5 Andrew Pinski pins...@gmail.com:
On Wed, Feb 4, 2009 at 1:18 PM, Дмитрий Дьяченко dim...@gmail.com wrote:
The following code
int bar(int *global)
{
int local;
if(local != global)
return 0;
return local;
}
The issue is that GCC does not figure that global cannot point to
local so it does not optimize away the if statement.
Thanks,
Andrew Pinski
gcc-4.2-20090204 is now available
Snapshot gcc-4.2-20090204 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 143942 You'll find: gcc-4.2-20090204.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20090204.tar.bz2 C front end and core compiler gcc-ada-4.2-20090204.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20090204.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20090204.tar.bz2 C++ front end and runtime gcc-java-4.2-20090204.tar.bz2 Java front end and runtime gcc-objc-4.2-20090204.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20090204.tar.bz2The GCC testsuite Diffs from 4.2-20090128 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
PATCH: Update classification of aggregates with __m256 ([AVX]: Update x86-64 psABI for aggregates with __m256)
On Tue, Feb 3, 2009 at 8:41 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Feb 1, 2009 at 11:44 AM, H.J. Lu hjl.to...@gmail.com wrote:
Hi,
We like to update x86-64 psABI to pass aggregates of 32 bytes with
single __m256 field
in AVX registers, instead of memory. However, finding the proper
wording seems tricky.
Here is what I got. Any comments?
Here is the revised proposal. Any comments. I will post a gcc
patch soon.
Here is the gcc patch with testcases. OK for trunk?
Thanks.
--
H.J.
gcc/
2009-02-03 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (x86_64_reg_class): Remove X86_64_AVX_CLASS.
(x86_64_reg_class_name): Removed.
(classify_argument): Return 0 if bytes 32. Return 0 if the
first one isn't X86_64_SSE_CLASS or any other ones aren't
X86_64_SSEUP_CLASS when size 16bytes. Don't turn
X86_64_SSEUP_CLASS into X86_64_SSE_CLASS if the preceded one
is X86_64_SSEUP_CLASS. Set AVX modes to 1 X86_64_SSE_CLASS
and 3 X86_64_SSEUP_CLASS.
(construct_container): Remove X86_64_AVX_CLASS. Handle 4
registers with 1 X86_64_SSE_CLASS and 3 X86_64_SSEUP_CLASS.
gcc/testsuite/
2009-02-04 H.J. Lu hongjiu...@intel.com
* gcc.target/x86_64/abi/avx/abi-avx.exp: New.
* gcc.target/x86_64/abi/avx/args.h: Likewise.
* gcc.target/x86_64/abi/avx/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx/avx-check.h: Likewise.
* gcc.target/x86_64/abi/avx/test_m256_returning.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_m256.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_structs.c: Likewise.
* gcc.target/x86_64/abi/avx/test_passing_unions.c: Likewise.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 5119)
+++ gcc/config/i386/i386.c (revision 5120)
@@ -1773,7 +1773,6 @@ enum x86_64_reg_class
X86_64_NO_CLASS,
X86_64_INTEGER_CLASS,
X86_64_INTEGERSI_CLASS,
-X86_64_AVX_CLASS,
X86_64_SSE_CLASS,
X86_64_SSESF_CLASS,
X86_64_SSEDF_CLASS,
@@ -1783,11 +1782,6 @@ enum x86_64_reg_class
X86_64_COMPLEX_X87_CLASS,
X86_64_MEMORY_CLASS
};
-static const char * const x86_64_reg_class_name[] =
-{
- no, integer, integerSI, sse, sseSF, sseDF,
- sseup, x87, x87up, cplx87, no
-};
#define MAX_CLASSES 4
@@ -4863,8 +4857,8 @@ classify_argument (enum machine_mode mod
tree field;
enum x86_64_reg_class subclasses[MAX_CLASSES];
- /* On x86-64 we pass structures larger than 16 bytes on the stack. */
- if (bytes 16)
+ /* On x86-64 we pass structures larger than 32 bytes on the stack. */
+ if (bytes 32)
return 0;
for (i = 0; i words; i++)
@@ -4974,6 +4968,20 @@ classify_argument (enum machine_mode mod
gcc_unreachable ();
}
+ if (words 2)
+ {
+ /* When size 16 bytes, if the first one isn't
+X86_64_SSE_CLASS or any other ones aren't
+X86_64_SSEUP_CLASS, everything should be passed in
+memory. */
+ if (classes[0] != X86_64_SSE_CLASS)
+ return 0;
+
+ for (i = 1; i words; i++)
+ if (classes[i] != X86_64_SSEUP_CLASS)
+ return 0;
+ }
+
/* Final merger cleanup. */
for (i = 0; i words; i++)
{
@@ -4983,10 +4991,15 @@ classify_argument (enum machine_mode mod
return 0;
/* The X86_64_SSEUP_CLASS should be always preceded by
-X86_64_SSE_CLASS. */
+X86_64_SSE_CLASS or X86_64_SSEUP_CLASS. */
if (classes[i] == X86_64_SSEUP_CLASS
- (i == 0 || classes[i - 1] != X86_64_SSE_CLASS))
- classes[i] = X86_64_SSE_CLASS;
+ classes[i - 1] != X86_64_SSE_CLASS
+ classes[i - 1] != X86_64_SSEUP_CLASS)
+ {
+ /* The first one should never be X86_64_SSEUP_CLASS. */
+ gcc_assert (i != 0);
+ classes[i] = X86_64_SSE_CLASS;
+ }
/* X86_64_X87UP_CLASS should be preceded by X86_64_X87_CLASS. */
if (classes[i] == X86_64_X87UP_CLASS
@@ -5107,8 +5120,11 @@ classify_argument (enum machine_mode mod
case V16HImode:
case V4DFmode:
case V4DImode:
- classes[0] = X86_64_AVX_CLASS;
- return 1;
+ classes[0] = X86_64_SSE_CLASS;
+ classes[1] = X86_64_SSEUP_CLASS;
+ classes[2] = X86_64_SSEUP_CLASS;
+ classes[3] = X86_64_SSEUP_CLASS;
+ return 4;
case V4SFmode:
case V4SImode:
case V16QImode:
@@ -5165,7 +5181,6 @@ examine_argument (enum machine_mode mode
case X86_64_INTEGERSI_CLASS:
(*int_nregs)++;
break;
- case X86_64_AVX_CLASS:
case X86_64_SSE_CLASS:
case X86_64_SSESF_CLASS:
case X86_64_SSEDF_CLASS:
@@ -5264,7 +5279,6 @@ construct_container (enum machine_mode m
case
ARM compiler generating never-used constant data structures
I have various constants. If I define them in a header file like this:
static const int my_thing_a = 3;
static const int my_thing_b = 12345;
then everything is nice, if I use them the compiler knows their value
and uses them as literals and it doesn't actually put them into the
.rodata section (which is important because I have a lot of them and
code space is at premium).
Now these things are very closely related, so it would make the program
much clearer is they could be collected in a structure. That is:
struct things { int a; int b; };
and then I could define a global structure
const struct things my_things = { 3, 12345 };
so that I can refer them as my_things.a or my_things.b;
The problem is that I do not want to instantiate the actual things
structure, for the same reason I did not want to instantiate the
individual const int definitions. So, I tried the GCC extension of
compound literals like this:
#define my_things ((struct things) { 3, 12345 })
int func( int x )
{
if ( x )
return my_things.a;
else
return my_things.b;
}
If I compile the above with -O2 or -Os, then if the target is AVR or
x86_64 then the result is what I expected, func() just loads 3 or 12345
then returns and that's all. There is no .rodata generated.
However, compiling for the ARM generates the same function code, but it
also generates the image of things in the .rodata segment. Twice. Even
when it stores 12345 separatelly. The code never actually references
any of them and they are not global thus it is just wasted memory:
.section.rodata
.align 2
.type C.1.1095, %object
.size C.1.1095, 8
C.1.1095:
.word 3
.word 12345
.align 2
.type C.0.1094, %object
.size C.0.1094, 8
C.0.1094:
.word 3
.word 12345
.text
.align 2
.global func2
.type func2, %function
func2:
ldr r3, .L6
cmp r0, #0
moveq r0, r3
movne r0, #3
bx lr
.L7:
.align 2
.L6:
.word 12345
Is there a reason why GCC generates the unused .rodata for the ARM
while for the other two it does not?
I guess I'm doing something fundamentally wrong, as usual...
Thanks,
Zoltan
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the old wiki. (I can send out
the patch later for people's reference.) The updated APIs in general
look good to me. I do have some comments based on our experience with
the initial prototyping:
void register_callbacks(int nregistrations, struct plugin_registration
*registrations);
Instead of passing in an array of plugin_registration objects with a
single register_callbacks call, it's probably better to have the
plugin call a sequence of register_callback with the necessary
information, as shown in the following example:
void plugin_register_callback (const char *plugin_name, enum
plugin_event event, plugin_callback_func callback, void *user_data);
/* In plugin code */
void
plugin_init()
{
...
register_callback (plugin_name, PLUGIN_FINISH_STRUCT, handle_struct, NULL);
register_callback (plugin_name, PLUGIN_FINISH_UNIT,
handle_end_of_compilation_unit, NULL);
...
}
In the function body of register_callback, GCC can then create the
plugin_registration objects and chain them together based on the event
type. Because GCC will need to maintain a list of plugin_registration
objects for each event anyway, we might as well let it create (and
destroy if necessary) the objects instead of leaving the task to the
plugins.
Note that in my example an additional parameter, plugin_name, is added
in register_callback. We found it useful to have the name around when
emitting error messages if something goes wrong during the callback
registration process.
-fplugin=/path/to/plugin.so;arg1=value;arg2=value;...
I am not sure if it is GCC's responsibility to understand key-value
(or any other types of) arguments to plugins. I think GCC should
simply take a string (which, of course, can be something like
arg1=value arg2=value) and pass it (unparsed) to the plugin. It is
plugin's job to parse/process the given arguments (whatever way it
likes). So the prototype of the plugin_init would look like this:
void plugin_init (const char *plugin_name, const char *plugin_arg);
In our current prototype, we implemented the originally proposed flag
-fplugin-arg=, which is associated with the plugin specified in the
most recently parsed -fplugin flag. If a -fplugin-arg flag is used
in the command-line without any preceding -fplugin, an error message
is emitted. Having the plugin name and its arguments concatenated as
currently proposed is also fine, but I would prefer a simple string
(like below) to a series of key-value pairs.
-fplugin=/path/to/plugin.so;arguments
(Note that the double quotes may not needed if the arguments doesn't
contain characters such as spaces.)
Pass Manager
We think it would be quite daunting (and probably open up a can of
worms) to allow plugins to re-order passes. So to get things moving
quickly, in our initial prototype we only support insertion of a new
pass and replacing an existing pass. When registering a new pass with
GCC, the plugin uses the normal register_callback call with the
PLUGIN_PASS_MANAGER_SETUP event. However, instead of registering a
callback function, it passes in a plugin_pass object (see below) that
specifies the opt_pass object of the new pass, the name of the
reference pass, the static instance number of the reference pass, and
whether to insert before/after or replacing the reference pass.
enum pass_positioning_ops
{
PASS_POS_INSERT_AFTER,
PASS_POS_INSERT_BEFORE,
PASS_POS_REPLACE
};
struct plugin_pass
{
struct opt_pass *pass;
const char *reference_pass_name;
/* Insert the pass at the specified instance of the reference pass.
If it's 0, do that for every instance. */
int ref_pass_instance_number;
enum pass_positioning_ops pos_op;
};
/* In plugin code */
void
plugin_init()
{
...
register_callback (plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL, pass_info);
...
}
When registering and positioning a new pass, GCC will search the
passes chained up in all_lowering_passes, all_ipa_passes, and
all_passes (similar to Mozilla dehydra's implementation) to find the
reference pass(es) with the matching name and instance number, and
then either insert the new pass or replace the reference pass.
One caveat with our current implementation is that because the
registration of new plugin passes happens after the command-line
options are parsed, we cannot specify single pass dumping for plugin
passes (e.g. -fdump-tree-newpass). IR dumping of plugin passes is
enabled only when the dump-all flags (e.g. -fdump-tree-all) are
specified.
What do people think about this pass registration/positioning
interface that I described? (Again, I will send out our patch later so
that people can get a better idea if my description is not clear
enough.)
Le-chun Wu
On Mon, Feb 2, 2009 at 2:42
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Wed, Feb 04, 2009 at 05:04:10PM -0800, Le-Chun Wu wrote: -fplugin=/path/to/plugin.so;arg1=value;arg2=value;... I am not sure if it is GCC's responsibility to understand key-value (or any other types of) arguments to plugins. I think GCC should simply take a string (which, of course, can be something like arg1=value arg2=value) and pass it (unparsed) to the plugin. It is plugin's job to parse/process the given arguments (whatever way it likes). Please let GCC do this, so that argument parsing can be (A) centralized, and (B) standardized. Otherwise the right way to pass arguments will end up different for every plugin. -- Daniel Jacobowitz CodeSourcery
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #13 from jakub at gcc dot gnu dot org 2009-02-04 08:18 --- Even if it fixes just PR38292, I'd say it would be worth applying. I'll bootstrap/regtest and submit it then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug target/39076] internal compiler error when cross-compiling flac
--- Comment #6 from ramana dot r at gmail dot com 2009-02-04 08:34 --- (In reply to comment #5) (In reply to comment #4) Looking at the dumps this rtx is generated by the rename registers pass in 4.3.x . In trunk however rename register does not generate this rtx and hence there is no problem. It could still be latent but one has to dig deeper. A quick comparison of trunk and gcc 4.3 branch shows the following patch being applied in trunk vs. the 4.3 branch. http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html A quick check with the patch at ram...@numenor:~/cos/mycos/gcc/gcc$ svn diff -r137128:137235 regrename.c Index: regrename.c === --- regrename.c (revision 137128) +++ regrename.c (revision 137235) @@ -812,7 +812,7 @@ OP_IN, 0); for (i = 0; i recog_data.n_dups; i++) - *recog_data.dup_loc[i] = copy_rtx (old_dups[i]); + *recog_data.dup_loc[i] = old_dups[i]; for (i = 0; i n_ops; i++) *recog_data.operand_loc[i] = old_operands[i]; if (recog_data.n_dups) Related discussions and patch proposed here. http://gcc.gnu.org/ml/gcc/2009-02/msg00074.html This is essentially a backport of a patch in trunk - A full bootstrap and regression test is underway. I've confirmed that this patch fixes the ICE mentioned with the ARM port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused
--- Comment #30 from ubizjak at gmail dot com 2009-02-04 08:57 --- (In reply to comment #29) A similar problem was fixed with PR38533, is this still an issue? TYPE=double: gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc: atlasmm 60 1000 0.208 2076.79 gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math atlasmm 60 1000 0.272 1588.14 TYPE=float: gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc atlasmm 60 1000 0.176 2454.39 gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math atlasmm 60 1000 0.168 2571.28 FLOAT case is OK now, but we regressed somehow. DOUBLE case still shows problem and runtime regression too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug c/39093] inline code optimized wrong with -O3
--- Comment #1 from schwab at suse dot de 2009-02-04 09:33 --- char* pw = (char*) bcAtomCompareExchange((void**) px, py, pz); This is violating the C aliasing rules. Declare px as void* to fix that. *** This bug has been marked as a duplicate of 21920 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|inline code optimized wrong |inline code optimized wrong |with -O3|with -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39093
[Bug c/21920] aliasing violations
--- Comment #137 from schwab at suse dot de 2009-02-04 09:33 --- *** Bug 39093 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||ricardo at teli dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #8 from rguenther at suse dot de 2009-02-04 09:35 --- Subject: Re: PTA constraint processing for *x = y is wrong On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote: --- Comment #7 from dberlin at gcc dot gnu dot org 2009-02-04 00:29 --- Subject: Re: PTA constraint processing for *x = y is wrong On Tue, Feb 3, 2009 at 9:24 AM, rguenther at suse dot de gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from rguenther at suse dot de 2009-02-03 14:24 --- Subject: Re: PTA constraint processing for *x = y is wrong On Tue, 3 Feb 2009, dberlin at dberlin dot org wrote: Subject: Re: PTA constraint processing for *x = y is wrong There used to be a *ANYTHING = ANYTHING constraint + ANYTHING containing all the variables pointing to ANYTHING that would have taken care of this. You certainly don't want to dynamically add all variables at solving time yourself, since that can't be optimized. This is the reason it works for ESCAPED, there we have an *ESCAPED = ESCAPED constraint. It doesn't work for CALLUSED though, I have a simple fix (CALLUSED is not big usually, so just not using it as a placeholder fixes the issue here). For the ANYTHING problem I have just dealt with it in do_ds_constraint (I'll post an updated patch soon after testing finished). My onl concern is practicality. The last time I did this solely at solving time it was ridiculously slow on large cases, since the solver is much better at difference propagation. Do you remember what testcase(s) this was? I can certainly time removing the shortcutting against handling *ANYTHING (and I'll try to come up with a testcase that is not fixed with just removing the shortcutting). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused
--- Comment #31 from bonzini at gnu dot org 2009-02-04 11:22 --- Created an attachment (id=17241) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17241action=view) source code to reproduce the bug Code from PR27827 that still regresses (also with -DTYPE=float, so it's not a target-specific issue; the numbers Uros posted used different code for float and double) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug target/28481] [4.2/4.3/4.4 Regression] uses memory where it can use registers
--- Comment #11 from bonzini at gnu dot org 2009-02-04 11:24 --- Reconfirmed: $ ./xgcc -B. serpent.c -O2 -S -o -| wc -l = 1380 $ ./xgcc -B. serpent.c -fno-tree-reassoc -O2 -S -o -| wc -l = 1304 -- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|2008-09-20 15:06:05 |2009-02-04 11:24:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-04 12:16 ---
Testcase that is not fixed with removing the short-cutting:
int i;
long __attribute__((noinline,const)) bar(int ***p) { return (long)p; }
void __attribute__((noinline))
foo(void)
{
int *y;
int **a = y, **x;
int ***p;
long b;
b = bar(a);
p = (int ***)b;
x = *p;
*x = i;
*y = 0;
}
extern void abort (void);
int main()
{
i = 1;
foo ();
if (i != 0)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-04 12:26
---
This one fails on trunk (where we fall back to anything for empty points-to
sets, so just add some unrelated j and the vops are wrong):
int i;
long __attribute__((noinline,const)) bar(int ***p) { return (long)p; }
void __attribute__((noinline))
foo(void)
{
int j;
int *y = j;
int **a = y, **x;
int ***p;
long b;
b = bar(a);
p = (int ***)b;
x = *p;
*x = i;
*y = 0;
}
extern void abort (void);
int main()
{
i = 1;
foo ();
if (i != 0)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-04 12:31
---
This one fails also on the branches that have PTA.
int i;
long __attribute__((noinline,const)) bar(int ***p) { return (long)p; }
extern void abort (void);
int main()
{
int j;
int *y = j;
int **a = y, **x;
int ***p;
long b;
b = bar(a);
p = (int ***)b;
x = *p;
*x = i;
i = 1;
*y = 0;
if (i != 0)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.3 4.2.4 4.3.3 4.4.0
Known to work||4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-04 12:37 --- Which makes it a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|PTA constraint processing |[4.2/4.3/4.4 Regression] PTA |for *x = y is wrong |constraint processing for *x ||= y is wrong Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #80 from bonzini at gnu dot org 2009-02-04 12:45 --- Brad, can you produce new stats? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #16 from bonzini at gnu dot org 2009-02-04 12:47 --- Andrew, if you point me to the patch I'll be glad to pick it up. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
--- Comment #1 from pedro dot lamarao at mndfck dot org 2009-02-04 13:02
---
I can confirm this bug on my system.
[psi...@joana GCC]$ uname -a
Linux joana 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST 2009
i686 i686 i386 GNU/Linux
[psi...@joana GCC]$ g++ -v
Using built-in specs.
Target: i386-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-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--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-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
[psi...@joana GCC]$ g++-4.4 -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../trunk/configure --prefix=/opt/gcc-4.4 --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++ --with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.4.0 20090204 (experimental) (GCC)
[psi...@joana GCC]$ cat test.cpp
struct B
{
int b;
};
B b;
struct A
{
B *operator-() const
{
return b;
}
A () {}
};
A a;
int foo ()
{
return a-b;
}
[psi...@joana GCC]$ g++ -c -o 43.o test.cpp
[psi...@joana GCC]$ g++-4.4 -c -o 44.o test.cpp
[psi...@joana GCC]$ nm 43.o
0039 t _GLOBAL__I_b
T _Z3foov
0016 t _Z41__static_initialization_and_destruction_0ii
W _ZN1AC1Ev
W _ZNK1AptEv
0004 B a
B b
[psi...@joana GCC]$ nm 44.o
0039 t _GLOBAL__I_b
T _Z3foov
0016 t _Z41__static_initialization_and_destruction_0ii
W _ZN1AC1Ev
W _ZNK1AdtEv
U __gxx_personality_v0
0004 B a
B b
--
pedro dot lamarao at mndfck dot org changed:
What|Removed |Added
CC||pedro dot lamarao at mndfck
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug c/35433] [4.2/4.3 regression] ICE with typeof and ternary operator
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-04 13:07 --- Subject: Bug 35433 Author: jsm28 Date: Wed Feb 4 13:07:43 2009 New Revision: 143922 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143922 Log: PR c/35433 * c-typeck.c (composite_type): Set TYPE_SIZE and TYPE_SIZE_UNIT for composite type involving a zero-length array type. testsuite: * gcc.dg/init-bad-6.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/init-bad-6.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-typeck.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35433
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-04 13:39 ---
Just doing:
@@ -,12 +,18 @@ write_unqualified_name (const tree decl)
else if (DECL_OVERLOADED_OPERATOR_P (decl))
{
operator_name_info_t *oni;
+ enum tree_code code = DECL_OVERLOADED_OPERATOR_P (decl);
+
if (DECL_ASSIGNMENT_OPERATOR_P (decl))
oni = assignment_operator_name_info;
else
-oni = operator_name_info;
+{
+ oni = operator_name_info;
+ if (code == COMPONENT_REF)
+code = ARROW_EXPR;
+}
- write_string (oni[DECL_OVERLOADED_OPERATOR_P (decl)].mangled_name);
+ write_string (oni[(int) code].mangled_name);
}
else if (VAR_OR_FUNCTION_DECL_P (decl) ! TREE_PUBLIC (decl)
DECL_NAMESPACE_SCOPE_P (decl)
is sufficient for the mangling, but still operator. appears in dumps etc.
instead of operator-, and I guess the name - mangled name stuff in
write_expression won't do the right thing either. So, either the operators.def
change should be reverted and dt should use a different code from COMPONENT_REF
(or no code at all and just write_string (dt). Or operator- should be
parsed and handled as operator with ARROW_EXPR code rather than COMPONENT_REF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-04 13:54 --- Created an attachment (id=17242) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17242action=view) gcc44-pr39095.patch Patch I'm going to bootstrap/regtest. I think changing code for operator- in all places is more risky than this. Jason, does this look ok? -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug testsuite/39096] New: should not try to run -flto or -fwhopr testsuite if lto lang not defined.
you get 10s of thousands of errors -- Summary: should not try to run -flto or -fwhopr testsuite if lto lang not defined. Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zadeck at naturalbridge dot com GCC host triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39096
[Bug middle-end/38157] -fconserve-stack enabled by default
--- Comment #4 from bonzini at gnu dot org 2009-02-04 14:36 --- Fixed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
--- Comment #4 from jason at redhat dot com 2009-02-04 15:57 --- Subject: Re: [4.4 Regression] Mangling changes break ABI OK. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug target/37488] register allocation spills floats needlessly
--- Comment #2 from bonzini at gnu dot org 2009-02-04 15:57 ---
minimized testcase:
void test(char *ip, double *reg_f)
{
static void * const addrs[] = {L1, L2};
double reg_f_a;
reg_f_a = 0.0;
goto *addrs[*++ip];
L1:
reg_f_a += reg_f[*++ip];
goto *addrs[*++ip];
L2:
reg_f[0] = reg_f_a;
}
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-04 15:57:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug target/37488] register allocation spills floats needlessly
--- Comment #3 from bonzini at gnu dot org 2009-02-04 16:03 ---
requires computed gotos and floats, even smaller testcase
void test(char *ip, double *reg_f)
{
static void * const addrs[] = {L1, L2};
double reg_f_a;
reg_f_a = 0.0;
goto *addrs[*++ip];
L1: reg_f_a = reg_f[*++ip];
L2: reg_f[0] = reg_f_a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong
--- Comment #13 from dberlin at gcc dot gnu dot org 2009-02-04 16:09 --- Subject: Re: PTA constraint processing for *x = y is wrong I don't remember offhand. At one point during 4.2 we used to compute the anything set exactly, and it led to massive issues. Of course, most of those were because the anything set had hundreds or thousands of SFT's :). I'm happy to go with your idea for fixing since fixing shortcutting won't fix it, except for two things: 1. ANYTHING is really limited to all addressable variables (IE address taken and escaping), instead of all variables. It was never meant to represent completely unknown (IE user has set pointer to (char *) 0xdeadbeef). ISTM the set you union in should be based on CALLUSED and ESCAPED or something thereof, or at least should be computable with constraints during solving, and unioned in when it changes. The way off the top of my head to do this is to simply stop using ANYTHING, and use ANYTHING directly, and then have ANYTHING = CALLUSED and ANYTHING = ESCAPED. Assuming you hate that idea for some reason 2. It's probably a lot faster to make a bitmap of these and update it, then union in the bitmap, than to iterate over all varinfos all the time. ISTM you are trying to avoid doing #1 by adding all variables, even though this is going to give you worse than necessary results. Intel actually iterates points-to solving in order to compute the set of nonlocal locations without explicitly adding the set everywhere. See the description of nloc in section 4.1 of On the Importance of Points=To Analysis and Other Memory Disambiguation Methods For C Programs On Wed, Feb 4, 2009 at 4:35 AM, rguenther at suse dot de gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from rguenther at suse dot de 2009-02-04 09:35 --- Subject: Re: PTA constraint processing for *x = y is wrong On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote: --- Comment #7 from dberlin at gcc dot gnu dot org 2009-02-04 00:29 --- Subject: Re: PTA constraint processing for *x = y is wrong On Tue, Feb 3, 2009 at 9:24 AM, rguenther at suse dot de gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from rguenther at suse dot de 2009-02-03 14:24 --- Subject: Re: PTA constraint processing for *x = y is wrong On Tue, 3 Feb 2009, dberlin at dberlin dot org wrote: Subject: Re: PTA constraint processing for *x = y is wrong There used to be a *ANYTHING = ANYTHING constraint + ANYTHING containing all the variables pointing to ANYTHING that would have taken care of this. You certainly don't want to dynamically add all variables at solving time yourself, since that can't be optimized. This is the reason it works for ESCAPED, there we have an *ESCAPED = ESCAPED constraint. It doesn't work for CALLUSED though, I have a simple fix (CALLUSED is not big usually, so just not using it as a placeholder fixes the issue here). For the ANYTHING problem I have just dealt with it in do_ds_constraint (I'll post an updated patch soon after testing finished). My onl concern is practicality. The last time I did this solely at solving time it was ridiculously slow on large cases, since the solver is much better at difference propagation. Do you remember what testcase(s) this was? I can certainly time removing the shortcutting against handling *ANYTHING (and I'll try to come up with a testcase that is not fixed with just removing the shortcutting). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug libgomp/39098] New: FAIL: libgomp.fortran/reduction3.f90 at -O1 and above
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/reduction3.f90 -B/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/ -I/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp -I/home/dave/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O1 -B/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/../libgfortran/.libs -L/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/.libs -lgomp -L/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/../libgfortran/.libs -lgfortranbegin -lgfortran -lm -o ./reduction3.exe(timeout = 300) PASS: libgomp.fortran/reduction3.f90 -O1 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/../libgfortran/.libs:.:/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/./libgomp/../libgfortran/.libs:/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/libstdc++-v3/.libs:/home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/libgomp/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/opt/gnu/gcc/gcc-4.3.3/lib:/home/dave/opt/gnu/lib FAIL: libgomp.fortran/reduction3.f90 -O1 execution test Starting program: /home/dave/gnu/gcc/objdir/arm-none-linux-gnueabi/libgomp/testsuite/reduction3.xg [Thread debugging using libthread_db enabled] [New Thread 0x4030b000 (LWP 24657)] [New Thread 0x40b0b450 (LWP 24658)] [New Thread 0x4130b450 (LWP 24659)] [Switching to Thread 0x4030b000 (LWP 24657)] Breakpoint 2, _gfortran_abort () at ../../../gcc/libgfortran/intrinsics/abort.c:39 39abort (); (gdb) bt #0 _gfortran_abort () at ../../../gcc/libgfortran/intrinsics/abort.c:39 #1 0x8924 in MAIN__ () at /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/reduction3.f90:52 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: arm-none-linux-gnueabi Configured with: ../gcc/configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi --enable-languages=c,c++,fortran --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --enable-checking=release --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/home/dave/opt/gnu Thread model: posix gcc version 4.4.0 20090202 (experimental) [trunk revision 143869] (GCC) (gdb) p r $1 = 3 (gdb) p ra $2 = (6.5, 6.5, 4, 4) -- Summary: FAIL: libgomp.fortran/reduction3.f90 at -O1 and above Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39098
[Bug c++/19618] Does warn if bit-fields exceed the size of bool types
--- Comment #4 from tydeman at tybor dot com 2009-02-04 16:16 ---
/*
* _Bool bit-fields: C99: 6.7.2.1, paragraph 3 along with Defect Report 335.
* _Bool bit-fields of size up to CHAR_BIT must be supported.
*/
#include limits.h /* CHAR_BIT */
int main(void){
struct bits {
int: 0;
_Bool : 0; /* force alignment */
_Bool bbf1 : 1; /* holds values 0 and 1 */
_Bool bbf8 : CHAR_BIT; /* must be supported */
} bits;
return 0;
}
The above code fails to compile in gcc 4.3.2-7
The error message is:
error: width of 'bbf8' exceeds its type
A _Bool is one storage unit, so is CHAR_BIT bits.
Therefore, _Bool bit-fields of size 0, 1, 2, ... CHAR_BIT
must be supported.
--
tydeman at tybor dot com changed:
What|Removed |Added
CC||tydeman at tybor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19618
[Bug c/35433] [4.2 regression] ICE with typeof and ternary operator
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-04 13:09 --- Fixed for 4.3.4 and 4.4.0. Not planning to work on backport to 4.2 branch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to fail||4.2.4 4.3.3 Known to work||4.3.4 4.4.0 Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE with |with typeof and ternary |typeof and ternary operator |operator| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35433
[Bug target/37488] register allocation spills floats needlessly
--- Comment #4 from bonzini at gnu dot org 2009-02-04 16:22 --- We get a wrong choice of class a1 (r59,l0) best FLOAT_REGS, cover FLOAT_REGS (remember this is with -mfpmath=sse) despite the preferred reload class is indeed SSE_REGS. But then, we get the spill even without SSE math. -- bonzini at gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug libgomp/39098] FAIL: libgomp.fortran/reduction3.f90
--- Comment #1 from danglin at gcc dot gnu dot org 2009-02-04 16:26 --- Actually, test also fails at -O0: FAIL: libgomp.fortran/reduction3.f90 -O0 execution test FAIL: libgomp.fortran/reduction3.f90 -O1 execution test FAIL: libgomp.fortran/reduction3.f90 -O2 execution test FAIL: libgomp.fortran/reduction3.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/reduction3.f90 -O3 -fomit-frame-pointer -funroll-loops e xecution test FAIL: libgomp.fortran/reduction3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/reduction3.f90 -O3 -g execution test FAIL: libgomp.fortran/reduction3.f90 -Os execution test -- danglin at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: |FAIL: |libgomp.fortran/reduction3.f|libgomp.fortran/reduction3.f |90 at -O1 and above |90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39098
[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong
--- Comment #14 from rguenther at suse dot de 2009-02-04 16:26 --- Subject: Re: [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote: --- Comment #13 from dberlin at gcc dot gnu dot org 2009-02-04 16:09 --- Subject: Re: PTA constraint processing for *x = y is wrong I don't remember offhand. At one point during 4.2 we used to compute the anything set exactly, and it led to massive issues. Of course, most of those were because the anything set had hundreds or thousands of SFT's :). I'm happy to go with your idea for fixing since fixing shortcutting won't fix it, except for two things: 1. ANYTHING is really limited to all addressable variables (IE address taken and escaping), instead of all variables. It was never meant to represent completely unknown (IE user has set pointer to (char *) 0xdeadbeef). Yes, is there a bitmap / array in the PTA graph that I can iterate over instead of all vars? ISTM the set you union in should be based on CALLUSED and ESCAPED or something thereof, or at least should be computable with constraints during solving, and unioned in when it changes. Ah, you mean whenever I see *ANYTHING = x union x into a new STORE_TO_ANYTHING solution and have an explicit *ANYTHING = STORE_TO_ANYTHING constraint (which I of course need to handle properly in do_ds_constraint)? That may be indeed faster. The way off the top of my head to do this is to simply stop using ANYTHING, and use ANYTHING directly, and then have ANYTHING = CALLUSED and ANYTHING = ESCAPED. I don't think CALLUSED or ESCAPED are related here. You can store non-addressables into *ANYTHING. Assuming you hate that idea for some reason 2. It's probably a lot faster to make a bitmap of these and update it, then union in the bitmap, than to iterate over all varinfos all the time. ISTM you are trying to avoid doing #1 by adding all variables, even though this is going to give you worse than necessary results. Intel actually iterates points-to solving in order to compute the set of nonlocal locations without explicitly adding the set everywhere. See the description of nloc in section 4.1 of On the Importance of Points=To Analysis and Other Memory Disambiguation Methods For C Programs I'll have a look there. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug c++/19618] Does warn if bit-fields exceed the size of bool types
--- Comment #5 from joseph at codesourcery dot com 2009-02-04 16:30 --- Subject: Re: Does warn if bit-fields exceed the size of bool types On Wed, 4 Feb 2009, tydeman at tybor dot com wrote: /* * _Bool bit-fields: C99: 6.7.2.1, paragraph 3 along with Defect Report 335. * _Bool bit-fields of size up to CHAR_BIT must be supported. */ I don't know why you think C99 is relevant to a C++ bug report. As I have explained at length before and as we discussed at length at the London WG14 meeting, the width of a type is the number of value and sign bits, so post-TC2 a _Bool:CHAR_BIT bit-field is valid only if the implementation defines _Bool to have CHAR_BIT value bits. GCC defines it to have one value bit with the other bits being padding bits and undefined behavior if you access a _Bool representation with any of the padding bits having a nonzero value (such representations being trap representations). Thus the width of _Bool is 1 with GCC and the diagnostics are required. As you know, TC2 changed the number of bits in an object of the type that is specified if the colon and expression are omitted to the width of an object of the type that would be specified were the colon and expression omitted. in 6.7.2.1 paragraph 3. I have no idea what is required by C++ and whether GCC implements the C++ requirements correctly or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19618
[Bug target/37488] register allocation spills floats needlessly
--- Comment #5 from bonzini at gnu dot org 2009-02-04 16:31 --- The old register allocator chose Register 59 pref FLOAT_SSE_REGS or none but that is not a cover class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug middle-end/23868] [4.2/4.3/4.4 regression] builtin_apply uses wrong mode for multi-hard-register return values
--- Comment #13 from bonzini at gnu dot org 2009-02-04 12:46 --- Christian, any news? -- bonzini at gnu dot org changed: What|Removed |Added CC||chrbr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong
--- Comment #15 from dberlin at gcc dot gnu dot org 2009-02-04 16:37 --- Subject: Re: [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong On Wed, Feb 4, 2009 at 11:26 AM, rguenther at suse dot de gcc-bugzi...@gcc.gnu.org wrote: --- Comment #14 from rguenther at suse dot de 2009-02-04 16:26 --- Subject: Re: [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote: --- Comment #13 from dberlin at gcc dot gnu dot org 2009-02-04 16:09 --- Subject: Re: PTA constraint processing for *x = y is wrong I don't remember offhand. At one point during 4.2 we used to compute the anything set exactly, and it led to massive issues. Of course, most of those were because the anything set had hundreds or thousands of SFT's :). I'm happy to go with your idea for fixing since fixing shortcutting won't fix it, except for two things: 1. ANYTHING is really limited to all addressable variables (IE address taken and escaping), instead of all variables. It was never meant to represent completely unknown (IE user has set pointer to (char *) 0xdeadbeef). Yes, is there a bitmap / array in the PTA graph that I can iterate over instead of all vars? Not right now. ISTM the set you union in should be based on CALLUSED and ESCAPED or something thereof, or at least should be computable with constraints during solving, and unioned in when it changes. Ah, you mean whenever I see *ANYTHING = x union x into a new STORE_TO_ANYTHING solution and have an explicit *ANYTHING = STORE_TO_ANYTHING constraint (which I of course need to handle properly in do_ds_constraint)? That may be indeed faster. Something like that. It is going to be faster than doing it one by one all the time. The way off the top of my head to do this is to simply stop using ANYTHING, and use ANYTHING directly, and then have ANYTHING = CALLUSED and ANYTHING = ESCAPED. I don't think CALLUSED or ESCAPED are related here. You can store non-addressables into *ANYTHING. How? If they are non-addressable, that implies they are not pointed to. I think you are going off the rails here :) If you really want to union ANYTHING into things, the simplest way is to change from doing: ANYTHING = ANYTHING a = y p_4 = ANYTHING p_1 = p_4 p_1 = a x_6 = *p_1 derefaddrtmp.11 = i *x_6 = derefaddrtmp.11 y.0_7 = y to ANYTHING = *ANYTHING ANYTHING = all pointers pre-built or whatever we decided on a = y p_4 = ANYTHING p_1 = p_4 p_1 = a x_6 = *p_1 derefaddrtmp.11 = i *x_6 = derefaddrtmp.11 y.0_7 = y Then p_4 will get the entire anything set, and it will propagate around just like you wanted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug tree-optimization/39094] New: loop_niter_by_eval should deal with a[i_1]
Brute force evaluation of niters does not deal with bb 5: i_10 = i_1 + 1; bb 6: # i_1 = PHI 0(2), i_10(5) # .MEM_11 = PHI .MEM_17(2), .MEM_11(5) if (i_1 = 4) goto bb 3; else goto bb 7; bb 3: D.5476_6 = a._M_instance[i_1]; D.5457_8 = i_1 * 4; D.5458_9 = a._M_instance[0] + D.5457_8; if (D.5476_6 != D.5458_9) goto bb 4; else goto bb 5; where get_val_for cannot handle a._M_instance[i_1]. -- Summary: loop_niter_by_eval should deal with a[i_1] Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39094
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-04 16:50 --- Subject: Bug 39095 Author: jakub Date: Wed Feb 4 16:50:22 2009 New Revision: 143933 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143933 Log: PR c++/39095 * operators.def: Use COMPONENT_REF code for -/pt operator again, remove ./dt operator. * mangle.c (write_expression): Handle COMPONENT_REF after handling ADDR_EXPR, for COMPONENT_REF without ARROW_EXPR inside of it write_string (dt) instead of using operators.def. * g++.dg/abi/mangle31.C: New test. Added: trunk/gcc/testsuite/g++.dg/abi/mangle31.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/operators.def trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug c++/39095] New: [4.4 Regression] Mangling changes break ABI
http://gcc.gnu.org/viewcvs?root=gccview=revrev=140916
seems to break ABI, e.g. 4.4 compiled digikam can't be linked against 4.3
compiled libraries.
struct B
{
int b;
};
B b;
struct A
{
B *operator-() const
{
return b;
}
A () {}
};
A a;
int foo ()
{
return a-b;
}
is mangled as _ZNK1AptEv in g++ 4.3 and below, but as
_ZNK1AdtEv in g++ 4.4.
--
Summary: [4.4 Regression] Mangling changes break ABI
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095
[Bug c++/39095] [4.4 Regression] Mangling changes break ABI
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-04 16:53 --- 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=39095
[Bug tree-optimization/28868] [4.2/4.3/4.4 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-04 10:14 --- I think this is bug is a valid request for FRE to eliminate redundant PHI nodes: bb 4: # c_1 = PHI a_4(D)(2), b_7(D)(3) # d_2 = PHI a_4(D)(2), b_7(D)(3) D.1599_10 = c_1 + d_2; There are no two same PHI nodes in PR23821. I am going to fix this one. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:30:40 |2009-02-04 10:14:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug rtl-optimization/38434] big performance boost from 4.3's -O3 vs. -O2 (in any version) on 3x3 matmul
--- Comment #6 from bonzini at gnu dot org 2009-02-04 12:02 --- We have: 4.34.4 -O2 3.36 3.32 -O3 3.02 3.50 -O3 -funroll-all-loops 2.92 3.45 Interestingly enough, if I _really_ hand-unroll the loop as suggested by the wrong summary, 4.4 is faster than 4.3: 4.34.4 -O2 3.53 3.23 -O3 3.53 3.23 -O3 -funroll-all-loops 3.45 3.18 This means: 1) that -funroll-all-loops is not really affecting the benchmark, but only the test code 2) that the regression is actually at -O3, not at -O2, and there's really no guarantee of what performance you get past -O2 3) ultimately, that this is not a regression, but just an enhancement request: 4.4 -O2 is better, but not as good as 4.3 -O3. --- here is the hand-unrolled loop code: module foo implicit none contains subroutine unroll(a,b,c) real, dimension(3,3) :: a,b,c c(1,1) = a(1,1)*b(1,1) + a(1,2)*b(2,1) + a(1,3)*b(3,1) c(1,2) = a(1,1)*b(1,2) + a(1,2)*b(2,2) + a(1,3)*b(3,2) c(1,3) = a(1,1)*b(1,3) + a(1,2)*b(2,3) + a(1,3)*b(3,3) c(2,1) = a(2,1)*b(1,1) + a(2,2)*b(2,1) + a(2,3)*b(3,1) c(2,2) = a(2,1)*b(1,2) + a(2,2)*b(2,2) + a(2,3)*b(3,2) c(2,3) = a(2,1)*b(1,3) + a(2,2)*b(2,3) + a(2,3)*b(3,3) c(3,1) = a(3,1)*b(1,1) + a(3,2)*b(2,1) + a(3,3)*b(3,1) c(3,2) = a(3,1)*b(1,2) + a(3,2)*b(2,2) + a(3,3)*b(3,2) c(3,3) = a(3,1)*b(1,3) + a(3,2)*b(2,3) + a(3,3)*b(3,3) end subroutine unroll end module foo program main use foo implicit none integer :: k real, dimension(3,3) :: a,b,c, a0, b0 real :: t1, t2 character(len=90) :: line call random_number(a0) call random_number(b0) a = a0 b = b0 call cpu_time(t1) do k=1,10**8 call unroll(a,b,c) end do call cpu_time(t2) print *,subroutine with explicit interface and unroll(1): ,t2-t1, s write (unit=line,fmt='(9G10.3)') c end program main -- bonzini at gnu dot org changed: What|Removed |Added Priority|P2 |P3 Last reconfirmed|2008-12-10 13:36:41 |2009-02-04 12:02:14 date|| Summary|[4.4 Regression] speed |big performance boost from |regression with hand- |4.3's -O3 vs. -O2 (in any |unrolled matmul |version) on 3x3 matmul Target Milestone|4.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434
[Bug c/35235] [4.2/4.3/4.4 Regression] struct/union rvalue qualifiers must not propagate to members
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-04 17:14 --- Working on a patch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-29 07:07:08 |2009-02-04 17:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35235
[Bug c++/19618] Does warn if bit-fields exceed the size of bool types
--- Comment #6 from tydeman at tybor dot com 2009-02-04 17:15 --- Opps. I missed that the bug report was against C++ (I still am learning bugzilla). So, ignore my previous comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19618
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #81 from lucier at math dot purdue dot edu 2009-02-04 17:27 --- Created an attachment (id=17243) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17243action=view) Memory and CPU statistics for 2009/02/04 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #82 from lucier at math dot purdue dot edu 2009-02-04 17:28 --- I still have the bitmap.c patch from http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html in my tree so I don't get meaningless statistics for bitmaps. (Kenny installed in the trunk something like the patch above for alloc-pool.c.) There are more bitmaps allocated than on 2008-09-26 (13GB instead of 12GB). 3GB was allocated in alloc-pool. Execution time was worse, 228.17 user seconds versus 168 seconds. I didn't watch top to estimate the maximum memory usage. This is with euler-8% /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.4.0 20090204 (experimental) [trunk revision 143922] (GCC) Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/39099] New: Local classes cannot be used as template arguments
I've tried defining a local class and then using it as a template argument,
this fails to work.
Here is a very short code example:
#include iostream
template class T
void func2785() {
}
class A {};
int main() {
class B {} b;
func2785A();
func2785B();
}
This bug also in g++ 3.4.6.
--
Summary: Local classes cannot be used as template arguments
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tohava at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39099
[Bug bootstrap/39001] lto branch doesn't build
--- Comment #4 from dnovillo at gcc dot gnu dot org 2009-02-04 17:49 --- Testing patch with the more straightforward of the two suggestions from Cary: http://gcc.gnu.org/ml/gcc/2009-01/msg00105.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39001
[Bug bootstrap/39001] lto branch doesn't build
--- Comment #5 from dnovillo at gcc dot gnu dot org 2009-02-04 18:06 --- Subject: Bug 39001 Author: dnovillo Date: Wed Feb 4 18:05:51 2009 New Revision: 143935 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143935 Log: PR 39001 * toplev.c (eh_personality_decl): Fix comment. * dwarf2out.c (dwarf2out_do_cfi_asm): Return true if current_function_decl is NULL. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/dwarf2out.c branches/lto/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39001
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #83 from dberlin at gcc dot gnu dot org 2009-02-04 18:24 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines These numbers claim a leak of the graph-preds bitmap (and related bitmaps) which are quite clearly freed all the time. These bitmaps are allocated onto the predbitmap obstack, which is released through remove_preds_and_fake_succs. It always executes, so i have trouble understanding why it considers this a leak. On Wed, Feb 4, 2009 at 12:28 PM, lucier at math dot purdue dot edu gcc-bugzi...@gcc.gnu.org wrote: --- Comment #82 from lucier at math dot purdue dot edu 2009-02-04 17:28 --- I still have the bitmap.c patch from http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html in my tree so I don't get meaningless statistics for bitmaps. (Kenny installed in the trunk something like the patch above for alloc-pool.c.) There are more bitmaps allocated than on 2008-09-26 (13GB instead of 12GB). 3GB was allocated in alloc-pool. Execution time was worse, 228.17 user seconds versus 168 seconds. I didn't watch top to estimate the maximum memory usage. This is with euler-8% /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.4.0 20090204 (experimental) [trunk revision 143922] (GCC) Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/39100] New: [4.4 Regression] -fstrict-aliasing miscompilation
typedef struct E
{
int p;
struct E *n;
} *EP;
typedef struct C
{
EP x;
short cn, cp;
} *CP;
__attribute__((noinline)) CP
foo (CP h, EP x)
{
EP pl = 0, *pa = pl;
EP nl = 0, *na = nl;
EP n;
while (x)
{
n = x-n;
if ((x-p 1) == 1)
{
h-cp++;
*pa = x;
pa = ((*pa)-n);
}
else
{
h-cn++;
*na = x;
na = ((*na)-n);
}
x = n;
}
*pa = nl;
*na = 0;
h-x = pl;
return h;
}
int
main (void)
{
struct C c = { 0, 0, 0 };
struct E e[2] = { { 0, e[1] }, { 1, 0 } };
EP p;
foo (c, e[0]);
if (c.cn != 1 || c.cp != 1)
__builtin_abort ();
if (c.x != e[1])
__builtin_abort ();
if (e[1].n != e[0])
__builtin_abort ();
if (e[0].n)
__builtin_abort ();
return 0;
}
is miscompiled on x86_64-linux with -O2, works with -O2 -fno-strict-aliasing
and with 4.3.2. When miscompiled, the *na = 0 store is optimized away.
--
Summary: [4.4 Regression] -fstrict-aliasing miscompilation
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug gcov-profile/38292] corrupted profile info with -O[23] -fprofile-use
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-04 19:51 --- Subject: Bug 38292 Author: jakub Date: Wed Feb 4 19:50:58 2009 New Revision: 143937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143937 Log: PR tree-optimization/38977 PR gcov-profile/38292 * calls.c (special_function_p): Disregard __builtin_ prefix. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-04 19:51 --- Subject: Bug 38977 Author: jakub Date: Wed Feb 4 19:50:58 2009 New Revision: 143937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143937 Log: PR tree-optimization/38977 PR gcov-profile/38292 * calls.c (special_function_p): Disregard __builtin_ prefix. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug libgomp/39098] FAIL: libgomp.fortran/reduction3.f90
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-04 20:00 --- Does it work without -fopenmp? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39098
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-04 20:04 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=136657 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-04 20:04 --- I will have a looksee. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-04 20:04:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-04 20:05 --- Note that the patch only enables us to use PTA results which are likely wrong here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-04 20:13 --- It is caused by revision 136657: http://gcc.gnu.org/ml/gcc-cvs/2008-06/msg00414.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #10 from jv244 at cam dot ac dot uk 2009-02-04 20:53 --- (In reply to comment #9) I hope to patch it soon although I have no such patch right now. Hi Jan, any progress on this one ? I've a core to analyze, but I'm stuck here. Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #18 from bonzini at gnu dot org 2009-02-04 20:54 --- Subject: Bug 37889 Author: bonzini Date: Wed Feb 4 20:54:36 2009 New Revision: 143939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143939 Log: 2009-02-04 Paolo Bonzini bonz...@gnu.org Hans-Peter Nilsson h...@axis.com PR rtl-optimization/37889 * rtlanal.c (rtx_addr_can_trap_p_1): Add offset and size arguments. Move offset handling from PLUS to before the switch. Use new arguments when considering SYMBOL_REFs too. (rtx_addr_can_trap_p): Pass dummy offset and size. (enum may_trap_p_flags): Remove. (may_trap_p_1): Pass size from MEM_SIZE. PR rtl-optimization/38921 * loop-invariant.c (find_invariant_insn): Use may_trap_or_fault_p. * rtl.h (may_trap_after_code_motion_p): Delete prototype. * rtlanal.c (may_trap_after_code_motion_p): Delete. (may_trap_p, may_trap_or_fault_p): Pass 0/1 as flags. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/rtl.h trunk/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot
--- Comment #10 from bonzini at gnu dot org 2009-02-04 20:54 --- Subject: Bug 38921 Author: bonzini Date: Wed Feb 4 20:54:36 2009 New Revision: 143939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143939 Log: 2009-02-04 Paolo Bonzini bonz...@gnu.org Hans-Peter Nilsson h...@axis.com PR rtl-optimization/37889 * rtlanal.c (rtx_addr_can_trap_p_1): Add offset and size arguments. Move offset handling from PLUS to before the switch. Use new arguments when considering SYMBOL_REFs too. (rtx_addr_can_trap_p): Pass dummy offset and size. (enum may_trap_p_flags): Remove. (may_trap_p_1): Pass size from MEM_SIZE. PR rtl-optimization/38921 * loop-invariant.c (find_invariant_insn): Use may_trap_or_fault_p. * rtl.h (may_trap_after_code_motion_p): Delete prototype. * rtlanal.c (may_trap_after_code_motion_p): Delete. (may_trap_p, may_trap_or_fault_p): Pass 0/1 as flags. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/rtl.h trunk/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-04 20:59 ---
On the alias-improvements branch the testcase also fails with
-O -fdelete-null-pointer-checks, so this is definitely a PTA bug.
PTA thinks the points-to set for na_5 is
na_5, is dereferenced, points-to NULL, points-to vars: { nl }
which would definitely enable deleting the store, as nl is a local variable.
The constraints that should make na_5 point to NONLOCAL as well are
h = NONLOCAL
x = NONLOCAL
x_1 = x
*na_5 = x_1
D.1262_20 = *na_5
na_21 = D.1262_20 + 32
na_4 = na_21
na_5 = na_4
relevant unifications are
Unifying x to h
Unifying na_4 to na_5
The PTA bug can be seen with the following simplified testcase:
typedef struct E
{
struct E *n;
} *EP;
void __attribute__((noinline))
foo (EP x)
{
EP nl = 0, *na = nl;
EP n;
while (x)
{
n = x-n;
*na = x;
na = ((*na)-n);
x = n;
}
*na = 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug c/35235] [4.2/4.3/4.4 Regression] struct/union rvalue qualifiers must not propagate to members
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-04 21:02 --- Subject: Bug 35235 Author: jsm28 Date: Wed Feb 4 21:02:42 2009 New Revision: 143940 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143940 Log: PR c/35235 * c-typeck.c (build_component_ref): Do not copy qualifiers from non-lvalue to component. testsuite: * gcc.dg/c99-array-lval-8.c: New test. Added: branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-array-lval-8.c Modified: branches/c-4_5-branch/gcc/ChangeLog.c45 branches/c-4_5-branch/gcc/c-typeck.c branches/c-4_5-branch/gcc/testsuite/ChangeLog.c45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35235
[Bug debug/39086] [4.4 Regression] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-04 21:14 --- It fails with gcc version 4.4.0 20090116 (experimental) [trunk revision 143440] (GCC) But I don't have anything older to try it with on that machine. It did work with gcc version 4.4.0 20081229 (experimental) [trunk revision 142951] (GCC) on i386-darwin8.11. I don't have time right now to figure out if this is really a regression or not or a reduced testcase but I am going to mark it as a regression so at least someone will look at it. I really think it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu Keywords||ice-on-valid-code Summary|Failing assert in |[4.4 Regression] Failing |dwarf2out.c:5770 when |assert in dwarf2out.c:5770 |compiling with -fno-tree-sra|when compiling with -fno- ||tree-sra Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #6 from dberlin at gcc dot gnu dot org 2009-02-04 21:16 ---
Subject: Re: [4.4 Regression] -fstrict-aliasing
miscompilation
On Wed, Feb 4, 2009 at 3:59 PM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-04 20:59
---
On the alias-improvements branch the testcase also fails with
-O -fdelete-null-pointer-checks, so this is definitely a PTA bug.
PTA thinks the points-to set for na_5 is
na_5, is dereferenced, points-to NULL, points-to vars: { nl }
which would definitely enable deleting the store, as nl is a local variable.
The constraints that should make na_5 point to NONLOCAL as well are
h = NONLOCAL
x = NONLOCAL
x_1 = x
*na_5 = x_1
D.1262_20 = *na_5
na_21 = D.1262_20 + 32
na_4 = na_21
na_5 = na_4
relevant unifications are
Unifying x to h
Unifying na_4 to na_5
Given those constraints, there is no way it will or should point to NONLOCAL.
na_5 doesn't actually point to anything given these constraints (IE
there is no na_5 = something), unless D.1262_20 + 32 points to
something, which it doesn't give the above constraints.
Basically
*a = b
c = *a
Does not imply that c = b if a is empty, which is what is happening
here, AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-04 21:18 --- Following do_ds_constraint shows *na_2 = x_1 nl - *na_2 = derefaddrtmp.7 nl - NULL *na_2 = x_1 NULL - ESCAPED NONLOCAL *na_2 = derefaddrtmp.7 NULL - NULL where on the lhs of - we show DELTA and on the rhs we show the rhs solution. The problem is obviously that DELTA doesn't include nl anymore when the rhs solution includes NONLOCAL. We do have a cycle here, can we really do DELTA processing there? Note that the constraint graph looks funny to me (but I never looked at them until now) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug libgomp/39098] FAIL: libgomp.fortran/reduction3.f90
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-04 21:22 --- Subject: Re: FAIL: libgomp.fortran/reduction3.f90 Does it work without -fopenmp? Yes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39098
[Bug bootstrap/39001] lto branch doesn't build
--- Comment #6 from dnovillo at gcc dot gnu dot org 2009-02-04 21:23
---
The recent patch only fixes the case for x86_64. This is still broken on ppc.
Will try to implement the first suggestion from
http://gcc.gnu.org/ml/gcc/2009-01/msg00074.html
/* confdefs.h. */
#define PACKAGE_NAME GNU C Runtime Library
#define PACKAGE_TARNAME libgcc
#define PACKAGE_VERSION 1.0
#define PACKAGE_STRING GNU C Runtime Library 1.0
#define PACKAGE_BUGREPORT
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
$ /home/dnovillo/lto/native/bld/./gcc/xgcc
-B/home/dnovillo/lto/native/bld/./gcc/
-B/home/dnovillo/lto/native/powerpc64-unknown-linux-gnu/bin/
-B/home/dnovillo/lto/native/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/dnovillo/lto/native/powerpc64-unknown-linux-gnu/include -isystem
/home/dnovillo/lto/native/powerpc64-unknown-linux-gnu/sys-include -c -g -O2
conftest.c 5
conftest.c:16: 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39001
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-04 21:36 ---
The following works (on the branch, with added NONLOCAL = *NONLOCAL
constraint):
ANYTHING = ANYTHING
READONLY = READONLY
ESCAPED = *ESCAPED
ESCAPED = ESCAPED + UNKNOWN
*ESCAPED = NONLOCAL
NONLOCAL = NONLOCAL
NONLOCAL = ESCAPED
NONLOCAL = *NONLOCAL
CALLUSED = *CALLUSED
CALLUSED = CALLUSED + UNKNOWN
INTEGER = ANYTHING
x = NONLOCAL
nl = NULL
n_5 = *x_1
*na_2 = x_1
ESCAPED = x_1
D.1242_6 = *na_2
na_7 = D.1242_6
x_1 = x
x_1 = n_5
na_2 = nl
na_2 = na_7
derefaddrtmp.7 = NULL
*na_2 = derefaddrtmp.7
ESCAPED = NULL
...
NULL = { }
ANYTHING = { ANYTHING }
READONLY = { READONLY }
ESCAPED = same as n_5
NONLOCAL = same as n_5
CALLUSED = { }
INTEGER = { ANYTHING }
x = { NONLOCAL }
nl = { NULL ESCAPED NONLOCAL }
n_5 = { NULL ESCAPED NONLOCAL }
x_1 = same as n_5
na_2 = { NULL ESCAPED NONLOCAL nl }
D.1242_6 = { NULL ESCAPED NONLOCAL }
na_7 = same as D.1242_6
derefaddrtmp.7 = { NULL }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
[Bug rtl-optimization/39076] internal compiler error when cross-compiling flac
--- Comment #7 from ramana dot r at gmail dot com 2009-02-04 21:56 --- (In reply to comment #6) This has now been committed as revision 143942 in the 4.3 branch - Sven, could you check and get back if you still see a problem . If not this bug can be closed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug c/35435] [4.2/4.3/4.4 regression] ICE with attribute tls_model in typedef
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-04 22:22 --- Testing a patch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-15 01:33:17 |2009-02-04 22:22:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35435
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-04 22:51 --- It appearanlty does not fix my bash build. I'm double-checking now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-04 23:16 --- jobs.c calls fork(), but special_function_p seems to miss that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug target/36409] Additional instructions in prologue and epilogue.
--- Comment #1 from ramana dot r at gmail dot com 2009-02-04 23:38 ---
4.4.0 with revision id 143499 generates the following code with -O3 , -O2 and
-Os . The same code is generated for 4.3.3 as well
sub sp, sp, #8
mov r3, sp
mov r2, #0
stmia r3, {r0, r1}
str r2, [r0, #0]
add sp, sp, #8
bx lr
Clearly things have gotten worse with an extra stmia being generated in this
case where the argument registers are being saved on the stack with the stmia
instruction.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
CC||rearnsha at arm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36409
[Bug debug/39086] [4.4 Regression] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-04 23:54 --- It is a regression introduced between revision 139502 and revision 139996. I am doing a binary search on it. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-04 23:54:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug c++/39099] Local classes cannot be used as template arguments
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-05 00:46 --- This is not a bug, but Standard conforming behaviour. The next C++ Standard will be different here. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39099
[Bug c/35435] [4.2/4.3/4.4 regression] ICE with attribute tls_model in typedef
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-02-05 01:18 --- Subject: Bug 35435 Author: jsm28 Date: Thu Feb 5 01:18:02 2009 New Revision: 143948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143948 Log: PR c/35435 * c-common.c (handle_tls_model_attribute): Ignore attribute for non-VAR_DECLs without checking DECL_THREAD_LOCAL_P. testsuite: * gcc.dg/tls/diag-6.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tls/diag-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35435
[Bug inline-asm/39048] gcc 4.4.0 20090131 - Extra underscore hides libgcc's soft-fp functions from Testsuite causing FAILs + naming error in libgcc
--- Comment #2 from rob1weld at aol dot com 2009-02-05 03:43 --- (In reply to comment #1) You can use following (slightly wrapped...) patch to enable 128bit soft-fp on Solaris: Thanks, I'll try that this week (working on a P1). Please read the ChangeLog: ../gcc_trunk/ChangeLog: * configure.ac: Recognize GNU/kOpenSolaris (*-*-kopensolaris*-gnu). ../gcc_trunk/ChangeLog: * libtool.m4: Add kfreebsd*-gnu and knetbsd*-gnu. You might want to change that to allow for the new Targets k*bsd and kopensolaris (OpenSolaris Kernel with *BSD and OpenSolaris Kernel with GNU Libc): @@ -3058,6 +3058,9 @@ -i[34567]86-*-linux* | x86_64-*-linux*) +i[34567]86-*-linux* | x86_64-*-linux* *-*-kopensolaris*-gnu kfreebsd*-gnu* knetbsd*-gnu* x86_64-*kfreebsd*-gnu) Thanks for the Tip, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39048
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #47 from rob1weld at aol dot com 2009-02-05 04:06 --- (In reply to comment #46) As I understand it, the complaint here is that GCC_EXEC_PREFIX being set affects HOSTCC, when HOSTCC is itself some other GCC. ... It is true (for most of us in this thread) that GCC_EXEC_PREFIX is being set to a value and we agree that it is likely that the value set would NOT work in all circumstances. One example is inherently derived from where we see it being set (wrongly), during make -i check _PRIOR_ to running make install. We (some of us) can see that the Testsuite Results vary WILDLY (sometimes) depending on the Installed Gcc versus the Tested Gcc. Here is an EXTREME example: On OpenSolaris 2008.11 install gcc version 4.4.0 20090131 trunk revision 143817 ./configured with these options: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Now with gcc version 4.4.0 20090131 trunk revision 143817 installed ./configure gcc version 4.4.0 20090204 trunk revision 143918 using these options: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld Now run gmake and do the Three-Stage Build. DO NOT INSTALL GCC. Run gmake -i check and save the logs (that you want to compare). # cd ../gcc_build # cp gcc/testsuite/gcc/gcc.log gcc/testsuite/gcc/gcc.log.PRE-INSTALL # cp gcc/testsuite/gnat/gnat.log gcc/testsuite/gnat/gnat.log.PRE-INSTALL # cp gcc/testsuite/obj-c++/obj-c++.log gcc/testsuite/obj-c++/obj-c++.log.PRE-INSTALL # cp gcc/testsuite/g++/g++.log gcc/testsuite/g++/g++.log.PRE-INSTALL # cp gcc/testsuite/gfortran/gfortran.log gcc/testsuite/gfortran/gfortran.log.PRE-INSTALL # cp gcc/testsuite/objc/objc.log gcc/testsuite/objc/objc.log.PRE-INSTALL # cp gcc/testsuite/ada/acats/acats.log gcc/testsuite/ada/acats/acats.log.PRE-INSTALL # cp i386-pc-solaris2.11/libstdc++-v3/testsuite/libstdc++.log i386-pc-solaris2.11/libstdc++-v3/testsuite/libstdc++.log.PRE-INSTALL # cp i386-pc-solaris2.11/libgomp/testsuite/libgomp.log i386-pc-solaris2.11/libgomp/testsuite/libgomp.log.PRE-INSTALL # cp i386-pc-solaris2.11/libffi/testsuite/libffi.log i386-pc-solaris2.11/libffi/testsuite/libffi.log.PRE-INSTALL # cp i386-pc-solaris2.11/libjava/testsuite/libjava.log i386-pc-solaris2.11/libjava/testsuite/libjava.log.PRE-INSTALL # cp i386-pc-solaris2.11/libmudflap/testsuite/libmudflap.log i386-pc-solaris2.11/libmudflap/testsuite/libmudflap.log.PRE-INSTALL Now Install gcc and then re-run gmake -i check and _sometimes_ you will get _some_ results that are different (and sometimes you will not). So let us see what happens when gcc version 4.4.0 20090131 trunk revision 143817 (./configured to use GNU's linker) is used to build gcc version 4.4.0 20090204 trunk revision 143918 (configured to use Sun's linker): # ../gcc_trunk/contrib/compare_tests ../gcc_build/gcc/testsuite/gcc/gcc.log.PRE-INSTALL ../gcc_build/gcc/testsuite/gcc/gcc.log | wc -l 0 It look like the C compiler is OK (it _might_ not be). Lets try C++: # ../gcc_trunk/contrib/compare_tests ../gcc_build/gcc/testsuite/g++/g++.log.PRE-INSTALL ../gcc_build/gcc/testsuite/g++/g++.log | wc -l 4140 Woah! Broken. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug middle-end/39101] New: [4.4 Regression] Null pointer dereference in delay slot
... mkdir -p ada/bldtools/sinfo rm -f ada/bldtools/sinfo/sinfo.ads ada/bldtools/sinfo/xsinfo.adb cp -p ../../gcc/gcc/ada/sinfo.ads ../../gcc/gcc/ada/xsinfo.adb ada/bldtools/sinfo (cd ada/bldtools/sinfo gnatmake -q xsinfo ./xsinfo ../../sinfo.h ) /bin/sh: line 1: 13373 Segmentation fault (core dumped) ./xsinfo ../../sinfo.h make[3]: *** [ada/sinfo.h] Error 139 d...@hiauly6:~/gnu/gcc-4.4/objdir/gcc/ada/bldtools/sinfo$ gdb -c core xsinfo GNU gdb (GDB) 6.8.50.20080917-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as hppa-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... BFD: Warning: /home/dave/gnu/gcc-4.4/objdir/gcc/ada/bldtools/sinfo/core is truncated: expected core file size = 1658880, found: 1601536. Reading symbols from /home/dave/gnu/gcc-4.4/objdir/prev-gcc/libgcc_s.so.4...done. Loaded symbols for /home/dave/gnu/gcc-4.4/objdir/./prev-gcc/libgcc_s.so.4 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 Core was generated by `./xsinfo ../../sinfo.h'. Program terminated with signal 11, Segmentation fault. #0 0x403f15a8 in _Unwind_Find_FDE (pc=0x403ef63b, bases=0xfb283efc) at ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c:979 979 ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c: No such file or directory. in ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c (gdb) bt #0 0x403f15a8 in _Unwind_Find_FDE (pc=0x403ef63b, bases=0xfb283efc) at ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c:979 #1 0x403ee128 in uw_frame_state_for (context=0xfb283d88, fs=0xfb28454c) at ../../../gcc/libgcc/../gcc/unwind-dw2.c:1129 #2 0x403eeb68 in uw_init_context_1 (context=0xfb283d88, outer_cfa=0xfb283d80, outer_ra=0x1cdc3) at ../../../gcc/libgcc/../gcc/unwind-dw2.c:1435 #3 0x403ef63c in _Unwind_RaiseException (exc=0x76ec0) at ../../../gcc/libgcc/../gcc/unwind.inc:93 #4 0x0001cdc0 in ada.exceptions.exception_propagation.propagate_exception ( e=value optimized out, from_signal_handler=value optimized out) at a-exexpr.adb:588 #5 0x0001ce3c in __gnat_raise_nodefer_with_msg (e=0x403ef63b) at a-except.adb:817 #6 0x0001d4c4 in __gnat_raise_exception (e=0x6d120, message=value optimized out) at a-except.adb:856 #7 0x0001ac3c in xsinfo__getline___1032 () #8 0x0001a2cc in _ada_xsinfo () (gdb) disass 0x403f1598 0x403f15b8 Dump of assembler code from 0x403f1598 to 0x403f15b8: 0x403f1598 _Unwind_Find_FDE+92: addil L%0,r19,r1 0x403f159c _Unwind_Find_FDE+96: ldw cc(r1),r10 0x403f15a0 _Unwind_Find_FDE+100: ldw 0(r10),r6 0x403f15a4 _Unwind_Find_FDE+104: cmpib, 0,r6,0x403f15bc _Unwind_Find_FDE+128 0x403f15a8 _Unwind_Find_FDE+108: ldw 0(r6),ret0 0x403f15ac _Unwind_Find_FDE+112: b,l 0x403f1684 _Unwind_Find_FDE+328,r0 0x403f15b0 _Unwind_Find_FDE+116: addil L%0,r19,r1 0x403f15b4 _Unwind_Find_FDE+120: cmpib,= 0,r6,0x403f1680 _Unwind_Find_FDE+324 End of assembler dump. (gdb) p/x $r6 $1 = 0x0 (gdb) p/x *(int *)$r10 $2 = 0x0 -- Summary: [4.4 Regression] Null pointer dereference in delay slot Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #1 from danglin at gcc dot gnu dot org 2009-02-05 04:22 --- This occurs in stage2 with d...@hiauly6:~/gnu/gcc-4.4/objdir/prev-gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada Thread model: posix gcc version 4.4.0 20090205 (experimental) [trunk revision 143949] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug middle-end/39101] [4.4 Regression] Null pointer dereference in delay slot
--- Comment #2 from danglin at gcc dot gnu dot org 2009-02-05 04:29 --- Bootstrap is also broken on hppa64-hp-hpux11.11: ... /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu64/gcc/gcc-4.4.0/hppa64-hp-hpux11.11/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite- strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definit ion -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variad ic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERAT OR_FILE -o build/gengenrtl \ build/gengenrtl.o build/errors.o .././libiberty/libiberty.a build/genmodes -m tmp-min-modes.c /bin/sh: 12659 Memory fault(coredump) make[3]: *** [s-modes-m] Error 139 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation
--- Comment #9 from dberlin at gcc dot gnu dot org 2009-02-05 07:10 --- Subject: Bug 39100 Author: dberlin Date: Thu Feb 5 07:09:44 2009 New Revision: 143951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143951 Log: 2009-02-05 Daniel Berlin dber...@dberlin.org Richard Guenther rguent...@suse.de PR tree-optimization/39100 * tree-ssa-structalias.c (do_ds_constraint): Actually do what the comment says and add edges. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr39100.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39100
