[Bug tree-optimization/50272] A case that PRE optimization hurts performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Component|c |tree-optimization --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-02 06:29:18 UTC --- I recognize this loop, it is part of coremarks. Anyways confirmed and it happens on MIPS64 too.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #9 from Anders F Björklund afb at users dot sourceforge.net 2011-09-02 06:40:28 UTC --- (In reply to comment #8) hello world tests OK on Snow Leopard, with patch This patch fails on darwin11 when applied to gcc-4_6-branch... Seems like the patch worked (= didn't fail to apply), but that the build failed due to missing dependencies ? f=`echo sort/sort.lo | sed -e 's/.lo$/.o/'`; missing-objcopy -j __GNU_GO.__go_export $f sort.gox.tmp mv -f sort.gox.tmp sort.gox /bin/sh: missing-objcopy: command not found make[4]: *** [sort.gox] Error 127 make[4]: *** Waiting for unfinished jobs It seems to required binutils to be installed (which we really want to avoid). Yes, it requires OBJCOPY=gobjcopy. Maybe this requirement should be replaced with some custom gox-extract tool ? Since the .go_export section name had to be changed, anyway: http://golang.org/doc/gccgo_install.html#Imports
[Bug c++/50244] wcstold not available for C++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244 --- Comment #5 from lcid-fire at gmx dot net 2011-09-02 06:41:29 UTC --- It seems to be a mixup of gcc 4.4.3 and 4.5.3 include paths. Obviously the headers are quite different - I'll have to sort it out.
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-02 07:27:30 UTC --- Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00052.html
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02 08:03:22 UTC --- (In reply to comment #5) This one is much better, and actually should lead to slightly better code than C++98, because we don't do anything if _Nw 1 (the 32-bit case is also better but doesn't optimize the case _Nb % _GLIBCXX_BITSET_BITS_PER_WORD == 0 _Nb % _GLIBCXX_BITSET_BITS_PER_ULL != 0. I don't care much these times) Looks better indeed. I think the compiler should be responsible for optimizing x~0UL, not the library. I'll have to check that bitset32(x).count() has no overhead compared to a call to __builtin_popcount. Looks to me like _DoWork is actually _Nb_GLIBCXX_BITSET_BITS_PER_ULL (more intuitive, and it makes _Nw and _Extrabits useless). I usually write the number ~((~static_castunsigned long long(0)) _Extrabits) as (1ULL _Extrabits)-1 and just noticed that your version would be faster at runtime (here it is compile-time anyway), cool.
[Bug middle-end/50266] [4.6/4.7 Regression] internal compiler error: in decode_addr_const, at varasm.c:2638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||arm-linux-gnueabi
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-09-02
CC||ebotcazou at gcc dot
||gnu.org, jsm28 at gcc dot
||gnu.org
Known to work||4.5.3
Target Milestone|--- |4.6.2
Summary|internal compiler error: in |[4.6/4.7 Regression]
|decode_addr_const, at |internal compiler error: in
|varasm.c:2638 |decode_addr_const, at
||varasm.c:2638
Ever Confirmed|0 |1
Known to fail||4.6.1, 4.7.0
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
08:22:43 UTC ---
Confirmed on x86_64-linux with -Os on 4.6 and trunk.
(gdb) call debug_tree (exp)
addr_expr 0x2ceb3fc0
type pointer_type 0x2ab5d150
type integer_type 0x2ab47540 unsigned int sizes-gimplified public
unsigned SI
size integer_cst 0x2ab35988 constant 32
unit size integer_cst 0x2ab35690 constant 4
align 32 symtab 0 alias set -1 canonical type 0x2ab47540
precision 32 min integer_cst 0x2ab359b0 0 max integer_cst 0x2ab35960
4294967295
pointer_to_this pointer_type 0x2ab5d150
sizes-gimplified public unsigned DI
size integer_cst 0x2ab35a50 constant 64
unit size integer_cst 0x2ab35a78 constant 8
align 64 symtab 0 alias set -1 canonical type 0x2ab5d150
pointer_to_this pointer_type 0x2ce99738
constant
arg 0 component_ref 0x2ceb7040 type integer_type 0x2ab47540
unsigned int
arg 0 indirect_ref 0x2ceb3f90 type record_type 0x2ce993f0 a
arg 0 integer_cst 0x2ce94938 constant 1241530624
t.i:12:9
arg 1 field_decl 0x2ab42720 a type integer_type 0x2ab47540
unsigned int
unsigned SI file t.i line 2 col 18 size integer_cst 0x2ab35988
32 unit size integer_cst 0x2ab35690 4
align 32 offset_align 128
offset integer_cst 0x2ab356b8 constant 0
bit offset integer_cst 0x2ab35dc0 constant 0 context
record_type 0x2ce993f0 a chain field_decl 0x2ab427b8 b
t.i:12:9
t.i:12:7
There is an INDIRECT_REF in the expression, that shouldn't happen. It is
from a CTOR that looks like
(gdb) call debug_generic_expr (ctor)
{1241530624B-a, 1241530624B-b, 0B}
and we have a CTOR and not individual initializations because of Erics
const-pool changes I believe. p-a is folded to 1241530624B-a even
before gimplification (but 1241530624B-a is unfolded - it's an
obfuscated constant).
We ICE from
#0 fancy_abort (
file=0x1252a70 /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c,
line=2638, function=0x1253700 decode_addr_const)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/diagnostic.c:893
#1 0x00ca9016 in decode_addr_const (exp=0x2ceb3fc0,
value=0x7fff9b30)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2638
#2 0x00ca97f0 in const_hash_1 (exp=0x2ceb3fc0)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2734
#3 0x00ca95db in const_hash_1 (exp=0x2cea54e0)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2724
#4 0x00cace7a in tree_output_constant_def (exp=0x2cea54e0)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:3302
#5 0x0083a5f4 in gimplify_init_constructor (expr_p=0x7fffb3a8,
pre_p=0x7fffccf8, post_p=0x7fffa928, want_value=0 '\000',
notify_temp_creation=0 '\000')
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/gimplify.c:3833
and fold p-a via c_fully_fold_internal.
Either the ADDR_EXPR case handling of this function or the COMPONENT_REF
case should be adjusted to fold it down to a constant.
Maybe there is a middle-end function somewhere to legitimize const
constructor elements though that I missed (and that the gimplifcation
misses).
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #10 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 08:45:22 UTC ---
Here's my attempt at a native version.
(of that gox-extract shell script)
Instead of the default variant:
OBJCOPY=${OBJCOPY:-objcopy}
$OBJCOPY -j .go_export $1 $2
The Darwin version could be this:
OTOOL=${OTOOL:-otool}
$OTOOL -s __GNU_GO __go_export $1 |
grep -v ^$1: | grep -v Contents of (__GNU_GO,__go_export) section |
cut -f 2- | tr -d ' ' | xxd -r -p - $2
It doesn't include the objcopy header,
but I believe that is skipped anyway ?
[Bug bootstrap/50265] [4.7 Regression] Bootstrap failure BufferedImage.java:336:0: internal compiler error: Segmentation fault on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-02 08:59:14 UTC --- This is caused by revision 178386: bootstrap succeeds on x86_64-apple-darwin10 and powerpc-apple-darwin9 if I revert it. r178386 | jamborm | 2011-08-31 10:17:19 -0700 (Wed, 31 Aug 2011) | 11 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/ipa-inline-analysis.c M /trunk/gcc/ipa-split.c M /trunk/gcc/testsuite/ChangeLog A /trunk/gcc/testsuite/gcc.c-torture/execute/pr49886.c 2011-08-31 Martin Jambor mjam...@suse.cz PR middle-end/49886 * ipa-inline-analysis.c (compute_inline_parameters): Set can_change_signature of noes with typde attributes. * ipa-split.c (split_function): Do not skip any arguments if can_change_signature is set. * testsuite/gcc.c-torture/execute/pr49886.c: New testcase. It may be a duplicate of pr50260.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #9 from vries at gcc dot gnu.org 2011-09-02 09:03:54 UTC ---
The following testcase reproduces the same failure without alloca, vla, or the
178353 patch.
stack-stave-restore.c:
...
extern void bar (int*);
char *p;
int
main ()
{
int q;
p = __builtin_stack_save ();
bar (q);
__builtin_stack_restore (p);
bar (q);
return 0;
}
...
Using q makes sure we use virtual-stack-vars, which expands into something
using FRAME_POINTER_REG.
Main has an incoming stack boundary of 32, and a preferred one of 128, so a
realign is needed. Nothing sets crtl-need_drap, so we have stack_realign_fp
rather than stack_realign_drap.
This forbids elimination from FRAME_POINTER_REG to HARD_FRAME_POINTER_REG.
The __builtin_stack_restore stays until ira (if we wouldn't by declaring p
global), and this forbids elimination from FRAME_POINTER_REG to
STACK_POINTER_REGNUM.
FRAME_POINTER_REG cannot be eliminated, and we assert.
This patch sets need_drap when a stack_restore is present at expand, which
allows both the 20010209-1.c and the stack-stave-restore.c testcase to succeed:
...
Index: src/gcc-mainline/gcc/explow.c
===
--- src/gcc-mainline/gcc/explow.c (revision 178379)
+++ src/gcc-mainline/gcc/explow.c (working copy)
@@ -1062,6 +1062,9 @@ emit_stack_restore (enum save_level save
/* The default is that we use a move insn. */
rtx (*fcn) (rtx, rtx) = gen_move_insn;
+ if (SUPPORTS_STACK_ALIGNMENT)
+crtl-need_drap = true;
+
/* See if this machine has anything special to do for this kind of save. */
switch (save_level)
{
...
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #11 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 09:06:25 UTC ---
OTOOL=${OTOOL:-otool}
$OTOOL -s __GNU_GO __go_export $1 |
grep -v ^$1: | grep -v Contents of (__GNU_GO,__go_export) section |
cut -f 2- | tr -d ' ' | xxd -r -p - $2
Apparently -X avoids that header text:
$OTOOL -s __GNU_GO __go_export -X $1 | cut -f 2- | tr -d ' ' | xxd -r -p - $2
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #10 from vries at gcc dot gnu.org 2011-09-02 09:24:33 UTC --- The __builtin_stack_restore stays until ira (if we wouldn't by declaring p global), The __builtin_stack_restore stays until ira (if we wouldn't declare p global, it would be eliminated),
[Bug tree-optimization/50272] A case that PRE optimization hurts performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 09:28:09 UTC --- Bah, stupid benchmarks ;)
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||almeidaraf at gmail dot com --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 09:30:32 UTC --- *** Bug 50270 has been marked as a duplicate of this bug. ***
[Bug c++/50270] Some symbols are exported even when -fvisibility=hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 09:30:32 UTC --- Dup. *** This bug has been marked as a duplicate of bug 48818 ***
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 09:32:07 UTC --- *** Bug 50265 has been marked as a duplicate of this bug. ***
[Bug bootstrap/50265] [4.7 Regression] Bootstrap failure BufferedImage.java:336:0: internal compiler error: Segmentation fault on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.7.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 09:32:07 UTC --- I'm sure it is. *** This bug has been marked as a duplicate of bug 50260 ***
[Bug c/50264] -Wdisabled-optimizations without -O generates strange errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50264 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 09:35:09 UTC --- 4.3.x is no longer maintained, fixed in 4.4.0.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #11 from vries at gcc dot gnu.org 2011-09-02 09:37:42 UTC --- The problems for testcases 20010209-1.c and stack-stave-restore.c can be reproduced on x86_64 using -mpreferred-stack-boundary=12.
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 09:37:55 UTC --- Hi, (In reply to comment #6) Looks better indeed. I think the compiler should be responsible for optimizing x~0UL, not the library. I'll have to check that bitset32(x).count() has no overhead compared to a call to __builtin_popcount. Indeed, I had the same thought about the compiler. And really, we are doing anyway better than C++98 for 32-bit too, I'm not particularly worried. But, if we have time we should check and open an optimization PR in case. Looks to me like _DoWork is actually _Nb_GLIBCXX_BITSET_BITS_PER_ULL (more intuitive, and it makes _Nw and _Extrabits useless). I usually write the number ~((~static_castunsigned long long(0)) _Extrabits) as (1ULL _Extrabits)-1 and just noticed that your version would be faster at runtime (here it is compile-time anyway), cool. Ah great. I'm so stupid, trying to do all the work in terms of _Nw and so on, where in this case we have _Nb itself available. About the formula, interesting indeed what you are noticing, I guess I will stick to the more obfuscated one for compile-time too, because like this it's clear we are doing the same adjustment done normally in _M_do_sanitize at run-time. I'm attaching the updated patch I'm going to test and commit (4_6-branch too).
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Attachment #25174|0 |1 is obsolete|| --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 09:40:42 UTC --- Created attachment 25175 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25175 Updated (simplified) again per Marc
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
09:40:33 UTC ---
(In reply to comment #3)
Created attachment 25162 [details]
optimized dump
1. The alloca in main is transformed into this declaration:
unnamed-unsigned:8 D.2129[24];
and accessed like this:
iftmp.6_13 = MEM[symbol: D.2129, index: ivtmp.30_31, step: 4,
offset: 4294967292B];
MEM[symbol: D.2129, index: ivtmp.30_31, step: 4, offset: 0B] = D.2105_15;
D.2099_18 = MEM[(int *)D.2129][5]{lb: 0 sz: 4};
MEM[symbol: D.2129, index: ivtmp.30_31, step: 4, offset: 0B] = 0;
2. __builtin_stack_restore/__builtin_stack_restore in main are not optimized
away, because the restored value is potentially used. The restored value is
the
same as the current value, so the restore is redundant, but that's not checked
in optimize_stack_restore.
saved_stack.3_5 = __builtin_stack_save ();
__builtin_stack_restore (saved_stack.3_5);
It does try it here:
second_stack_restore:
/* If there's exactly one use, then zap the call to __builtin_stack_save.
If there are multiple uses, then the last one should remove the call.
In any case, whether the call to __builtin_stack_save can be removed
or not is irrelevant to removing the call to __builtin_stack_restore. */
if (has_single_use (gimple_call_arg (call, 0)))
but for some reason it doesn't trigger?
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
09:42:13 UTC ---
(In reply to comment #6)
fold_builtin_alloca_for_var should record stack alignment
change due to
+ /* Declare array. */
+ elem_type = build_nonstandard_integer_type (BITS_PER_UNIT, 1);
+ n_elem = size * 8 / BITS_PER_UNIT;
+ align = MIN (size * 8, BIGGEST_ALIGNMENT);
+ array_type = build_array_type_nelts (elem_type, n_elem);
+ var = create_tmp_var (array_type, NULL);
+ DECL_ALIGN (var) = align;
+
If the stack alignment code cannot handle decls with any DECL_ALIGN
it is broken. We for sure do not need to do anything here nor
in the vectorizer, which does
if (vect_can_force_dr_alignment_p (decl, alignment))
{
DECL_ALIGN (decl) = TYPE_ALIGN (vectype);
DECL_USER_ALIGN (decl) = 1;
[Bug fortran/50273] New: [4.5/4.6/4.7 Regression] -Walign-commons no longer effective
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273 Bug #: 50273 Summary: [4.5/4.6/4.7 Regression] -Walign-commons no longer effective Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Motivated by the thread: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1f5e2018f744e5c6 With gfortran 4.4, one got the warning: common /global_var/ a, b, c 1 Warning: COMMON 'global_var' at (1) requires 3 bytes of padding at start; reorder elements or use -fno-align-commons However, with gfortran 4.5/4.6/4.7, it compiles without warning - not even with -Walign-commons Note: In 4.5 there was a change in how padding works. Before, the padding was added before the too short variable, now it is added after the variable. The advantage is a better compatibility with C struct and for common blocks of different length in different scopes (which is valid for blank commons). Cf. http://gcc.gnu.org/gcc-4.5/changes.html#Fortran I assume that this change broke the test. Example (cf. link for a longer, C+Fortran example): subroutine test() character :: a integer :: b character :: c common /global_var/ a, b, c print *, a, b, c end subroutine test
[Bug fortran/50273] [4.5/4.6/4.7 Regression] -Walign-commons no longer effective
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-02 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 10:11:32 UTC --- ./f951 -quiet t.f90 -Wpadded f951: warning: padding struct size to alignment boundary [-Wpadded] f951: warning: padding struct to align 'pending' [-Wpadded] f951: warning: padding struct size to alignment boundary [-Wpadded] t.f90: In function 'test': t.f90:1:0: warning: padding struct size to alignment boundary [-Wpadded] Note that suggesting -fno-align-commons shouldn't be done - using it can severely reduce performance. Not sure where the first three warnings come from - probably from frontend generated entities which are not detected as builtin if (DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION) warning (OPT_Wpadded, padding struct to align %q+D, field); if (TREE_CONSTANT (unpadded_size) simple_cst_equal (unpadded_size, TYPE_SIZE (rli-t)) == 0 input_location != BUILTINS_LOCATION) warning (OPT_Wpadded, padding struct size to alignment boundary);
[Bug fortran/50273] [4.5/4.6/4.7 Regression] -Walign-commons no longer effective
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.4
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-02 10:28:40 UTC --- Author: paolo Date: Fri Sep 2 10:28:36 2011 New Revision: 178463 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178463 Log: 2011-09-02 Paolo Carlini paolo.carl...@oracle.com Marc Glisse marc.gli...@normalesup.org PR libstdc++/50268 * include/std/bitset (struct _Sanitize_val): Add. (bitset::bitset(unsigned long long)): Fix. * testsuite/23_containers/bitset/cons/50268.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/bitset/cons/50268.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/bitset
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #14 from vries at gcc dot gnu.org 2011-09-02 10:28:52 UTC ---
but for some reason it doesn't trigger?
The bb containing the __builtin_stack_restore has 2 successors:
...
bb 6:
D.2099_18 = MEM[(int *)D.2129][5]{lb: 0 sz: 4};
__builtin_stack_restore (saved_stack.3_5);
if (D.2099_18 != 15)
goto bb 7;
else
goto bb 8;
...
This case doesn't fall into the cases described in the header comment.
...
/* Try to optimize out __builtin_stack_restore. Optimize it out
if there is another __builtin_stack_restore in the same basic
block and no calls or ASM_EXPRs are in between, or if this block's
only outgoing edge is to EXIT_BLOCK and there are no calls or
ASM_EXPRs after this __builtin_stack_restore. */
...
It hits this piece of code in optimize_stack_restore and returns, so it doesn't
reach second_stack_restore:
...
/* Allow one successor of the exit block, or zero successors. */
switch (EDGE_COUNT (bb-succs))
{
case 0:
break;
case 1:
if (single_succ_edge (bb)-dest != EXIT_BLOCK_PTR)
return NULL_TREE;
break;
default:
return NULL_TREE;
}
second_stack_restore:
...
For the stack-save-restore.c, if I declare p inside the function, cse creates a
(set (sp) (sp)), which is eliminated.
But for the 20010209-1.c example, that doesn't happen.
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 10:41:52 UTC --- (by the way, if you can see a neat enough way to improve _M_are_all_aux, you are welcome to propose it! I'm definitely not an expert in this area, and when I implemented it, I remember just quickly hacking something close to what we have elsewhere, which I could easily convince myself was correct)
[Bug c++/50274] New: Conditionnal rethrow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274 Bug #: 50274 Summary: Conditionnal rethrow Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: romain.geiss...@gmail.com This bug could be reproduced on x86_64 with G++ 4.5.x, 4.6.x and the current trunk. Target: x86_64-unknown-linux-gnu Configured with: /prj/compwork2/geissler/trunk/configure --prefix=/prj/compwork2/geissler/install --enable-shared --enable-languages=c,c++ --disable-libgcj --enable-checking --enable-plugin --with-gmp=/sw/st/gnu_compil/gnu/linux-rh-ws-4-x86_64/ --with-mpfr=/sw/st/gnu_compil/gnu/linux-rh-ws-4-x86_64/ --with-mpc=/sw/st/gnu_compil/gnu/linux-rh-ws-4-x86_64/ --with-ppl=/sw/st/gnu_compil/gnu/linux-rh-ws-4-x86_64/ --with-cloog=/sw/st/gnu_compil/gnu/linux-rh-ws-4-x86_64/ Thread model: posix gcc version 4.7.0 20110829 (experimental) (GCC) Compilation line: g++ rethrow.cpp -o rethrow The rethrow made in foo handler is not caught by the main handler as it should. Here is the execution trace: throw caught foo terminate called after throwing an instance of 'int' Aborted It works with GCC 4.4.x : throw caught foo caught main If the test if (!i) is removed, it works. If foo prototype is changed to return void it also works.
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #11 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02 10:59:46 UTC --- (In reply to comment #10) (by the way, if you can see a neat enough way to improve _M_are_all_aux, you are welcome to propose it! I'm definitely not an expert in this area, and when I implemented it, I remember just quickly hacking something close to what we have elsewhere, which I could easily convince myself was correct) all(), when it reaches the last chunk, checks (nbchunk-1)*chunksize+popcount(lastchunk)==size(). It seems to me that it should check instead lastchunk==mask (where mask is something like ~(~0ULextrabits), computed at compile-time). Because of the way things are implemented, it means the helper needs to take mask (or extrabits) as argument.
[Bug c++/50274] Conditionnal rethrow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274 --- Comment #1 from Romain Geissler romain.geissler at gmail dot com 2011-09-02 11:00:50 UTC --- Created attachment 25176 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25176 Rethrow made in foo is not caught in main handler.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
11:02:22 UTC ---
(In reply to comment #14)
but for some reason it doesn't trigger?
The bb containing the __builtin_stack_restore has 2 successors:
...
bb 6:
D.2099_18 = MEM[(int *)D.2129][5]{lb: 0 sz: 4};
__builtin_stack_restore (saved_stack.3_5);
if (D.2099_18 != 15)
goto bb 7;
else
goto bb 8;
...
This case doesn't fall into the cases described in the header comment.
...
/* Try to optimize out __builtin_stack_restore. Optimize it out
if there is another __builtin_stack_restore in the same basic
block and no calls or ASM_EXPRs are in between, or if this block's
only outgoing edge is to EXIT_BLOCK and there are no calls or
ASM_EXPRs after this __builtin_stack_restore. */
...
It hits this piece of code in optimize_stack_restore and returns, so it
doesn't
reach second_stack_restore:
...
/* Allow one successor of the exit block, or zero successors. */
switch (EDGE_COUNT (bb-succs))
{
case 0:
break;
case 1:
if (single_succ_edge (bb)-dest != EXIT_BLOCK_PTR)
return NULL_TREE;
break;
default:
return NULL_TREE;
}
second_stack_restore:
...
For the stack-save-restore.c, if I declare p inside the function, cse creates
a
(set (sp) (sp)), which is eliminated.
But for the 20010209-1.c example, that doesn't happen.
Ok, the code really tries to optimize the case of __builtin_stack_restore
being called right before exiting the function only.
That's because it doesn't look for alloca() calls inbetween the
stack-save/restore pair at all (just for ones following a restore).
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #12 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 11:07:33 UTC ---
It doesn't include the objcopy header,
but I believe that is skipped anyway ?
Or at least it was *supposed* to ignore it,
but the Stream_from_file was horribly buggy.
(apparently has a dyslectic problem with
comparisons, aggrevated by copy/paste ?)
It always returned instead of any data,
so failed to provide the required magic...
(or any other data beyond that, if asked)
Fixing that class, and it works just fine:
Index: gcc/go/gofrontend/import.cc
===
--- gcc/go/gofrontend/import.cc(revision 178444)
+++ gcc/go/gofrontend/import.cc(working copy)
@@ -836,7 +836,7 @@
bool
Stream_from_file::do_peek(size_t length, const char** bytes)
{
- if (this-data_.length() = length)
+ if (this-data_.length() = length)
{
*bytes = this-data_.data();
return true;
@@ -854,7 +854,7 @@
return false;
}
- if (lseek(this-fd_, - got, SEEK_CUR) != 0)
+ if (lseek(this-fd_, - got, SEEK_CUR) 0)
{
if (!this-saw_error())
error(lseek failed: %m);
@@ -876,7 +876,7 @@
void
Stream_from_file::do_advance(size_t skip)
{
- if (lseek(this-fd_, skip, SEEK_CUR) != 0)
+ if (lseek(this-fd_, skip, SEEK_CUR) 0)
{
if (!this-saw_error())
error(lseek failed: %m);
That bug should affect any other platform too,
if trying to use naked .gox (without object) ?
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #13 from Anders F Björklund afb at users dot sourceforge.net 2011-09-02 11:10:51 UTC --- Created attachment 25177 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25177 import-export.diff Just the import/export changes, i.e. outside libgo directory.
[Bug c++/50274] Conditionnal rethrow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-02 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 11:18:33 UTC --- It works for me with 4.5 and 4.6 and 4.7 on x86_64-linux. linux-rh-ws-4-x86_64 are you maybe using a very old glibc (and thus unwinder)? Is the libgcc_s.so.1 used at runtime that from the compiler versions you tested?
[Bug target/50275] New: [4.6 regression] libgcc build failure on LM32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50275 Bug #: 50275 Summary: [4.6 regression] libgcc build failure on LM32 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: phil...@philpem.me.uk When building GCC 4.6.0 or 4.6.1 on x86_64 for lm32-elf, libgcc fails to build. Last few lines of the build log: checking whether we are using the GNU C compiler... yes checking whether /home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/./gcc/xgcc -B/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/./gcc/ -nostdinc -B/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/lm32-elf/newlib/ -isystem /home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/lm32-elf/newlib/targ-include -isystem /home/philpem/gcc/build-20110902-105609/gcc-4.6.0/newlib/libc/include -B/opt/toolchains/lm32-elf/lm32-elf/bin/ -B/opt/toolchains/lm32-elf/lm32-elf/lib/ -isystem /opt/toolchains/lm32-elf/lm32-elf/include -isystem /opt/toolchains/lm32-elf/lm32-elf/sys-includeaccepts -g... yes checking for /home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/./gcc/xgcc -B/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/./gcc/ -nostdinc -B/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/lm32-elf/newlib/ -isystem /home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/lm32-elf/newlib/targ-include -isystem /home/philpem/gcc/build-20110902-105609/gcc-4.6.0/newlib/libc/include -B/opt/toolchains/lm32-elf/lm32-elf/bin/ -B/opt/toolchains/lm32-elf/lm32-elf/lib/ -isystem /opt/toolchains/lm32-elf/lm32-elf/include -isystem /opt/toolchains/lm32-elf/lm32-elf/sys-includeoption to accept ISO C89... At this point, 'cc1' starts consuming massive amounts of RAM and seems to get stuck in an infinite loop. The only way out is to force a SIGINT (ctrl-c) and kill it off, kill -9, or reboot. This appears to be similar to bug 46898 on 4.6.0. Build commands used: ../configure --prefix=/opt/toolchains/lm32-elf --target=lm32-elf --enable-languages=c,c++ --with-newlib --enable-sjlj-exceptions make make install Test results: 4.5.3 -- OK 4.6.0 -- bug present 4.6.1 -- bug present
[Bug bootstrap/50265] [4.7 Regression] Bootstrap failure BufferedImage.java:336:0: internal compiler error: Segmentation fault on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-02 11:28:03 UTC --- I'm sure it is. At least on x86_64-apple-darwin10 it is fixed by the patch for pr50260 at http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00052.html .
[Bug c++/50274] Conditionnal rethrow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274 Romain Geissler romain.geissler at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Romain Geissler romain.geissler at gmail dot com 2011-09-02 11:43:51 UTC --- Yeah you're right, i used an old libgcc_s.so.1 at runtime. It works when using the correct library.
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 12:08:04 UTC --- Created attachment 25178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25178 Work in progress patch for the _M_are_all_aux issue I'm considering doing something like this: what do you think? Can we tidy somehow the general case (_Nw 1)? (patch already passes the existing bitset::all test)
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #13 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02 12:23:33 UTC --- (In reply to comment #12) Created attachment 25178 [details] Work in progress patch for the _M_are_all_aux issue I'm considering doing something like this: what do you think? Can we tidy somehow the general case (_Nw 1)? (patch already passes the existing bitset::all test) Doesn't _Base_bitset1 also need a special case for _Nb==_GLIBCXX_BITSET_BITS_PER_WORD ? I think we could express the constant as ~static_cast_WordT(0)(_GLIBCXX_BITSET_BITS_PER_WORD-_Nb) so we don't need a special case (and something similar for the last word of the generic _Base_bitset)
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 12:33:40 UTC --- (In reply to comment #13) Doesn't _Base_bitset1 also need a special case for _Nb==_GLIBCXX_BITSET_BITS_PER_WORD ? You are right, got confused by the signedness. I think we could express the constant as ~static_cast_WordT(0)(_GLIBCXX_BITSET_BITS_PER_WORD-_Nb) so we don't need a special case (and something similar for the last word of the generic _Base_bitset) Let's see what I can do, thanks.
[Bug c++/50276] New: Wrong used uninitialized in this function warning [C++0x]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
Bug #: 50276
Summary: Wrong used uninitialized in this function warning
[C++0x]
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
For this example code, GCC mistakenly produces the following warning:
tmp.cc:10:5: warning: 'value' is used uninitialized in this function
[-Wuninitialized]
The warning is wrongly given, because there is no execution path that does not
assign a well-defined value to the variable. In fact, there are no branches at
all between the declaring and the assigning of the variable.
templatetypename T
unsigned testfun(const T func)
{
return func();
}
templateint i
unsigned test()
{
if(unsigned value = testfun( [] () { return 0; }))
{
return value;
}
return i;
}
int main()
{
return test1();
}
The warning being wrongly given depends on the following conditions:
- test() being a template function: changing i into an actual parameter
removes the warning
- func being a functor: changing it into an integer parameter removes the
warning
- the variable value being declared and assigned to in the if-condition:
declaring and assigning it separately removes the warning.
- the func parameter being a lambda function: changing it into a static
method of a class removes the warning.
The following aspects do not affect the warning:
- testfun() being a template function: changing T into an explicit int(*)()
retains the warning
- whether i is used within test() or not
- adding static or inline attributes to any function did not change the
warning.
Tested on GCC 4.5.3 and GCC 4.6.1, on x86_64-linux-gnu in both 32-bit and
64-bit mode on all optimization modes.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-09-02 12:46:10 UTC --- 4.6 version of the patch posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00140.html
[Bug fortran/50273] [4.5/4.6/4.7 Regression] -Walign-commons no longer effective
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-02
12:57:03 UTC ---
(In reply to comment #1)
./f951 -quiet t.f90 -Wpadded
Note that suggesting -fno-align-commons shouldn't be done - using it
can severely reduce performance.
But to be 100% Fortran standard conforming, one has to use -fno-align-commons,
if I recall correctly. I think the standard demands that the memory is
contiguously, though at the moment, I fail to come up with a
standard-conforming code which would run into issues with -falign-commons (i.e.
the default) - at least after the 4.5 change.
(Side note: The Intel compiler has a similar option (-(no)align): By default,
no padding is added to common blocks but padding is added to structures..)
* * *
Regarding -Wpadded: I have not thoroughly investigated. What puzzles me is the
string pending as I could not find the string anywhere.
* * *
Regarding the missing front-end warning: The following seems to work (only
lightly tested):
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -1069,3 +1069,2 @@ translate_common (gfc_common_head *common, gfc_symbol
*var_list)
unsigned HOST_WIDE_INT align;
- unsigned HOST_WIDE_INT max_align;
bool saw_equiv;
@@ -1076,3 +1075,2 @@ translate_common (gfc_common_head *common, gfc_symbol
*var_list)
align = 1;
- max_align = 1;
saw_equiv = false;
@@ -1119,3 +1117,3 @@ translate_common (gfc_common_head *common, gfc_symbol
*var_list)
- if (offset (max_align - 1))
+ if (offset)
{
@@ -1142,4 +1140,2 @@ translate_common (gfc_common_head *common, gfc_symbol
*var_list)
current_offset += offset;
- if (max_align align)
- max_align = align;
[Bug c++/50276] Wrong used uninitialized in this function warning [C++0x]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi 2011-09-02 13:04:31
UTC ---
Even this produces the warning. Changing any of the 0s into 1 did not
affect the warning.
static inline unsigned testfun(void*)
{
return 0;
}
templateint i
static inline unsigned test()
{
if(unsigned value = testfun( []() { return 0; } ))
return value;
return 0;
}
int main()
{
return test0();
}
[Bug c++/50255] Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 --- Comment #6 from Stephan Bergmann stephan.bergmann.secondary at googlemail dot com 2011-09-02 13:15:42 UTC --- While I still don't have a stripped down test case, I at least know now what is going wrong (on recent gcc-4_6-branch rev 178396, at least): When compiling vbasheetobjects.cxx, the text section for the non-virtual thunk (with section name .text._ZN19... and group name _ZThn20_N19...) is first obtained at get_section() hot_function_section() function_section_1() function_section_1() assemble_start_function() assemble_thunk() cgraph_expand_function() cgraph_expand_all_functions() cgraph_optimize() cgraph_finalize_compilation_unit() cp_write_global_declarations() compile_file() do_compile() toplev_main() main() There, get_section() is called with decl pointing to the thunk, as assemble_thunk() sets global current_function_decl = thunk_fndecl; Later on, the corresponding rodata section for the non-virtual thunk (with section name .rodata._ZN19... and erroneous group name _ZN19... instead of _ZThn20_N19...) is first obtained at get_section() default_function_rodata_section() final_scan_insn() final() rest_of_handle_final() execute_one_pass() execute_pass_list() execute_pass_list() execute_pass_list() tree_rest_of_compilation() cgraph_expand_function() ... a few lines further down in the same invocation of cgraph_expand_function() (and in final_scan_insn() we are at switch_to_section(targetm.asm_out.function_rodata_section(current_function_decl));). But this time, current_function_decl points to the function itself, not the non-virtual thunk, as tree_rest_of_compilation() sets current_function_decl = fndecl;
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Attachment #25178|0 |1 is obsolete|| --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 13:15:38 UTC --- Created attachment 25179 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25179 Updated per Marc draft for the _M_are_all_aux issue I'm finishing testing this.
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #16 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02 13:26:14 UTC --- (In reply to comment #15) I'm finishing testing this. Looks good, thanks.
[Bug target/49987] [4.7 Regression] gcc.c-torture/compile/pr34856.c fails on powerpc-darwin9 from r176228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 --- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-09-02 13:32:14 UTC --- Author: rsandifo Date: Fri Sep 2 13:32:10 2011 New Revision: 178474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178474 Log: gcc/ PR target/49987 * config/rs6000/rs6000.c (paired_expand_vector_init): Check for valid CONST_VECTOR operands. (rs6000_expand_vector_init): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug middle-end/50266] [4.6/4.7 Regression] internal compiler error: in decode_addr_const, at varasm.c:2638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-09-02 13:36:20 UTC --- I don't think there's any particular reason this initializer should need to be folded in a particular way by the front end; I'd think the front end's job is to produce a valid GENERIC initializer, whether or not folded, with folding to something visibly constant only required if the object initialized is of static storage duration. If you make x static then it builds OK (although it's not required to) but in C99 an aggregate initializer of automatic storage duration can have non-constant elements even if the type of the aggregate is a const-qualified type (that is, x is initialized once and constant after that). In fact you get the same ICE when x isn't marked const at all. (And in general the middle-end ought to be prepared to see aggregate initializers that become constant after constant propagation but aren't known by the front end to be constant.)
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #17 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-02 13:39:26 UTC --- Author: paolo Date: Fri Sep 2 13:39:22 2011 New Revision: 178475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178475 Log: 2011-09-02 Paolo Carlini paolo.carl...@oracle.com Marc Glisse marc.gli...@normalesup.org PR libstdc++/50268 * include/std/bitset (struct _Sanitize_val): Add. (bitset::bitset(unsigned long long)): Fix. * testsuite/23_containers/bitset/cons/50268.cc: New. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/bitset/cons/50268.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/std/bitset
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 13:40:40 UTC --- Fixed for 4.6.2 and mainline (_M_are_all_aux issue dealt with in mainline).
[Bug middle-end/29269] missing documentation for vcond (vector conditional operation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 13:53:54 UTC --- Fixed.
[Bug middle-end/29269] missing documentation for vcond (vector conditional operation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
13:53:37 UTC ---
Author: rguenth
Date: Fri Sep 2 13:53:32 2011
New Revision: 178480
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178480
Log:
2011-09-02 Richard Guenther rguent...@suse.de
PR tree-optimization/27460
PR middle-end/29269
* doc/md.texi (vcond): Document.
* genopinit.c (optabs): Turn vcond{,u}_optab into a conversion
optab with two modes.
* optabs.h (enum convert_optab_index): Add COI_vcond, COI_vcondu.
(enum direct_optab_index): Remove DOI_vcond, DOI_vcondu.
(vcond_optab): Adjust.
(vcondu_optab): Likewise.
(expand_vec_cond_expr_p): Adjust prototype.
* optabs.c (get_vcond_icode): Adjust.
(expand_vec_cond_expr_p): Likewise.
(expand_vec_cond_expr): Likewise.
* tree-vect-stmts.c (vect_is_simple_cond): Return the comparison
vector type.
(vectorizable_condition): Allow differing types for comparison
and result.
* config/i386/i386.c (ix86_expand_sse_cmp): Use proper mode
for the comparison.
* config/i386/sse.md (vcondmode): Split to
vcondV_256:modeVF_256:mode, vcondV_128:modeVF_128:mode,
vcondV_128:modeVI124_128:mode and
vconduV_128:modeVI124_128:mode.
(vcondv2di): Change to vcondVI8F_128:modev2di.
(vconduv2di): Likewise.
* config/arm/neon.md (vcondmode): Change to vcond*modemode.
(vcondumode): Likewise.
* config/ia64/vect.md (vcondmode): Likewise.
(vcondumode): Likewise.
(vcondv2sf): Likewise.
* config/mips/mips-ps-3d.md (vcondv2sf): Likewise.
* config/rs6000/paired.md (vcondv2sf): Likewise.
* config/rs6000/vector.md (vcondmode): Likewise.
(vcondumode): Likewise.
* config/spu/spu.md (vcondmode): Likewise.
(vcondumode): Likewise.
* gcc.dg/vect/vect-cond-7.c: New testcase.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/config/ia64/vect.md
trunk/gcc/config/mips/mips-ps-3d.md
trunk/gcc/config/rs6000/paired.md
trunk/gcc/config/rs6000/vector.md
trunk/gcc/config/spu/spu.md
trunk/gcc/doc/md.texi
trunk/gcc/genopinit.c
trunk/gcc/optabs.c
trunk/gcc/optabs.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/27460] Does not vectorize statements with mixed type COND_EXPRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
13:53:37 UTC ---
Author: rguenth
Date: Fri Sep 2 13:53:32 2011
New Revision: 178480
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178480
Log:
2011-09-02 Richard Guenther rguent...@suse.de
PR tree-optimization/27460
PR middle-end/29269
* doc/md.texi (vcond): Document.
* genopinit.c (optabs): Turn vcond{,u}_optab into a conversion
optab with two modes.
* optabs.h (enum convert_optab_index): Add COI_vcond, COI_vcondu.
(enum direct_optab_index): Remove DOI_vcond, DOI_vcondu.
(vcond_optab): Adjust.
(vcondu_optab): Likewise.
(expand_vec_cond_expr_p): Adjust prototype.
* optabs.c (get_vcond_icode): Adjust.
(expand_vec_cond_expr_p): Likewise.
(expand_vec_cond_expr): Likewise.
* tree-vect-stmts.c (vect_is_simple_cond): Return the comparison
vector type.
(vectorizable_condition): Allow differing types for comparison
and result.
* config/i386/i386.c (ix86_expand_sse_cmp): Use proper mode
for the comparison.
* config/i386/sse.md (vcondmode): Split to
vcondV_256:modeVF_256:mode, vcondV_128:modeVF_128:mode,
vcondV_128:modeVI124_128:mode and
vconduV_128:modeVI124_128:mode.
(vcondv2di): Change to vcondVI8F_128:modev2di.
(vconduv2di): Likewise.
* config/arm/neon.md (vcondmode): Change to vcond*modemode.
(vcondumode): Likewise.
* config/ia64/vect.md (vcondmode): Likewise.
(vcondumode): Likewise.
(vcondv2sf): Likewise.
* config/mips/mips-ps-3d.md (vcondv2sf): Likewise.
* config/rs6000/paired.md (vcondv2sf): Likewise.
* config/rs6000/vector.md (vcondmode): Likewise.
(vcondumode): Likewise.
* config/spu/spu.md (vcondmode): Likewise.
(vcondumode): Likewise.
* gcc.dg/vect/vect-cond-7.c: New testcase.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/config/ia64/vect.md
trunk/gcc/config/mips/mips-ps-3d.md
trunk/gcc/config/rs6000/paired.md
trunk/gcc/config/rs6000/vector.md
trunk/gcc/config/spu/spu.md
trunk/gcc/doc/md.texi
trunk/gcc/genopinit.c
trunk/gcc/optabs.c
trunk/gcc/optabs.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/27460] Does not vectorize statements with mixed type COND_EXPRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02 13:54:18 UTC --- Fixed for 4.7.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-09-02 14:30:49 UTC --- Author: jamborm Date: Fri Sep 2 14:30:34 2011 New Revision: 178482 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178482 Log: 2011-09-02 Martin Jambor mjam...@suse.cz PR middle-end/49886 * ipa-split.c (split_function): Do not skip any arguments if can_change_signature is set or there are function type attributes. * testsuite/gcc.c-torture/execute/pr49886.c: New testcase. * testsuite/gfortran.fortran-torture/compile/pr50260.f90: Likewise. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49886.c branches/gcc-4_6-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr50260.f90 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/ipa-split.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49972] Invalid .gcc_except_table with -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-02 14:40:44 UTC --- Apparently this pr has been fixed between revisions 178293 and 178298 (178298? see http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg03415.html and http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg03416.html ).
[Bug rtl-optimization/49972] Invalid .gcc_except_table with -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972 --- Comment #8 from Bernd Schmidt bernds at gcc dot gnu.org 2011-09-02 14:49:51 UTC --- I'm guessing it was this: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02175.html
[Bug rtl-optimization/49972] Invalid .gcc_except_table with -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-02 15:10:28 UTC --- I'm guessing it was this: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02175.html i.e., revision 178298. Closing as fixed.
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-02 15:48:44 UTC --- Ok, I've now managed to reproduce the unspecs in a fresh cross build. Perhaps adjust_mems could try harder and call targetm.delegitimize_address on all the expressions if it is !amd-store, or perhaps just set some flag when it sees an UNSPEC and requests that outer expressions from within the same call are then targetm.delegitimize_address processed until a single adjust_mem_uses finishes. But that doesn't explain what the problem is, because the unspecs I've looked at are successfully delegitimized into SYMBOL_REF etc. during mem_loc_descriptor. So, what exactly is the problematic assembly part in the .debug_info? I admit I haven't went through all the unspecs, just some of them.
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #10 from Peter Bergner bergner at gcc dot gnu.org 2011-09-02 15:59:32 UTC --- Adding Alan and a comment Alan made on some internal emails that hopefully will shead some light on the subject: After quite a lot of messing around, I managed to reproduce the linker abort. Turns out to be a .debug_loc reference into .toc!! This .byte 0x3 .8byte .LC7 .byte 0x6 .byte 0x94 .byte 0x4 .byte 0xf7 .uleb128 0x39 .byte 0xf7 .uleb128 0x32 .byte 0x84 .sleb128 32 .byte 0xf6 .byte 0x8 .uleb128 0x32 .byte 0x22 .byte 0xf7 .uleb128 0x39 .byte 0xf7 .uleb128 0 .byte 0x9f which is 0ec4 01f0 0250 (DW_OP_addr: 20; DW_OP_deref; DW_OP_deref_size: 4; DW_OP_GNU_convert 0x39; DW_OP_GN U_convert 0x32; DW_OP_breg20 (r20): 32; DW_OP_GNU_deref_type: 8 0x32; DW_OP_plus; DW_OP_GNU_convert 0x39; DW_OP_GNU_convert 0 x0; DW_OP_stack_value) The reference to .LC7 is the killer .LC7: .tc ecp2_.P36000[TC],ecp2_+36000 Now the code using .LC7 looks like addis 10,2,.LC7@toc@ha .loc 1 416 0 addi 11,1,1196 ld 5,768(18) ld 9,.LC7@toc@l(10) mr 10,20 .loc 1 305 0 so why on earth do we have such a weird location list? (debug_insn 8123 8124 7848 5 (var_location:DI D#142 (mem/u/c:DI (lo_sum:DI (debug_expr:DI D#146) (const:DI (unspec:DI [ (symbol_ref/u:DI (*.LC7) [flags 0x2]) ] UNSPEC_TOCREL))) [23 S8 A8])) -1 (nil)) (debug_insn 7848 8123 7852 5 (var_location:SI iznuc (fix:SI (plus:DF (float:DF (mem:SI (debug_expr:DI D#142) [0 MEM[base: D.8528_3216, \ offset: 0B]+0 S4 A32])) (mem:DF (debug_expr:DI D#143) [0 MEM[base: D.8527_3225, offset: 0B]+0 S8 A64] chgpen.fppized.f:416 -1 (nil)) Ick!
[Bug fortran/50267] [4.4] ICE in lhd_set_decl_assembler_name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50267 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-09-02 16:32:23 UTC --- OK, let's close this as RESOLVED FIXED.
[Bug other/50277] New: strndup should use strnlen instead of strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277 Bug #: 50277 Summary: strndup should use strnlen instead of strlen Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ivan.tub...@gmail.com Regarding strndup (const char *s, size_t n): strndup is using strlen to get the length of s, in order to decide whether to allocate n+1 characters or strlen(s)+1. This is inefficient. Imagine that s is one googol characters long, and I call strndup(s,3) because I want a duplicate of up to the first three characters. Yet strlen will go all the way to the end of s, just to find that it is longer than 3 characters! I suggest using strnlen instead.
[Bug other/50277] strndup should use strnlen instead of strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-02 16:45:15 UTC --- strndup is part of the libc that comes from your OS and not part of GCC. Most likely you wanted to file this as a glibc bug.
[Bug other/50277] strndup should use strnlen instead of strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277 --- Comment #2 from Ivan Tubert-Brohman ivan.tubert at gmail dot com 2011-09-02 16:51:42 UTC --- On Fri, Sep 2, 2011 at 12:45 PM, pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-02 16:45:15 UTC --- strndup is part of the libc that comes from your OS and not part of GCC. Most likely you wanted to file this as a glibc bug. Thanks, I got confused because I found the code in the gcc repository. (I was looking at http://gcc.gnu.org/viewcvs/trunk/libiberty/strndup.c?view=markup )
[Bug other/50277] strndup should use strnlen instead of strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277 --- Comment #3 from Ivan Tubert-Brohman ivan.tubert at gmail dot com 2011-09-02 16:55:07 UTC --- And the code in glibc already uses strnlen. Sorry about that. Please close the ticket unless you deem necessary to modify the version in libiberty/strndup.c
[Bug other/50277] strndup should use strnlen instead of strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-02 16:58:48 UTC --- Well that is the portable version of strndup, GCC uses it only once but it is only will ever be called with a string which has a null char. Also strnlen is not portable either.
[Bug fortran/50278] New: [4.7 Regression] SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278 Bug #: 50278 Summary: [4.7 Regression] SPEC CPU 2000 failed to build Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 178470 failed to build 178.galgel, 191.fma3d and 200.sixtrack. All errors look like gfortran -c -o lapak.o -ffixed-form -ffixed-line-length-132 -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math lapak.f90 lapak.f90: In function 'ilaenv': lapak.f90:4285:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[3]: *** [lapak.o] Error 1 Revision 178287 is OK.
[Bug fortran/50278] [4.7 Regression] SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-09-02 17:27:43 UTC --- [hjl@gnu-35 delta-fortran]$ cat x.f INTEGER FUNCTION ILAENV( ISPEC, NAME, OPTS, N1, N2, N3, $ N4 ) LOGICALCNAME, SNAME CHARACTER*1C1 CHARACTER*2C2, C4 CHARACTER*3C3 CHARACTER*6SUBNAM GO TO ( 100, 100, 100, 400, 500, 600, 700, 800 ) ISPEC 100 CONTINUE ILAENV = 1 IC = ICHAR( SUBNAM( 1:1 ) ) IZ = ICHAR( 'Z' ) IF( IZ.EQ.90 .OR. IZ.EQ.122 ) THEN IF( IC.GE.97 .AND. IC.LE.122 ) THEN DO 10 I = 2, 6 IC = ICHAR( SUBNAM( I:I ) ) IF( IC.GE.97 .AND. IC.LE.122 ) $SUBNAM( I:I ) = CHAR( IC-32 ) 10 CONTINUE END IF IF( ( IC.GE.129 .AND. IC.LE.137 ) .OR. $ ( IC.GE.162 .AND. IC.LE.169 ) ) THEN DO 20 I = 2, 6 IF( ( IC.GE.129 .AND. IC.LE.137 ) .OR. $ ( IC.GE.162 .AND. IC.LE.169 ) ) $SUBNAM( I:I ) = CHAR( IC+64 ) 20 CONTINUE END IF IF( IC.GE.225 .AND. IC.LE.250 ) THEN SUBNAM( 1:1 ) = CHAR( IC-32 ) DO 30 I = 2, 6 IF( IC.GE.225 .AND. IC.LE.250 ) $SUBNAM( I:I ) = CHAR( IC-32 ) 30 CONTINUE END IF END IF C1 = SUBNAM( 1:1 ) SNAME = C1.EQ.'S' .OR. C1.EQ.'D' CNAME = C1.EQ.'C' .OR. C1.EQ.'Z' IF( .NOT.( CNAME .OR. SNAME ) ) $ RETURN IF( C2.EQ.'GE' ) THEN IF( C3.EQ.'QRF' .OR. C3.EQ.'RQF' .OR. C3.EQ.'LQF' .OR. $ C3.EQ.'QLF' ) THEN IF( C4.EQ.'QR' .OR. C4.EQ.'RQ' .OR. C4.EQ.'LQ' .OR. $ C4.EQ.'BR' ) THEN NX = 128 END IF END IF END IF ILAENV = NX RETURN 400 CONTINUE 500 CONTINUE 600 CONTINUE 700 CONTINUE 800 CONTINUE END SUBROUTINE DGEHRD( N, ILO, IHI, A, LDA, TAU, WORK, LWORK, INFO ) REAL*8 A( LDA, * ), TAU( * ), WORK( * ) NB = ILAENV( 1, 'DGEHRD', ' ', N, ILO, IHI, -1 ) IF( NB.GT.1 .AND. NB.LT.NH ) THEN NX = MAX( NB, ILAENV( 3, 'DGEHRD', ' ', N, ILO, IHI, -1 ) ) IF( NX.LT.NH ) THEN IWS = N*NB END IF END IF WORK( 1 ) = IWS END [hjl@gnu-35 delta-fortran]$ /export/gnu/import/svn/gcc-test-spec/usr/bin/gcc -S -O3 -ffast-math -funroll-loops x.f x.f:61.22: NB = ILAENV( 1, 'DGEHRD', ' ', N, ILO, IHI, -1 ) 1 Warning: Type mismatch in argument 'name' at (1); passed CHARACTER(1) to INTEGER(4) x.f:63.34: NX = MAX( NB, ILAENV( 3, 'DGEHRD', ' ', N, ILO, IHI, -1 ) ) 1 Warning: Type mismatch in argument 'name' at (1); passed CHARACTER(1) to INTEGER(4) x.f: In function ‘ilaenv’: x.f:1:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-35 delta-fortran]$
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 --- Comment #11 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-09-02 17:44:28 UTC --- Also, when I built a new cross-compiler over on gcc10, the issue moved from .LC7 to .LC8 -- so the exact .LC number may vary for whatever reason.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2011-09-02 18:09:41 UTC --- (In reply to comment #14) .init_array section is an array of pointers. How do you grep it? You arrange for the pointers to be assigned values whose bytes happen to correspond to text (endian-independent text, ideally). Just like using grep to determine target endianness or floating point format. I couldn't find an uniform way to assign a fixed address to symbol in a section which works for all ELF targets.
[Bug ada/43598] GNAT.Expect.Non_Blocking_Spawn double free or corruption
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43598 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #1 from nicolas.boulenguez at free dot fr 2011-09-02 18:21:16 UTC --- The reproducer does not print any error with gnat 4.6.1-5 on Linux 3.0.0-1-amd64.
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 --- Comment #6 from Michael Matz matz at gcc dot gnu.org 2011-09-02 18:31:56 UTC --- Author: matz Date: Fri Sep 2 18:31:47 2011 New Revision: 178489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178489 Log: PR middle-end/50260 * ipa-split.c (split_function): Call add_referenced_var. * tree-ssa-phiopt.c (cond_store_replacement): Don't call get_var_ann. (cond_if_else_store_replacement_1): Ditto. * tree-ssa-pre.c (get_representative_for): Ditto. (create_expression_by_pieces): Ditto. (insert_into_preds_of_block): Ditto. * tree-sra.c (create_access_replacement): Ditto. (get_replaced_param_substitute): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/tree-sra.c trunk/gcc/tree-ssa-phiopt.c trunk/gcc/tree-ssa-pre.c
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-09-02 18:42:24 UTC --- Fixed.
[Bug fortran/50278] [4.7 Regression] SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-02 19:16:22 UTC --- I think it has been fixed by the commit for PR middle-end/50260 (Rev. 178488)
[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087 eric-bugs at omnifarious dot org changed: What|Removed |Added CC||eric-bugs at omnifarious ||dot org --- Comment #5 from eric-bugs at omnifarious dot org 2011-09-02 20:57:45 UTC --- I thought that perhaps it was expected behavior. I still think it's a missed optimization opportunity. A call of a constexpr function can clearly, in all cases, be reduced to a constant expression if the arguments are also constant expressions. So it seems like the optimizer should do this if it can. But it isn't a 'bug' exactly, just more of a 'it could do this better'.
[Bug ada/37110] Assert_Failure at atree.adb:886 caused by legal prefixed notation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37110 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #4 from nicolas.boulenguez at free dot fr 2011-09-02 21:15:38 UTC --- Found with same sources. 4.4.6 (x86_64-pc-linux-gnu) Assert_Failure atree.adb:884 I will try to reduce the needed sources and submit them.
[Bug fortran/50149] loader error with source containing common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 --- Comment #3 from Behzad Salimi riddle00 at gmail dot com 2011-09-02 22:34:27 UTC --- Hello, Thank you very much for your reply and help. Your example pointed me to the clue to find the error in my source: evidently, a /name/ block is required even when the name is empty, i.e., common // ..., my source had common i, j, k, ... this is not allowed! What is surprising is that no compiler error or warning was generated while the loader complained! I had expected to get a compiler error if the common /name/ ... format is strictly required. Perhaps you could make a note to cause a compiler error in your future distributions. Problem is solved and I thank you very much for your assistance. You can delete my original bug report as resolved and perhaps mark it as a remark for a future compiler improvement. Take care, Behzad. On Mon, Aug 22, 2011 at 6:38 AM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 Tobias Burnus burnus at gcc dot gnu.org changed: What |Removed |Added CC| |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-22 13:38:45 UTC --- (In reply to comment #0) System Version: Mac OS X 10.6.8 (10K549), Kernel Version: Darwin 10.8.0 gcc/gfortran version 4.6.1 ld: duplicate symbol ___BLNK__ in obj/trajectory.o and obj/integral.o collect2: ld returned 1 exit status As written, I cannot reproduce the problem on Linux. Can you create a minimal example which reproduces this error and attach it, stating exactly the command-line options you used? For instance, the following example works for me on Linux with no special options and with the options you used. As expected, I get in the object files the blank common (common // ...), namely nm shows the __BLNK__ symbol in both files: 0008 C __BLNK__ However, as the C indicates, the data is in common and thus should not produce any error message if it exists in multiple object files. What do you get if you run nm obj/trajectory.o |grep __BLNK__ and nm obj/integral.o |grep __BLNK__? ! - file1.f90 - subroutine foo integer :: i common // i end subroutine foo ! - file2.f90 - subroutine bar integer :: j common // j end subroutine bar call foo() call bar() end -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #16 from vries at gcc dot gnu.org 2011-09-02 22:47:42 UTC ---
Started testing patch from comment 9, augmented with comments:
...
Index: explow.c
===
--- explow.c (revision 178145)
+++ explow.c (working copy)
@@ -1062,6 +1062,20 @@ emit_stack_restore (enum save_level save
/* The default is that we use a move insn. */
rtx (*fcn) (rtx, rtx) = gen_move_insn;
+ /* If stack_realign_drap, the x86 backend emits a prologue that aligns both
+ STACK_POINTER and HARD_FRAME_POINTER.
+ If stack_realign_fp, the x86 backend emits a prologue that aligns only
+ STACK_POINTER. This renders the HARD_FRAME_POINTER unusable for accessing
+ aligned variables, which is reflected in ix86_can_eliminate.
+ We normally still have the realigned STACK_POINTER that we can use.
+ But if there is a stack restore still present at reload, it can trigger
+ mark_not_eliminable for the STACK_POINTER, leaving no way to eliminate
+ FRAME_POINTER into a hard reg.
+ To prevent this situation, we force need_drap if we emit a stack
+ restore. */
+ if (SUPPORTS_STACK_ALIGNMENT)
+crtl-need_drap = true;
+
/* See if this machine has anything special to do for this kind of save. */
switch (save_level)
{
...
[Bug fortran/50149] loader error with source containing common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Severity|major |normal --- Comment #4 from kargl at gcc dot gnu.org 2011-09-02 23:00:54 UTC --- (In reply to comment #3) Hello, Thank you very much for your reply and help. Your example pointed me to the clue to find the error in my source: evidently, a /name/ block is required even when the name is empty, i.e., common // ..., my source had common i, j, k, ... this is not allowed! No, a /name/ block *IS NOT* required even when the name is empty. troutmask:sgk[218] cat a.f90 b.f90 c.f90 ! a.f90 subroutine foo common i i = 2 end subroutine foo ! b.f90 subroutine bar common j j = 1 end subroutine bar ! c.f90 program c common k call foo call bar print *, k end program c This compiles with gfortran 4.7.0 with all of the options you specify. What is surprising is that no compiler error or warning was generated while the loader complained! I had expected to get a compiler error if the common /name/ ... format is strictly required. Perhaps you could make a note to cause a compiler error in your future distributions. It's not required. You have a broken loader, which is not a gfortran problem.
[Bug bootstrap/50279] New: go bootstrap fails with lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279 Bug #: 50279 Summary: go bootstrap fails with lto Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: jpfol...@verizon.net A git checkout of gcc trunk at 982ffd8d9a1d9df5d91298d89d38293f4f3c86b4 configured with --with-build-config=bootstrap-lto --enable-languages=all,obj-c++,go on a gentoo linux x86_64 system with a gcc 4.5.3 bootstrap compiler gives this error: /root/gcc/lto/./prev-gcc/g++ -B/root/gcc/lto/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/root/gcc/libstdc++-v3/libsupc++ -L/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/root/gcc/lto/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o go1 \ go/ast-dump.o go/dataflow.o go/export.o go/expressions.o go/go-backend.o go/go-dump.o go/go-gcc.o go/go-lang.o go/go-optimize.o go/go.o go/gogo-tree.o go/gogo.o go/import.o go/import-archive.o go/lex.o go/parse.o go/runtime.o go/statements.o go/types.o go/unsafe.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lppl_c -lppl -lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz In file included from ../../gcc/tree-ssa-address.c:1020:0, from ../../gcc/coretypes.h:63, from :4410: ../../gcc/go/gofrontend/gogo-tree.cc: In function 'sort': ../../gcc/go/gofrontend/gogo-tree.cc:205:32: internal compiler error: in splice_child_die, at dwarf2out.c:5007 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [/tmp/ccgXj2ab.ltrans1.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[2]: *** [go1] Error 1
[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-03 00:48:25 UTC --- (In reply to comment #5) I still think it's a missed optimization opportunity. Yes, it definitely is. I'm just not sure whether it should be fixed by doing constexpr expansion in non-constant expression contexts in some cases, or improving normal optimization to handle this case.
[Bug c++/50280] New: Incorrect type deduced for T when passed a const bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280
Bug #: 50280
Summary: Incorrect type deduced for T when passed a const
bitfield
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ cat test.cc
struct S { int bf : 3; };
templateclass _T1
void make_pair(_T1 __x) {}
void foo() {
const S s = S();
make_pair(s.bf);
}
$ g++-4.6 -c test.cc
test.cc: In function 'void foo()':
test.cc:8:17: error: cannot bind bitfield 's.S::bf' to 'int'
$ clang++ -c test.cc
$
It looks like gcc is deducing the parameter type from the base type of the
bitfield rather than its type modified by qualifiers on the containing object.
This seems related to PR43663, but isn't the same issue because using const
_T1 in make_pair makes this compile.
This showed up when compiling a make_pair(val, bitfield) call in C++0x mode
that worked in C++98 mode, but the underlying issue is present in C++98 too.
[Bug c/50281] New: result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
Bug #: 50281
Summary: result registers are overwritten giving incorrect
result
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nickpar...@eaton.com
Application code
bool8_t testMaths(void)
{
uint32_t result1_u4;
uint32_t result2_u4;
int32_t result1_s4;
int32_t result2_s4;
//;
// Multiplying U3s
//;
result1_u4 = MulU3U3S3(16777215L,100L); // should be around 100
PutImmediateString(ECU_COMMS,\r\nmulu3u3s3 : [ );
PrintINT4(ECU_COMMS, 16777215L, 'D',0);
PutImmediateString(ECU_COMMS, ] x [);
PrintINT4(ECU_COMMS, 100L, 'D',0);
PutImmediateString(ECU_COMMS, ] = [);
PrintINT4(ECU_COMMS, result1_u4, 'D',0);
PutImmediateString(ECU_COMMS, ]);
.
.
.
.
}
/***
* MulU3U3S3()
*
* Function: Multiplies two unsigned 24bit max values,
* then shifts left by 2^24
***/
uint32_t MulU3U3S3(uint32_t a_u4, uint32_t b_u4)
{
uint32_t answer;
asm volatile
(
push r0 \n\t
push r1 \n\t
clr r20 \n\t // zero register
// 0 byte shifts
mul %A1,%A2 \n\t // a1a2
mov r2,r0 \n\t
mov r3,r1 \n\t
// 1 byte shifts
mul %A1,%B2 \n\t
add r3,r0\n\t
adc r4,r1\n\t
adc r5,r20 \n\t
mul %A2,%B1 \n\t
add r3,r0\n\t
adc r4,r1\n\t
adc r5,r20 \n\t
// 2 byte shifts
mul %A1,%C2 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r20 \n\t
mul %A2,%C1 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r20 \n\t
mul %B2,%B1 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r20 \n\t
// 3 byte shifts
mul %B1,%C2 \n\t
add r5,r0\n\t
adc r6,r1\n\t
adc r7,r20 \n\t
mul %B2,%C1 \n\t
add r5,r0\n\t
adc r6,r1\n\t
adc r7,r20 \n\t
// 4 byte shifts
mul %C2,%C1 \n\t
add r6,r0\n\t
adc r7,r1\n\t
mov %A0,r5 \n\t
mov %B0,r6 \n\t
mov %C0,r7 \n\t
clr %D0 \n\t
//adc %G0,r20 \n\t
pop r1\n\t
pop r0\n\t
: =r (answer)
: r (a_u4), r (b_u4)
: r2,r3,r4,r5,r6,r7,r20
);
return (answer);
}
[Bug inline-asm/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |inline-asm Severity|major |normal
[Bug c++/50280] Incorrect type deduced for T when passed a const bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-03 01:07:40 UTC --- It works on the trunk as of 4.7.0 20110823 [trunk revision 178018]
[Bug c/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 NickParker at Eaton dot com changed: What|Removed |Added Component|inline-asm |c Severity|normal |major --- Comment #1 from NickParker at Eaton dot com 2011-09-03 01:09:21 UTC --- top level function to test mulu3u3s3 function and print result - 932 .LM119: 933 0478 6FEF ldi r22,lo8(16777215) 934 047a 7FEF ldi r23,hi8(16777215) 935 047c 8FEF ldi r24,hlo8(16777215) 936 047e 90E0 ldi r25,hhi8(16777215) 937 0480 24E6 ldi r18,lo8(100) 938 0482 30E0 ldi r19,hi8(100) 939 0484 40E0 ldi r20,hlo8(100) 940 0486 50E0 ldi r21,hhi8(100) 941 0488 0E94 call MulU3U3S3 942 048c 6B01 movw r12,r22 943 048e 7C01 movw r14,r24 944 .LVL128: 945 .LM120: 946 0490 80E0 ldi r24,lo8(0) 947 0492 60E0 ldi r22,lo8(__c.2370) 948 0494 70E0 ldi r23,hi8(__c.2370) 949 0496 0E94 call PutFlashString 950 .LM121: 951 049a 80E0 ldi r24,lo8(0) 952 049c 4FEF ldi r20,lo8(16777215) 953 049e 5FEF ldi r21,hi8(16777215) 954 04a0 6FEF ldi r22,hlo8(16777215) 955 04a2 70E0 ldi r23,hhi8(16777215) 956 04a4 24E4 ldi r18,lo8(68) 957 04a6 0E94 call PrintINT4 958 .LM122: 959 04aa 80E0 ldi r24,lo8(0) 960 04ac 60E0 ldi r22,lo8(__c.2372) 961 04ae 70E0 ldi r23,hi8(__c.2372) 962 04b0 0E94 call PutFlashString 963 .LM123: 964 04b4 80E0 ldi r24,lo8(0) 965 04b6 44E6 ldi r20,lo8(100) 966 04b8 50E0 ldi r21,hi8(100) 967 04ba 60E0 ldi r22,hlo8(100) 968 04bc 70E0 ldi r23,hhi8(100) 969 04be 24E4 ldi r18,lo8(68) 970 04c0 0E94 call PrintINT4 971 .LM124: 972 04c4 80E0 ldi r24,lo8(0) 973 04c6 60E0 ldi r22,lo8(__c.2374) 974 04c8 70E0 ldi r23,hi8(__c.2374) 975 04ca 0E94 call PutFlashString 976 .LM125: 977 04ce 80E0 ldi r24,lo8(0) 978 04d0 B701 movw r22,r14 979 04d2 A601 movw r20,r12 980 04d4 24E4 ldi r18,lo8(68) 981 04d6 0E94 call PrintINT4 982 .LM126: 983 04da 80E0 ldi r24,lo8(0) 984 04dc 60E0 ldi r22,lo8(__c.2376) 985 04de 70E0 ldi r23,hi8(__c.2376) 986 04e0 0E94 call PutFlashString -maths code 259 .globalMulU3U3S3 261 MulU3U3S3: 262 .LFB8: 263 .LM19: 264 .LVL22: 265 00ee 2F92 push r2 266 00f0 3F92 push r3 267 00f2 4F92 push r4 268 00f4 5F92 push r5 269 00f6 6F92 push r6 270 00f8 7F92 push r7 271 00fa AF92 push r10 272 00fc EF92 push r14 273 00fe FF92 push r15 274 0100 0F93 push r16 275 0102 1F93 push r17 276 /* prologue: function */ 277 /* frame size = 0 */ 278 .LM20: 279 0104 7901 movw r14,r18 280 0106 8A01 movw r16,r20 281 /* #APP */ 282; 324 maths_mul.c 1 283 0108 0F92 push r0 284 010a 1F92 push r1 285 010c AF92 push r10 286 010e AA24 clr r10 287 0110 6E9D mul r22,r14 288 0112 202C mov r2,r0 289 0114 312C mov r3,r1 290 0116 6F9D mul r22,r15 291 0118 300C add r3,r0 292 011a 411C adc r4,r1 293 011c 5A1C adc r5,r10 294 011e E79E mul r14,r23 295 0120 300C add r3,r0 296 0122 411C adc r4,r1 297 0124 5A1C adc r5,r10 298 0126 609F mul r22,r16 299 0128 400C add r4,r0 300 012a 511C adc r5,r1 301 012c 6A1C adc r6,r10 302 012e E89E mul r14,r24 303 0130 400C add r4,r0 304 0132 511C adc r5,r1 305 0134 6A1C adc r6,r10 306 0136 F79E mul r15,r23 307 0138 400C add r4,r0 308 013a 511C adc r5,r1 309 013c 6A1C adc r6,r10 310 013e 709F mul r23,r16 311 0140 500C add r5,r0 312
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target Severity|major |normal
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-03 01:13:00 UTC --- I think your inline-asm is broken. You have: : =r (answer) : r (a_u4), r (b_u4) : r2,r3,r4,r5,r6,r7,r20 But you modify %1 and %2 which causes what you are seeing and GCC thinks your inline-asm does not modify those registers.
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #3 from NickParker at Eaton dot com 2011-09-03 01:28:57 UTC --- The final printed calculation result of MulU3U3S3() is wrong, because two of the four result registers are incorrect and have been overwritten. mulu3u3s3 : [ +0016777215 ] x [+000100 ] = [+0010502615 ] I am wondering if the CPU is running out of registers? Because I have found stepping through that the calcualtion is actually working correctly
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #4 from NickParker at Eaton dot com 2011-09-03 01:30:26 UTC --- Hi Andrew, Can you please explain what you mean by %1 and %2. Thanks.
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #5 from NickParker at Eaton dot com 2011-09-03 01:32:20 UTC ---
Sorry. I pasted a broken version. Before. Code below works.
uint32_t MulU3U3S3(uint32_t a_u4, uint32_t b_u4)
{
//uint32_t answer;
asm volatile
(
push r0 \n\t
push r1 \n\t
push r10 \n\t
clr r10 \n\t // zero register
// 0 byte shifts
mul %A1,%A2 \n\t // a1a2
mov r2,r0\n\t
mov r3,r1\n\t
// 1 byte shifts
mul %A1,%B2 \n\t
add r3,r0\n\t
adc r4,r1\n\t
adc r5,r10 \n\t
mul %A2,%B1 \n\t
add r3,r0\n\t
adc r4,r1\n\t
adc r5,r10 \n\t
// 2 byte shifts
mul %A1,%C2 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r10 \n\t
mul %A2,%C1 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r10 \n\t
mul %B2,%B1 \n\t
add r4,r0\n\t
adc r5,r1\n\t
adc r6,r10 \n\t
// 3 byte shifts
mul %B1,%C2 \n\t
add r5,r0\n\t
adc r6,r1\n\t
adc r7,r10 \n\t
mul %B2,%C1 \n\t
add r5,r0\n\t
adc r6,r1\n\t
adc r7,r10 \n\t
// 4 byte shifts
mul %C2,%C1 \n\t
add r6,r0\n\t
adc r7,r1\n\t
mov %A0,r5 \n\t
mov %B0,r6 \n\t
mov %C0,r7 \n\t
clr %D0 \n\t
//adc %G0,r20 \n\t
pop r10 \n\t
pop r1 \n\t
pop r0 \n\t
: =r (answer)
: r (a_u4), r (b_u4)
: r2,r3,r4,r5,r6,r7,r10
);
return (answer);
}
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-03 01:38:44 UTC --- Oh the real issue is that the : r (a_u4), r (b_u4) Those two arguments could be in r0 or r1. Also the generated asm does not correspond to the source you gave as there is an extra push/pop r10.
[Bug ada/37110] Assert_Failure at atree.adb:886 caused by legal prefixed notation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37110 --- Comment #5 from nicolas.boulenguez at free dot fr 2011-09-03 03:23:36 UTC --- -- There were two distinct bugs. package P is type T1 is tagged null record; type T2 is tagged null record; function Func (Func_Formal : in T1'Class; I : in Integer) return access T2; procedure Proc (Proc_Formal : out T2); end P; -- This legal line causes a bug box. -- 4.4.6 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:1149 -- 4.6.1 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:1240 with P; use P; procedure Trigger1 is Actual : constant T1 := (null record); begin Proc (Proc_Formal = Func (Func_Formal = Actual, I = 0).all); end Trigger1; -- Obsessive Obfuscated Programming on Trigger1 caused another kind of -- bug box with 4.3 and 4.4. -- 4.4.6 (x86_64-pc-linux-gnu) Assert_Failure atree.adb:884 -- 4.6.1 (x86_64-pc-linux-gnu) detects the missing body. with P; use P; procedure Trigger2 is Actual : constant T1 := (null record); begin Actual.Func (0).Proc; end Trigger2;
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #7 from NickParker at Eaton dot com 2011-09-03 04:45:08 UTC --- Please ignore the r10/r20 guff I was experimenting. I later realised the muls3s3u3 code gives the right answer, the problem occurs later on somehow Nick.
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #8 from NickParker at Eaton dot com 2011-09-03 04:46:45 UTC --- Please ignore the r10/r20 guff I was experimenting. I later realised the muls3s3u3 code gives the right answer, the problem occurs later on somehow the registers where the results are are getting walked on. Nick.
