[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-06-16 06:55 ---
This looks wrong.  The code in expand_one_stack_var_at (before dynamic stack
realignment) made perfect sense, if we gave a bigger alignment to some variable
(e.g. automatic array), it is useful to tell the expanders that we did.
And if it got a smaller than requested alignment, similarly it is better to
tell that to the expanders (the latter happens when the requested alignment is
larger than what can be supported for automatic vars).
>From the offset we don't know absolute alignment, unless we know how aligned is
virtual_stack_vars_rtx.  We should know that without dynamic stack realignment,
for dynamic stack realignment all we need to ensure is that the computed
alignment isn't larger than the one we are going to use.
E.g. replacing MAX_SUPPORTED_STACK_ALIGNMENT with
crtl->max_used_stack_slot_alignment (or crtl->stack_alignment_needed).
Or say MAX (crtl->max_used_stack_slot_alignment, PREFERRED_STACK_BOUNDARY)
or MAX (crtl->stack_alignment_needed, PREFERRED_STACK_BOUNDARY)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[wilson at codesourcery dot com]

--- Comment #10 from wilson at codesourcery dot com  2010-06-16 06:30 
---
Subject: Re:  suboptimal MIPS widening multiply accumulate

On Wed, 2010-06-09 at 20:21 +, bernds at gcc dot gnu dot org wrote:
> What do you think?  Please let me know what your MIPS tests turned up.

I'm looking at this again.  My MIPS tests showed that my patch fixed 17
gcc.target/mips multiply-accumulate testcases that were accidentally
broken by the new tree level widening multiply optimization pass.  My
new testcase madd-9.c failed, but it turned out that I accidentally
double-patched the file.  Fixing the file, it now passes.  I forgot to
include this testcase in my second patch, though it was there in the
first one.  The bad news is that there are two new failures:
dpaq_sa_l_w.c and dpsq_sa_l_w.c.  These are MIPS DSP fixed-point
multiply-accumulate testcases, which is something I definitely didn't
bother to check earlier.  Overall I would say it is a win, since it
fixes many int/long/long long examples, and only breaks a few obscure
cases that should be fixable with a little more work.

I'm looking at your patch too.  There is a testcase that doesn't appear
to belong, gcc.target/arm/pr42172-1.c.  I'm not sure why
convert_plusminus_to_widen needs to check for MULT and call
convert_mult_to_widen.  If we are scanning basic blocks from top to
bottom, it seems that the multiplies would have already been checked.
But maybe this has something to do with looking at operands computed in
other basic blocks that haven't been scanned yet, in which case it would
make sense.  I'm not sure if that is possible.  Otherwise, it looks like
you have completed and cleanup up a bunch of stuff that I didn't get far
enough to notice.  It all looks good to me.  I can try rerunning MIPS
testcases to see how it works.

I see that the failure of the DSP fixed-point tests is because we have
checks for
+  if (TREE_CODE (type) != INTEGER_TYPE)
+return false;
and the old code in expr.c that we are replacing does
-  if ((TREE_CODE (type) == INTEGER_TYPE
-  || TREE_CODE (type) == FIXED_POINT_TYPE)
So that looks like an easy fix (assuming no other complications), but
will require a rebuild and retest.

Jim


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902

[Bug middle-end/44505] [4.6 Regression] gcc.c-torture/execute/frame-address.c

[amodra at gmail dot com]

--- Comment #3 from amodra at gmail dot com  2010-06-16 05:59 ---
Confirmed on powerpc-linux.  check_fa tail calls check_fa_mid, ignoring the
fact that check_fa_mid is passed the address of a check_fa local var.

1510 :
1510:   94 21 ff e0 stwur1,-32(r1)
1514:   38 61 00 08 addir3,r1,8
1518:   38 21 00 20 addir1,r1,32
151c:   4b ff ff b4 b   14d0 


-- 

amodra at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-16 05:59:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505

[Bug tree-optimization/44507] [4.5/4.6 Regression] vectorization ANDs array elements together incorrectly

[amodra at gcc dot gnu dot org]

--- Comment #14 from amodra at gcc dot gnu dot org  2010-06-16 04:23 ---
Subject: Bug 44507

Author: amodra
Date: Wed Jun 16 04:23:05 2010
New Revision: 160822

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160822
Log:
PR tree-optimization/44507
* gcc.dg/vect/pr44507.c (seeIf256ByteArrayIsConstant): Correct cast.


Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/pr44507.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507

[Bug tree-optimization/44507] [4.5/4.6 Regression] vectorization ANDs array elements together incorrectly

[amodra at gcc dot gnu dot org]

--- Comment #13 from amodra at gcc dot gnu dot org  2010-06-16 04:22 ---
Subject: Bug 44507

Author: amodra
Date: Wed Jun 16 04:22:36 2010
New Revision: 160821

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160821
Log:
PR tree-optimization/44507
* gcc.dg/vect/pr44507.c (seeIf256ByteArrayIsConstant): Correct cast.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr44507.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507

[Bug tree-optimization/44507] [4.5/4.6 Regression] vectorization ANDs array elements together incorrectly

[amodra at gmail dot com]

--- Comment #12 from amodra at gmail dot com  2010-06-16 03:14 ---
testsuite/gcc.dg/vect/pr44507.c is invalid on LP64.  This:

curVal = *((unsigned long *)(&pArray[index]));

loads 8 bytes, ie. the last time around the loop this loads 4 bytes past the
end of the array.  On big-endian machines this is the low 32 bits so the test
fails.  The obvious fix is to replace the cast with (unsigned int *) and indeed
this makes the test pass on powerpc64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507

[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)

[danglin at gcc dot gnu dot org]

--- Comment #14 from danglin at gcc dot gnu dot org  2010-06-16 02:44 
---
I think the setting of reg:DI 2374 from reg:DI 2349 is incorrect.  Testing
fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740

[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)

[danglin at gcc dot gnu dot org]

--- Comment #13 from danglin at gcc dot gnu dot org  2010-06-16 01:27 
---
The flag for reg:DI 2349 is copied from:

Breakpoint 7, set_reg_attrs_from_value (reg=0x83fffd4c0420, 
x=0x83fffd976c40) at ../../gcc/gcc/emit-rtl.c:975
975   if (HARD_REGISTER_P (reg))
(gdb) p debug_rtx (reg)  
(reg:DI 2349)
$69 = void
(gdb) p debug_rtx (x)  
(reg/f:DI 356 [ D.35290 ])

The flag in reg/f:DI 356 is set here:

Breakpoint 6, mark_reg_pointer (reg=0x83fffd976c40, align=64)
at ../../gcc/gcc/emit-rtl.c:1118
1118  if (! REG_POINTER (reg))
(gdb) p debug_rtx (reg) 
(reg:DI 356 [ D.35290 ])
$71 = void
(gdb) bt
#0  mark_reg_pointer (reg=0x83fffd976c40, align=64)
at ../../gcc/gcc/emit-rtl.c:1118
#1  0x40dd6c54 in expand_one_register_var (var=0x83fffdff1790)
at ../../gcc/gcc/cfgexpand.c:847
#2  0x40dd7574 in expand_one_var (var=0x83fffd976c40, 
toplevel=0 '\0', really_expand=128 '\200')
at ../../gcc/gcc/cfgexpand.c:978
#3  0x40dd8ecc in expand_used_vars ()
at ../../gcc/gcc/cfgexpand.c:1310
#4  0x40de6118 in gimple_expand_cfg ()
at ../../gcc/gcc/cfgexpand.c:3779
#5  0x41b86534 in execute_one_pass (pass=0x83fffdff1790)
at ../../gcc/gcc/passes.c:1568

(gdb) p debug_tree (var)
 
sizes-gimplified asm_written public unsigned DI
size 
unit size 
align 64 symtab -2147482625 alias set -1 canonical type
83fffdd8ac78
pointer_to_this >
used unsigned ignored DI file ../../gcc/gcc/gimple-pretty-print.c line
1498 col 1 size  unit size 
align 64 context 
abstract_origin 
(reg:DI 356 [ D.35290 ])>
asm_written used nothrow public private protected static deprecated visited
tree_0 tree_1 tree_2 tree_3 tree_4 tree_6>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740

[Bug c/44553] Cross compiling for ia64 fails as stdlib.h doesn't exist

[tony at bakeyournoodle dot com]

--- Comment #2 from tony at bakeyournoodle dot com  2010-06-16 01:03 ---
Created an attachment (id=20924)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20924&action=view)
Proposed fix


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553

[Bug c/44553] Cross compiling for ia64 fails as stdlib.h doesn't exist

[tony at bakeyournoodle dot com]

--- Comment #1 from tony at bakeyournoodle dot com  2010-06-16 01:02 ---
Created an attachment (id=20923)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20923&action=view)
Buildlogs


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553

[Bug c/44553] New: Cross compiling for ia64 fails as stdlib.h doesn't exist

[tony at bakeyournoodle dot com]

When trying to cross compile a stage1 (I believe that is the correct
terminology) compiler I get the following error.

---
/home/tony/buildall/ia64/gcc0/./gcc/xgcc -B/home/tony/buildall/ia64/gcc0/./gcc/
-B/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/bin/
-B/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/lib/ -isystem
/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/include -isystem
/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/sys-include -g -O2 -O2  -g
-O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -DUSE_GAS_SYMVER -g 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc
-I/home/tony/buildall/src/gcc/libgcc -I/home/tony/buildall/src/gcc/libgcc/.
-I/home/tony/buildall/src/gcc/libgcc/../gcc
-I/home/tony/buildall/src/gcc/libgcc/../include  -DHAVE_CC_TLS -o unwind-c.o
-MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c
/home/tony/buildall/src/gcc/libgcc/../gcc/unwind-c.c
In file included from
/home/tony/buildall/src/gcc/libgcc/../gcc/unwind-sjlj.c:30:
/home/tony/buildall/ia64/gcc0/./gcc/include/unwind.h:214:20: error: stdlib.h:
No such file or directory
In file included from /home/tony/buildall/src/gcc/libgcc/../gcc/unwind-c.c:29:
/home/tony/buildall/ia64/gcc0/./gcc/include/unwind.h:214:20: error: stdlib.h:
No such file or directory
---

It looks like stdlib.h is included to get the prototype for abort().

I'll attach the buildlogs for binutils and gcc so you have the exact
commandline used.  Also I have a patch I use to get past the error I cannot
speak to it's correctness but it seems "safe" to me.


-- 
   Summary: Cross compiling for ia64 fails as stdlib.h doesn't exist
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tony at bakeyournoodle dot com
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553

[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)

[danglin at gcc dot gnu dot org]

--- Comment #12 from danglin at gcc dot gnu dot org  2010-06-16 01:01 
---
The REG_POINTER flag for reg:DI 274 is copied from reg:DI 2374 in pa.c.
The flag for reg:DI 2374 is in turn copied from reg:DI 2349 in pa.c.
The flag for reg:DI 2349 is set here:

(gdb) p debug_rtx (reg) 
(reg:DI 2349 [ D.35290 ])
$68 = void
(gdb) bt
#0  mark_reg_pointer (reg=0x83fffd4c0420, align=64)
at ../../gcc/gcc/emit-rtl.c:1118
#1  0x41166d94 in set_reg_attrs_from_value (reg=0x83fffd4c0420, 
x=0x40fd976c40) at ../../gcc/gcc/emit-rtl.c:992
#2  0x41166e14 in gen_reg_rtx_and_attrs (x=0x83fffd976c40)
at ../../gcc/gcc/emit-rtl.c:1003
#3  0x4195a8bc in move_invariant_reg (loop=0x83fffdff18f0, 
invno=64) at ../../gcc/gcc/loop-invariant.c:1416
#4  0x4195ad40 in move_invariants (loop=0x83fffd4c0420)
at ../../gcc/gcc/loop-invariant.c:1489
#5  0x4195ad40 in move_invariants (loop=0x83fffd4c0420)
at ../../gcc/gcc/loop-invariant.c:1489
#6  0x4195b2bc in move_single_loop_invariants (
loop=0x83fffced9ab0) at ../../gcc/gcc/loop-invariant.c:1558
#7  0x4195cdc8 in move_loop_invariants ()
at ../../gcc/gcc/loop-invariant.c:1905
#8  0x419302f8 in rtl_move_loop_invariants ()
at ../../gcc/gcc/loop-init.c:254
#9  0x41b86534 in execute_one_pass (pass=0x83fffdff18f0)
at ../../gcc/gcc/passes.c:1568
#10 0x41b86964 in execute_pass_list (pass=0x83fffd4c0420)
at ../../gcc/gcc/passes.c:1623
#11 0x41b869a8 in execute_pass_list (pass=0x83fffd4c0420)
at ../../gcc/gcc/passes.c:1624
#12 0x41b869a8 in execute_pass_list (pass=0x83fffd4c0420)
at ../../gcc/gcc/passes.c:1624
#13 0x427a78b8 in tree_rest_of_compilation (fndecl=0x83fffdff18f0)
at ../../gcc/gcc/tree-optimize.c:413
... 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740

[Bug c++/44552] specialization of static const class member declaration should issue warning.

[dpovey at gmail dot com]

--- Comment #5 from dpovey at gmail dot com  2010-06-15 23:22 ---
OK thanks guys.


-- 

dpovey at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug c++/44552] specialization of static const class member declaration should issue warning.

[redi at gcc dot gnu dot org]

--- Comment #4 from redi at gcc dot gnu dot org  2010-06-15 23:21 ---
N.B. it's not necessarily a mistake. If an explicit specialization is defined
in another translation unit then the implicit instantiation of the primary
template must be suppressed, or you get multiple definitions and an ODR
violation.

See pages 197-198 of Vandevoorde & Josuttis for a very similar example and
explanation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug c++/44552] specialization of static const class member declaration should issue warning.

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-06-15 23:18 ---
It's true that your specialization is only a declaration, but this would be a
definition too:

template<>
const int MyTraits::kValue = 1;

It's not true that the declaration has no purpose, it tells the compiler there
is an explicit specialization and the primary template should not be implicitly
instantiated.

That's exactly what's needed if an explicit specialization is defined in
another translation unit, otherwise you get multiple definitions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug c++/44552] specialization of static const class member declaration should issue warning.

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|trivial |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug c++/44552] specialization of static const class member declaration should issue warning.

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-06-15 23:13 
---
For the record, neither ICC nor SunStudio warn. I seem to remember that in the
past people often commented that it's pretty tough to produce warnings for this
kind of mistake.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug c++/44552] specialization of static const class member declaration should issue warning.

[dpovey at gmail dot com]

--- Comment #1 from dpovey at gmail dot com  2010-06-15 22:47 ---
Sorry, I made a mistake in the last line: I meant "Definitely not meaningful
for a const member."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug c++/44552] New: specialization of static const class member declaration should issue warning.

[dpovey at gmail dot com]

If you compile the following code:

template class MyTraits {
 public:
  static const T kValue = 0;
};

template<>
const int MyTraits::kValue; // define it.

int main(){
  const void * a = &(MyTraits::kValue);
}

g++ will issue no warnings but give linking errors.  The statement
template<> const int MyTraits::kValue;
is in error: it is intended to be a definition of the variable but C++ does
not allow specializations of definitions (thanks to pinksia for pointing this
out).  I really should have templated the definition.  However, the statement I
did enter can have no possible purpose and I believe a warning should be
issued.  It is possible that the statement could be meaningful for a non-const
static member (I don't know C++ well enough to judge) but it is definitely not
meaningful for a static member: thus I believe a warning is in order.


-- 
   Summary: specialization of static const class member declaration
should issue warning.
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpovey at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552

[Bug middle-end/44551] New: [missed optimization] AVX vextractf128 after vinsertf128

[kretz at kde dot org]

Consider the following testcase:

#include 

static inline __m256i __attribute__((always_inline))
my_add(__m256i a0, __m256i b0)
{
__m128i a1 = _mm256_extractf128_si256(a0, 1);
__m128i b1 = _mm256_extractf128_si256(b0, 1);
__m256i r  =
_mm256_castsi128_si256(_mm_add_epi32(_mm256_castsi256_si128(a0),
_mm256_castsi256_si128(b0)));
r = _mm256_insertf128_si256(r, _mm_add_epi32(a1, b1), 1);
return r;
}

extern int DATA[];

void use_insert_extract()
{
__m256i x = _mm256_loadu_si256((__m256i*)&DATA[0]);
__m256i y = _mm256_loadu_si256((__m256i*)&DATA[1]);
x = my_add(x, y);
x = my_add(x, y);
_mm256_storeu_si256((__m256i*)&DATA[0], x);
}

int main()
{
return DATA[1];
}

Compiled with "g++ -mavx -O3 -Wall -S" one gets the following output:
vmovdqu DATA(%rip), %ymm1
pushq   %rbp
vmovdqu DATA+4(%rip), %ymm0
vextractf128$0x1, %ymm1, %xmm3
vmovdqa %xmm1, %xmm2
movq%rsp, %rbp
vmovdqa %xmm0, %xmm1
vextractf128$0x1, %ymm0, %xmm0
vpaddd  %xmm1, %xmm2, %xmm2
vpaddd  %xmm0, %xmm3, %xmm3
vinsertf128 $0x1, %xmm3, %ymm2, %ymm2
vextractf128$0x1, %ymm2, %xmm3
vpaddd  %xmm1, %xmm2, %xmm1
vpaddd  %xmm0, %xmm3, %xmm0
vinsertf128 $0x1, %xmm0, %ymm1, %ymm0
vmovdqu %ymm0, DATA(%rip)

ICC 11.1 compiles the same source ("-xavx -O3 -Wall -S") to:
vmovdqu   DATA(%rip), %ymm1
vmovdqu   4+DATA(%rip), %ymm0
vextractf128 $1, %ymm1, %xmm2
vextractf128 $1, %ymm0, %xmm6
vpaddd%xmm0, %xmm1, %xmm3
vpaddd%xmm6, %xmm2, %xmm5
vpaddd%xmm0, %xmm3, %xmm4
vpaddd%xmm6, %xmm5, %xmm7
vinsertf128 $1, %xmm7, %ymm4, %ymm8
vmovdqu   %ymm8, DATA(%rip)

Note especially the extract after insert which happens because of the double
application of my_add. This kind of optimization (which ICC is able to apply
here) is important because AVX introduces 256 bit vector registers but
arithmetic/logic/comparison operations on integers remain the 128 bit SSE
variants. Thus if you want to handle integers in YMM registers you will find a
lot of vinsertf128 and vextractf128 operations.


-- 
   Summary: [missed optimization] AVX vextractf128 after vinsertf128
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551

[Bug c++/44548] Link error when defining templated static const variable

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-06-15 22:24 ---
> but it is an explicit specialization of the *definition* of the variable

No it is a specialization of the declaration.  There are only specialization of
declarations; never definitions.  Re-read the link you gave and you will see
the following: "Explicit specialization declaration syntax" .


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548

[Bug c++/44548] Link error when defining templated static const variable

[dpovey at gmail dot com]

--- Comment #2 from dpovey at gmail dot com  2010-06-15 22:19 ---
I don't agree with you that this is not a bug, although I do agree that I could
have coded it differently.

Look at

http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/explicit_specialization.htm

the section on  "Explicit specialization of members of class templates".

You are right, my syntax was an explicit specialization, and that was pointless
and I could have done it a different way, but I believe what I wrote still
counts as  a definition of the variable-- what else could the syntax possibly
mean?  I.e. the line:
template<> const int MyTraits::kValue;
You say this is an explicit specialization; fine, but it is an explicit
specialization of the *definition* of the variable. You can't *declare* a class
member outside of the class itself, and I'm not specializing the class itself. 
So either that line needs to be rejected by the compiler, or it needs to work
as I intended-- what other possible meaning could it have than the one I
intended?  The C++ standard doesn't seem to mention whether or not you are
allowed to explicitly specialize static const variables that have been defined
inside the class, and it does seem a bit pointless to do so, but I think it
should either compile or issue an error or warning. 


-- 

dpovey at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548

[Bug c++/44550] New: Wrong filename in error message when using c++0x + optimised + precompiled headers

[small_duck at revesdemondes dot com]

I'm noticing wrong filenames and line numbers on error messages when combining
optimised build with c++0x and precompiled headers. Here is a minimal test
case:

All.h:
#include 

test.h:
#include "All.h"

test.cpp:
#include "test.h"
Test::Test()
{
}

g++ -std=gnu++0x -O3 All.h
g++ -std=gnu++0x -O3 test.cpp
test.h:2: error: ‘Test’ has not been declared
test.h:2: error: ISO C++ forbids declaration of ‘Test’ with no type

If I:
- Don't use gnu++0x
- Or don't use -O3
- Or don't precompile All.h
- Or include All.h directly in test.cpp
then I get the expected error message

test.cpp:3: error: ‘Test’ has not been declared
test.cpp:3: error: ISO C++ forbids declaration of ‘Test’ with no type

System: Linux 2.6.32-5-amd64 #1 SMP Tue Jun 1 04:34:03 UTC 2010 x86_64
GNU/Linux

g++ -v -save-temps:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-1)


-- 
   Summary: Wrong filename in error message when using c++0x +
optimised + precompiled headers
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: small_duck at revesdemondes dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44550

[Bug debug/41130] GCC should emit an index of publicly named entities

[tromey at gcc dot gnu dot org]

--- Comment #15 from tromey at gcc dot gnu dot org  2010-06-15 21:51 ---
I think we've decided not to pursue this route.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.5.1
Version|tree-ssa|4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130

[Bug fortran/44549] [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-06-15 21:05 ---
Dominique, thanks for reporting this. I can confirm the error you're seeing and
I already see what's wrong: In 'match_procedure_in_type' the handling of the
gfc_typebound_proc structures is not correct (each procedure in the list gets
the same structure).

Will post a patch shortly.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-15 21:05:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44549

[Bug target/43364] Suboptimal code for the use of ARM NEON intrinsic "vset_lane_f32"

[siarhei dot siamashka at gmail dot com]

--- Comment #4 from siarhei dot siamashka at gmail dot com  2010-06-15 
20:34 ---
(In reply to comment #3)
> Or use multiple alternatives feature for inline assembly constraints to emit 
> either VMOV or VLD1?

Well, this kind of works :) But is very ugly and fragile:

/***/
#include 

/* Override a slow 'vdup_n_f32' intrinsic with something better */

static inline float32x2_t vdup_n_f32_fast(float x)
{
float32x2_t result;
asm (
".set vdup_n_f32_fast_CODE_EMITTED,0\n"
".irp regname,r0,r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,r13,r14\n"
".ifeqs \"\\regname\", \"%1\"\n"
"vdup.32 %P0, %1\n"
".set vdup_n_f32_fast_CODE_EMITTED,1\n"
".endif\n"
".ifeqs \"[\\regname, #0]\", \"%1\"\n"
"vld1.f32 {%P0[]}, [\\regname, :32]\n"
".set vdup_n_f32_fast_CODE_EMITTED,1\n"
".endif\n"
".endr\n"
".if vdup_n_f32_fast_CODE_EMITTED == 0\n"
".error \"Fixme: icky macros from 'vdup_n_f32_fast' failed\"\n"
".endif\n"
: "=w,w" (result) : "r,Q" (x) : "memory");
return result;
}

#define vdup_n_f32(x) vdup_n_f32_fast(x)

/* Now let's test it for accessing data in registers */

float neon_add_regs(float a, float b)
{
float32x2_t tmp1, tmp2;
tmp1 = vdup_n_f32(a);
tmp2 = vdup_n_f32(b);
tmp1 = vadd_f32(tmp1, tmp2);
return vget_lane_f32(tmp1, 0);
}

/* ... and in memory */

void neon_add_mem(float * __restrict out,
  float * __restrict a,
  float * __restrict b)
{
float32x2_t tmp1, tmp2;
tmp1 = vdup_n_f32(*a);
tmp2 = vdup_n_f32(*b);
tmp1 = vadd_f32(tmp1, tmp2);
*out = vget_lane_f32(tmp1, 0);
}
/***/

$ objdump -d test.o

 :
   0:   f4e10c9fvld1.32 {d16[]}, [r1, :32]
   4:   f4e21c9fvld1.32 {d17[]}, [r2, :32]
   8:   f2400da1vadd.f32d16, d16, d17
   c:   f4c0080fvst1.32 {d16[0]}, [r0]
  10:   e12fff1ebx  lr

0014 :
  14:   ee800b90vdup.32 d16, r0
  18:   ee811b90vdup.32 d17, r1
  1c:   f2400da1vadd.f32d16, d16, d17
  20:   ee100b90vmov.32 r0, d16[0]
  24:   e12fff1ebx  lr


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43364

[Bug target/43364] Suboptimal code for the use of ARM NEON intrinsic "vset_lane_f32"

[siarhei dot siamashka at gmail dot com]

--- Comment #3 from siarhei dot siamashka at gmail dot com  2010-06-15 
20:14 ---
The whole point of submitting this PR was to find an efficient way to use NEON
instructions to operate on any arbitrary scalar floating point values in order
to overcome Cortex-A8 VFP Lite inherent slowness (maybe make it transparent via
wrapping it into a C++ class and use operator overloading).

Using 'vdup_n_f32' to load a single floating point value seems to be better
than 'vset_lane_f32' here because we don't have to deal with uninitialized part
of the register. But 'vdup_n_f32' suffers from the similar performance issues
(VLD1 instruction is not used directly) and results in redundant instructions
emitted when the value is loaded from memory. Optimistically, something like
this should have been used instead of 'vdup_n_f32' in this case:

static inline float32x2_t vdup_n_f32_mem(float *p)
{
float32x2_t result;
asm ("vld1.f32 {%P0[]}, [%1, :32]" : "=w" (result) : "r" (p) : "memory");
return result;
}

If wonder if it is possible to check at compile time whether the operand comes
from memory or from a register? Something similar to '__builtin_constant_p'
builtin-function? Or use multiple alternatives feature for inline assembly
constraints to emit either VMOV or VLD1? Anything else?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43364

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2010-06-15 20:10 
---
(In reply to comment #2)
>> Try to change that into a "print *, atan(1.0,  i/10.0)  -atan2(1.0,  i/10.)"
>> and see what it outputs.
> 
> Only changing the first line, I get
> 
>  -4.35482832E-08
> Abort

Changing only the first line, could you compile with -fdump-tree-original and
attach the *.f90.003t.original file that gets generated?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

[Bug fortran/44549] New: [OOP][F2008] Type-bound procedure: bogus error from list after PROCEDURE

[dominiq at lps dot ens dot fr]

After the fix for pr40117 with r160646, the following code (borrowed from
somewhere)

MODULE rational_numbers
  IMPLICIT NONE
  PRIVATE
  TYPE,PUBLIC :: rational
PRIVATE
INTEGER n,d

CONTAINS
! ordinary type-bound procedure
PROCEDURE :: real => rat_to_real
! specific type-bound procedures for generic support
PROCEDURE,PRIVATE :: rat_asgn_i, rat_plus_rat, rat_plus_i
PROCEDURE,PRIVATE,PASS(b) :: i_plus_rat
! generic type-bound procedures
GENERIC :: ASSIGNMENT(=) => rat_asgn_i
GENERIC :: OPERATOR(+) => rat_plus_rat, rat_plus_i, i_plus_rat
  END TYPE
  CONTAINS
ELEMENTAL REAL FUNCTION rat_to_real(this) RESULT(r)
  CLASS(rational),INTENT(IN) :: this
  r = REAL(this%n)/this%d
END FUNCTION

ELEMENTAL SUBROUTINE rat_asgn_i(a,b)
  CLASS(rational),INTENT(OUT) :: a
  INTEGER,INTENT(IN) :: b
  a%n = b
  a%d = 1
END SUBROUTINE

ELEMENTAL TYPE(rational) FUNCTION rat_plus_i(a,b) RESULT(r)
  CLASS(rational),INTENT(IN) :: a
  INTEGER,INTENT(IN) :: b
  r%n = a%n + b*a%d
  r%d = a%d
END FUNCTION

ELEMENTAL TYPE(rational) FUNCTION i_plus_rat(a,b) RESULT(r)
  INTEGER,INTENT(IN) :: a
  CLASS(rational),INTENT(IN) :: b
  r%n = b%n + a*b%d
  r%d = b%d
END FUNCTION

ELEMENTAL TYPE(rational) FUNCTION rat_plus_rat(a,b) RESULT(r)
  CLASS(rational),INTENT(IN) :: a,b
  r%n = a%n*b%d + b%n*a%d
  r%d = a%d*b%d
END FUNCTION
END

gives the following bogus error:


class_test.f90:31.48:

ELEMENTAL TYPE(rational) FUNCTION rat_plus_i(a,b) RESULT(r)
1
Error: Assignment operator interface at (1) must be a SUBROUTINE

and gives an ICE when compiled with -std=f2003


class_test.f90:12.49:

PROCEDURE,PRIVATE :: rat_asgn_i, rat_plus_rat, rat_plus_i
 1
Error: Fortran 2008: PROCEDURE list at (1)
class_test.f90:16.29:

GENERIC :: OPERATOR(+) => rat_plus_rat, rat_plus_i, i_plus_rat
 1
Error: Undefined specific binding 'rat_plus_i' as target of GENERIC '+' at (1)
f951: internal compiler error: Segmentation fault


-- 
   Summary: [OOP][F2008] Type-bound procedure: bogus error from list
after PROCEDURE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: x86_64-apple-darwin10.3.0
  GCC host triplet: x86_64-apple-darwin10.3.0
GCC target triplet: x86_64-apple-darwin10.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44549

[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument

[janus at gcc dot gnu dot org]

--- Comment #12 from janus at gcc dot gnu dot org  2010-06-15 19:41 ---
(In reply to comment #11)
> This gives me a segfault ICE.

... with the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00553b5d in gfc_find_symtree (st=0x41, name=0x77f2de50
"vtype$grid") at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2390
2390  c = strcmp (name, st->name);
(gdb) bt
#0  0x00553b5d in gfc_find_symtree (st=0x41, name=0x77f2de50
"vtype$grid") at /home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2390
#1  0x00553b08 in gfc_delete_symtree (root=0x18081d0,
name=0x77f2de50 "vtype$grid") at
/home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2371
#2  0x00554772 in gfc_undo_symbols () at
/home/jweil/gcc46/trunk/gcc/fortran/symbol.c:2843
#3  0x00515f65 in decode_statement () at
/home/jweil/gcc46/trunk/gcc/fortran/parse.c:271
#4  0x005177be in next_free () at
/home/jweil/gcc46/trunk/gcc/fortran/parse.c:723
#5  0x00517b8e in next_statement () at
/home/jweil/gcc46/trunk/gcc/fortran/parse.c:908
#6  0x0051c190 in gfc_parse_file () at
/home/jweil/gcc46/trunk/gcc/fortran/parse.c:4299


Seems to be related to PR 44064 (or even a duplicate).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051

[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument

[janus at gcc dot gnu dot org]

--- Comment #11 from janus at gcc dot gnu dot org  2010-06-15 19:38 ---
Here is a reduced test case, based on comment #0:

module grid_module
  implicit none 
  type grid
  end type
  type field
type(grid) :: mesh
  end type
contains
  real function return_x(this)
class(grid) :: this
  end function
end module 

module field_module
  use grid_module, only: field,return_x
  implicit none 
contains
  subroutine output(this)
class(field) :: this
print *,return_x(this%mesh)
  end subroutine
end module

end


This gives me a segfault ICE.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051

[Bug tree-optimization/44391] [4.6 Regression] gcc.dg/graphite/id-19.c ICEs at -Os (in build2_stat, at tree.c:3670)

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-06-15 19:13 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391

[Bug tree-optimization/44391] [4.6 Regression] gcc.dg/graphite/id-19.c ICEs at -Os (in build2_stat, at tree.c:3670)

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-06-15 19:12 ---
Subject: Bug 44391

Author: spop
Date: Tue Jun 15 19:11:59 2010
New Revision: 160803

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160803
Log:
Fix PR44391: use size_one_node for pointer types.

2010-06-15  Sebastian Pop  

PR middle-end/44391
* graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Use
size_one_node for pointer types.  Do not call gmp_cst_to_tree.

* gcc.dg/graphite/pr44391.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr44391.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-clast-to-gimple.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391

[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument

[janus at gcc dot gnu dot org]

--- Comment #10 from janus at gcc dot gnu dot org  2010-06-15 19:08 ---
Comment #1 is fixed by r160622, but the original test case still does not work
(hangs in some kind of infinite loop for me, at r160801 on
x86_64-unknown-linux-gnu).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051

[Bug c++/44548] Link error when defining templated static const variable

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-15 19:00 ---
No you just specialized the declaration.
You want:
template
const T MyTraits::kValue; // define it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548

[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2010-06-15 19:00 
---
.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461

[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2010-06-15 18:57 
---
Subject: Bug 42461

Author: ebotcazou
Date: Tue Jun 15 18:56:59 2010
New Revision: 160802

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160802
Log:
Backport from mainline
2010-06-09  Eric Botcazou  

PR rtl-optimization/42461
* dce.c (deletable_insn_p): Return true for const or pure calls again.
* except.c (insn_could_throw_p): Return false if !flag_exceptions.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr42461.c
  - copied unchanged from r160790, trunk/gcc/testsuite/gcc.dg/pr42461.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dce.c
branches/gcc-4_5-branch/gcc/except.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461

[Bug c++/44548] New: Link error when defining templated static const variable

[dpovey at gmail dot com]

Complete code is below [just a few lines].  Note-- bug goes away when I
initialize the variable outside the class, not inside.

qpo...@merlin: ~$ cat temp.cc

template class MyTraits {
 public:
  static const T kValue = 0;
};

template<>
const int MyTraits::kValue; // define it.

int main(){
  const void * a = &(MyTraits::kValue);
}

qpo...@merlin: ~$ g++ temp.cc
/tmp/ccuYrD0D.o: In function `main':
temp.cc:(.text+0x14): undefined reference to `MyTraits::kValue'
collect2: ld returned 1 exit status
qpo...@merlin: ~$ g++ -v
Using built-in specs.
Target: i686-linux
Configured with: ../configure --build=i686-linux --with-arch=nocona
--with-tune=core2 --with-thread=posix --with-as=/usr/local/bin/as
--with-ld=/usr/local/bin/ld --with-system-zlib --program-suffix=-4.3
Thread model: posix
gcc version 4.3.5 (GCC) 
qpo...@merlin: ~$ uname -a
Linux merlin.fit.vutbr.cz 2.6.32.12 #1 SMP Tue Apr 27 15:10:42 CEST 2010 x86_64
x86_64 x86_64 GNU/Linux
qpo...@merlin: ~$


-- 
   Summary: Link error when defining templated static const variable
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpovey at gmail dot com
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548

[Bug c/44547] New: -Wuninitialized reports false warning in nested switch statements

[anthony dot penniston at hotmail dot com]

GCC with -Wuninitialized enabled and -On where n>= 1 will report falsely that a
variable is uninitialized despite having sufficient information to determine
that the variable must necessarily be initialized.

The erroneous warning is:
In function ‘main’:
warning: ‘n’ may be used uninitialized in this function

The output from running "gcc -v -save-temps -Wuninitialized -O1 source-file"
is: 

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 -E -quiet -v test.c -mtune=generic
-Wuninitialized -O1 -fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/include
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -mtune=generic -auxbase test -O1 -Wuninitialized -version -o test.s
GNU C (Debian 4.3.2-1.1) version 4.3.2 (x86_64-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
warning: MPFR header version 2.3.2 differs from library version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3741a6052d20b6389f93b1cc4a619780
test.c: In function ‘main’:
test.c:14: warning: ‘n’ may be used uninitialized in this function
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
 as -V -Qy -o test.o test.s
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.18.0.20080103
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wuninitialized' '-O1' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_x86_64
--hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. test.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o


*note: the output above lists version 4.3.2; however I have tested with the
same effect on gcc version 4.5.0 and have no reason to believe it doesn't exist
in trunk.

The minimal source code example:
// ---
/* GCC bug: -Wuninitialized produces false warning
 * compile with gcc -Wuninitialized -On where n >= 1
 */

int main( int argc, char *argv[] )
{
switch( argc )
{
// note: bug no longer occurs if case values are consective (i.e.
1,2,3)
case 1:
case 2:
case 4:
{
int n;
switch( argc )
{
case 1:
case 2:
case 4:
n = argc;
break;
}

return n;

break;
}
}

return 0;
}

// ---

>From the example above, the first switch limits the value of argc to cases 1,
2, or 4, so that in the second switch statement the compiler should be able to
determine that its value must necessarily be 1,2, or 4 and thus n must
necessarily become 

[Bug fortran/43388] [F2008][OOP] ALLOCATE with MOLD=

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2010-06-15 18:42 ---
Fixed with r160801. Remaining problems are tracked by PR 44541.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43388

[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-06-15 18:40 ---
(In reply to comment #0)
> Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature)


For the MOLD problem we already have a test case in allocate_alloc_opt_10.f90
(which is put behind comments right now, but should be uncommented once this PR
is fixed).


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-15 18:40:31
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541

[Bug fortran/43388] [F2008][OOP] ALLOCATE with MOLD=

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-06-15 18:35 ---
Subject: Bug 43388

Author: janus
Date: Tue Jun 15 18:33:58 2010
New Revision: 160801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160801
Log:
2010-06-15  Janus Weil  

PR fortran/43388
* gfortran.h (gfc_expr): Add new member 'mold'.
* match.c (gfc_match_allocate): Implement the MOLD tag.
* resolve.c (resolve_allocate_expr): Ditto.
* trans-stmt.c (gfc_trans_allocate): Ditto.


2010-06-15  Janus Weil  

PR fortran/43388
* gfortran.dg/allocate_alloc_opt_8.f90: New.
* gfortran.dg/allocate_alloc_opt_9.f90: New.
* gfortran.dg/allocate_alloc_opt_10.f90: New.
* gfortran.dg/class_allocate_2.f03: Modified an error message.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_10.f90
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_8.f90
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_allocate_2.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43388

[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-06-15 18:16 ---
(In reply to comment #5)

> bbro pass is blindly changing:

Ooops, scrap this. Post-reload splitter is splitting in a wrong way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-06-15 18:09 ---
Confirmed.

bbro pass is blindly changing:

(jump_insn 55 57 23 2 pr44546.c:10 (set (pc)
(if_then_else (unle (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:SI 28)
(pc))) 576 {*jcc_1} (expr_list:REG_DEAD (reg:CCFP 17 flags)
(expr_list:REG_BR_PROB (const_int 7929 [0x1ef9])
(nil)))
to

(jump_insn 55 57 28 2 pr44546.c:10 (set (pc)
(if_then_else (gt (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:SI 89)
(pc))) 576 {*jcc_1} (expr_list:REG_DEAD (reg:CCFP 17 flags)
(expr_list:REG_BR_PROB (const_int 2071 [0x817])
(nil)))

This is not valid insn, since GT condition does not satisfy
ix86_trivial_fp_comparison_operator predicate.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

  Known to fail|4.5.0   |4.5.0 4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|4.5 ICE in extract_insn, at |[4.5/4.6 Regression] ICE in
   |recog.c:2103 with -ffast-   |extract_insn, at
   |math -Os (compiling |recog.c:2103 with -ffast-
   |graphviz)   |math -Os (compiling
   ||graphviz)
   Target Milestone|--- |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c/44546] 4.5 ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-06-15 18:07 ---
It is caused by revision 149035:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-15 18:07:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2010-06-15 17:55 ---
We seem to be folding the virtual call to the wrong method.  I'm
investigating...


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-06-14 11:23:28 |2010-06-15 17:55:11
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2010-06-15 17:25 
---
Created an attachment (id=20922)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20922&action=view)
A new patch

Fix typo and update comments.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-06-15 17:20 
---
Created an attachment (id=20921)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20921&action=view)
An updated patch

I don't see why expand_one_stack_var_at should compute alignment
when its callers know what the alignment should be. We just need
to do some sanity check.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #20920|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2010-06-15 17:13 
---
Created an attachment (id=20920)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20920&action=view)
A patch to use alignment

If we already know the alignment we need, why not use it? Here is
a patch does it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-15 17:12 ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159362


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535

[Bug bootstrap/44544] [4.4 Regression] build failure due to lhd_pass_through_t

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-15 16:57 ---
Should be fixed now, sorry.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-06-15 16:45 ---
Re: #c4 - !really_expand never occur when !optimize and for optimize they
are called IMHO way too early (during inlining etc.).

Re: #c8 - the testcases were meant for the given range of svn revs of trunk to
show the issue where expand_one_var is called twice and that forces useless
realignment.  If you want just see too high DECL_ALIGN setting, try:
void
f (long x)
{
  long a, b, c, d;
  asm ("" : : "r" (&a), "r" (&b), "r" (&c), "r" (&d));
  __builtin_alloca (1);
}

at any optimization level on x86_64-linux on the trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug bootstrap/44544] [4.4 Regression] build failure due to lhd_pass_through_t

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-15 16:32 ---
Subject: Bug 44544

Author: jakub
Date: Tue Jun 15 16:32:24 2010
New Revision: 160798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160798
Log:
PR bootstrap/44544
Backport from mainline
2009-09-13  Richard Guenther  
Rafael Avila de Espindola  

* langhooks-def.h (lhd_pass_through_t): Declare.
* langhooks.c (lhd_pass_through_t): New function.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/langhooks-def.h
branches/gcc-4_4-branch/gcc/langhooks.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544

[Bug c/44546] 4.5 ICE with -ffast-math -Os (compiling graphviz)

[chexum at gmail dot com]

--- Comment #3 from chexum at gmail dot com  2010-06-15 16:31 ---
/* minimal source showing (hopefully) the same ICE */
typedef struct { float *ewgts; } vtx_data; 
extern int whatever(vtx_data *);
float *compute_apsp_artifical_weights_packed (vtx_data * graph, int n)
{
  float *weights;

  weights = (float *) zmalloc (n * sizeof (float));
  weights[n] =
whatever(graph) > graph[n].ewgts[n] ?
whatever(graph) : graph[n].ewgts[n];
}

/* gcc -v -save-temps -Os -ffast-math ffmos.c */

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/lto-wrapper
Target: i586-pc-linux-gnu
Configured with: ..//configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --with-system-zlib
--enable-languages=c,c++,objc,java,ada,fortran --enable-threads
--enable-__cxa_atexit --enable-clocale=gnu --enable-libada --enable-shared
--with-ecj-jar=/usr/share/java/ecj.jar i586-pc-linux-gnu
Thread model: posix
gcc version 4.5.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Os' '-ffast-math' '-c'
'-mtune=pentium' '-march=pentium'
 /usr/lib/gcc/i586-pc-linux-gnu/4.5.0/cc1 -E -quiet -v ffmos.c -mtune=pentium
-march=pentium -ffast-math -Os -fpch-preprocess -o ffmos.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/../../../../i586-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i586-pc-linux-gnu/4.5.0/include
 /usr/lib/gcc/i586-pc-linux-gnu/4.5.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Os' '-ffast-math' '-c'
'-mtune=pentium' '-march=pentium'
 /usr/lib/gcc/i586-pc-linux-gnu/4.5.0/cc1 -fpreprocessed ffmos.i -quiet
-dumpbase ffmos.c -mtune=pentium -march=pentium -auxbase ffmos -Os -version
-ffast-math -o ffmos.s
GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922
GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922
Compiler executable checksum: 7fe8daf58b4922cb9313351112738768
ffmos.c: In function ‘compute_apsp_artifical_weights_packed’:
ffmos.c:12:1: error: unrecognizable insn:
(jump_insn 59 58 47 2 ffmos.c:11 (set (pc)
(if_then_else (lt (reg:CCFP 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 45)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 2071 [0x817])
(nil))
 -> 45)
ffmos.c:12:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

chexum at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c/44546] 4.5 ICE with -ffast-math -Os (compiling graphviz)

[chexum at gmail dot com]

--- Comment #2 from chexum at gmail dot com  2010-06-15 16:26 ---
Created an attachment (id=20919)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20919&action=view)
Original compilation log with -v


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c/44546] 4.5 ICE with -ffast-math -Os (compiling graphviz)

[chexum at gmail dot com]

--- Comment #1 from chexum at gmail dot com  2010-06-15 16:26 ---
Created an attachment (id=20918)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20918&action=view)
Original preprocessed source


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug c/44546] New: 4.5 ICE with -ffast-math -Os (compiling graphviz)

[chexum at gmail dot com]

libtool: compile:  gcc -v -save-temps -DHAVE_CONFIG_H -I. -I../.. -I../..
-I../../lib/common -I../../lib/gvc -I../../lib/pack -I../../lib/ortho
-I../../lib/pathplan -I../../lib/graph -I../../lib/sparse -I../../lib/rbtree
-I../../lib/sfdpgen -I../../lib/cdt -Os -Wall -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith
-Wall -ffast-math -MT stress.lo -MD -MP -MF .deps/stress.Tpo -c stress.c  -fPIC
-DPIC -o .libs/stress.o
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-pc-linux-gnu/4.5.0/lto-wrapper
Target: i586-pc-linux-gnu
Configured with: ..//configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --with-system-zlib
--enable-languages=c,c++,objc,java,ada,fortran --enable-threads
--enable-__cxa_atexit --enable-clocale=gnu --enable-libada --enable-shared
--with-ecj-jar=/usr/share/java/ecj.jar i586-pc-linux-gnu
Thread model: posix
gcc version 4.5.0 (GCC)
...
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I../..'
'-I../..' '-I../../lib/common' '-I../../lib/gvc' '-I../../lib/pack'
'-I../../lib/ortho' '-I../../lib/pathplan' '-I../../lib/graph'
'-I../../lib/sparse' '-I../../lib/rbtree' '-I../../lib/sfdpgen'
'-I../../lib/cdt' '-Os' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64'
'-Wno-unknown-pragmas' '-Wstrict-prototypes' '-Wpointer-arith' '-Wall'
'-ffast-math' '-MT' 'stress.lo' '-MD' '-MP' '-MF' '.deps/stress.Tpo' '-c'
'-fPIC' '-DPIC' '-o' '.libs/stress.o' '-mtune=pentium' '-march=pentium'
 /usr/lib/gcc/i586-pc-linux-gnu/4.5.0/cc1 -fpreprocessed stress.i -quiet
-dumpbase stress.c -mtune=pentium -march=pentium -auxbase-strip .libs/stress.o
-Os -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -version
-ffast-math -fPIC -o stress.s
GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922
GNU C (GCC) version 4.5.0 (i586-pc-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127922
Compiler executable checksum: 7fe8daf58b4922cb9313351112738768
stress.c: In function �<80><98>mdsModel�<80><99>:
stress.c:1373:12: warning: �<80><98>delta�<80><99> may be used
uninitialized in this function
stress.c: In function
�<80><98>compute_apsp_artifical_weights_packed�<80><99>:
stress.c:1494:1: error: unrecognizable insn:
(jump_insn 445 444 315 11 stress.c:1454 (set (pc)
(if_then_else (lt (reg:CCFP 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 303)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 2900 [0xb54])
(nil))
 -> 303)
stress.c:1494:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: 4.5 ICE with -ffast-math -Os (compiling graphviz)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chexum at gmail dot com
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug tree-optimization/44545] internal compiler error: in remove_unreachable_handlers, at tree-eh

[gxgjyyozme at zrmshffbt dot mine dot nu]

--- Comment #1 from gxgjyyozme at zrmshffbt dot mine dot nu  2010-06-15 
16:22 ---
Created an attachment (id=20917)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20917&action=view)
Instance of source code which causes crash.

from geany/scintilla


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545

[Bug tree-optimization/44545] New: internal compiler error: in remove_unreachable_handlers, at tree-eh

[gxgjyyozme at zrmshffbt dot mine dot nu]

A combination of options can yield the error:
internal compiler error: in remove_unreachable_handlers, at tree-eh.c

To produce the error, g++ is invoked thus:
g++ -c -pipe --trapv --non-call-exceptions --stack-check -O2

Aside from -pipe and -O2, which can be further decomposed, the options are the
minimal set to produce the error in this case.

Build from 
URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 160774

unset LDFLAGS
export CFLAGS=-pipe
export CXXFLAGS=-pipe
configure --enable-languages=c++
make bootstrap-lean

See attachment for source code of test case.
Taken from geany/scintilla.


-- 
   Summary: internal compiler error: in remove_unreachable_handlers,
at tree-eh
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gxgjyyozme at zrmshffbt dot mine dot nu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545

[Bug tree-optimization/44391] [4.6 Regression] gcc.dg/graphite/id-19.c ICEs at -Os (in build2_stat, at tree.c:3670)

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2010-06-15 16:19 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01519.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391

[Bug bootstrap/44544] [4.4 Regression] build failure due to lhd_pass_through_t

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-15 16:11:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2010-06-15 15:39 ---
(In reply to comment #7)
> Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
> but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
> 

I set the breakpoint at expand_one_stack_var_at and ran
the testcase in gdb. expand_one_stack_var_at wasn't called.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug bootstrap/44544] New: [4.4 Regression] build failure due to lhd_pass_through_t

[hp at gcc dot gnu dot org]

Build passed last with 160755, first failure 160784 as follows, most likely for
all targets:

/bin/sh /tmp/hpautotest-gcc44/gcc/gcc/../move-if-change tmp-gcov-iov.h
gcov-iov.h
echo timestamp > s-iov
gcc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute   -DHAVE_CONFIG_H -I. -I.
-I/tmp/hpautotest-gcc44/gcc/gcc -I/tmp/hpautotest-gcc44/gcc/gcc/.
-I/tmp/hpautotest-gcc44/gcc/gcc/../include
-I/tmp/hpautotest-gcc44/gcc/gcc/../libcpp/include
-I/tmp/hpautotest-gcc44/cris-elf/gccobj/./gmp -I/tmp/hpautotest-gcc44/gcc/gmp
-I/tmp/hpautotest-gcc44/cris-elf/gccobj/./mpfr -I/tmp/hpautotest-gcc44/gcc/mpfr
 -I/tmp/hpautotest-gcc44/gcc/gcc/../libdecnumber
-I/tmp/hpautotest-gcc44/gcc/gcc/../libdecnumber/dpd -I../libdecnumber   
/tmp/hpautotest-gcc44/gcc/gcc/c-lang.c -o c-lang.o
/tmp/hpautotest-gcc44/gcc/gcc/c-lang.c:49: error: 'lhd_pass_through_t'
undeclared here (not in a function)

There's no lhd_pass_through_t in 4.4 and the patch didn't add one.

Author of suspect patch CC:ed.


-- 
   Summary: [4.4 Regression] build failure due to lhd_pass_through_t
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44544

[Bug c/44543] moving static keyword causes compilation to fail

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-06-15 15:28 ---
This is due to C's complex declarator syntax, where the "*" is associated with
the identifier "f" not the return type.  You would need to say:

char static *f()


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44543

[Bug c++/44328] switch/case optimization produces an invalid lookup table index

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2010-06-15 15:08 ---
Unfortunately I don't see this happening on the x86_64-linux ->
arm-linux-gnueabi cross compiler I built for myself.  The generated
assembly has all four elements in the initialization of CSWTCH.2 and
the intermediate tree dumps from the cross compiler are not really
different from the ones from a native x86_64 compiler.

Could you please first try to reproduce the bug with the
-fno-tree-switch-conversion swithch?  If that helps, the bug is indeed
in the lookup table generation and then I would like you to provide
the dump files generated by switches -fdump-tree-tailr1-slim
-fdump-tree-switchconv  

It would be great if you could do that with a gcc (4.5 or trunk)
patched with the following hunk but maybe we will be able to see
something interesting even without it.

Thanks.


Index: gcc/tree-switch-conversion.c
===
--- gcc/tree-switch-conversion.c(revision 160709)
+++ gcc/tree-switch-conversion.c(working copy)
@@ -517,6 +517,13 @@
   array_type = build_array_type (value_type, arr_index_type);
   ctor = build_constructor (array_type, info.constructors[num]);
   TREE_CONSTANT (ctor) = true;
+  if (dump_file)
+   {
+ fprintf (dump_file, "\n\nCONSTRUCTOR %i:\n", num);
+ 
+ print_node (dump_file, "", ctor, 0);
+ fprintf (dump_file, "\n");
+   }

   decl = build_decl (loc, VAR_DECL, NULL_TREE, array_type);
   TREE_STATIC (decl) = 1;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug c/44543] New: moving static keyword causes compilation to fail

[todd dot freed at gmail dot com]

Hello,

consider the following two declarations, which compile fine

static char f();
static char* f();

Then, if I move the 'static' keyword, like so:

char static f();
char* static f();

The first one still compiles, but the second one fails like this:

error.c:1: error: expected identifier or '(' before 'static'

I think this is a bug because if I use a non-pointer return type, like char or
int, it works fine. But if I use a pointer return type, like char* or void*, I
get the compiler error, depending on whether static is the first or second
word. Additionally, if I typedef char* charstar, and return that instead, it
works fine.

So, the file I am compiling is a one-liner, named error.c

char* static f();

using this command:

gcc error.c -c

Here's what I get from gcc -v

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.3/configure --host=i686-pc-linux-gnu
--build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --localstatedir=/var
--libexecdir=/usr/lib --sharedstatedir=/usr/com --mandir=/usr/man
--infodir=/usr/info --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu
--enable-languages=c,c++ --disable-libstdcxx-pch --program-suffix=-4.3.3
--disable-nls
Thread model: posix
gcc version 4.3.3 (GCC for Cross-LFS 4.3.3.20090323)


-- 
   Summary: moving static keyword causes compilation to fail
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: todd dot freed at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44543

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[matz at gcc dot gnu dot org]

--- Comment #7 from matz at gcc dot gnu dot org  2010-06-15 14:56 ---
Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-06-15 14:46 ---
I watched crtl->stack_alignment_estimated in gdb
with the testcase in comment #2. I didn't see it
set to 256.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

gcc

[icegood]

Under 
gcc version 4.3.2 (Debian 4.3.2-1.1) 
and 
cc version 4.3.4 20090804 (release) 1 (GCC) Target: i686-pc-cygwin
i obtained same result after testing  features from tutorial 
http://www.cplusplus.com/doc/tutorial/typecasting/ there :

http://old.nabble.com/file/p28892128/tutor.cpp tutor.cpp 

After "g++ tutor.cpp" on both debian and cygwin i obtained same result:

a is: P5CBase 
b is: P5CBase 
c is: P5CBase 
*a is: 5CBase 
*b is: 8CDerived 
*c is: 8CDerived


-- 
View this message in context: 
http://old.nabble.com/gcc-%3Ctypeinfo%3E-tp28892128p28892128.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-15 
14:09 ---
Subject: Re:  32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

> --- Comment #1 from fxcoudert at gcc dot gnu dot org  2010-06-11 13:51 
> ---
>>   if(atan(1.0,  i/10.0)  -atan2(1.0,  i/10.)/= 0.0)   call abort()
>
> Try to change that into a "print *, atan(1.0,  i/10.0)  -atan2(1.0,  i/10.)"
> and see what it outputs.

Only changing the first line, I get

 -4.35482832E-08
Abort

Changing the second line, too, gives

 -4.35482832E-08
 -1.08094956596804792E-016
  4.33012666E-08
  4.38017677684143791E-017
  3.05452623E-08
  3.33934269125535366E-017
  2.96684455E-08
 -5.7679762288359E-017
  4.87235496E-08
 -9.40003283544932344E-017
 -1.70394934E-08
  2.55871712706579046E-017
  1.22149613E-09
 -3.88144377749810587E-017
  2.30690667E-08
 -2.16840434497100887E-018
 -1.41206291E-08
 -8.18572640226555848E-018
  2.18556941E-08
 -3.06287113727155003E-017

Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2010-06-15 13:50 ---
Oh, and yes, I agree that in expand_one_stack_var_at (only called when
really_expand == true) we should limit align to $something.  I'm just not
sure what $something is.  crtl->stack_alignment_estimated is not really it,
because that one itself is adjusted by expand_stack_alignment (running after
all expansion).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-06-15 13:40 ---
Can you try to instead do the stack-estimation only when really_expand is
false?  The issue is, we see all variables (or we _should_ see) exactly twice,
once for estimation, once for generating the DECL_RTL.  The code was so
twisted that I didn't want to touch it too much during expand-from-ssa, but
I planned to return to that somewhen, hence I'm not sure if we really see
each variable only twice.  But we should be working towards that goal.

In any case it should be fine to track crtl->stack_alignment_estimated only
in the first pass (really_expand == false), and never touch it again in
the second pass (really_expand == true).  Then you should also be able
to simplify the condition.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2010-06-15 
13:15 ---
Subject: Re:  [4.5/4.6 Regression] FAIL:
gcc.dg/tree-ssa/20031015-1.c (internal compiler error)

Attached .i.

Dave


--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2010-06-15 
13:15 ---
Created an attachment (id=20915)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20915&action=view)


--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2010-06-15 
13:15 ---
Created an attachment (id=20916)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20916&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-15 12:53 ---
Created an attachment (id=20914)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20914&action=view)
gcc46-pr44542.patch

For the "don't use changed DECL_ALIGN for stack estimation after
expand_one_stack_var_at has been called" subprogram we can do something like
this.

For the other issue, I wonder if we couldn't limit align in
expand_one_stack_var_at to minimum of MAX_SUPPORTED_STACK_ALIGNMENT
and crtl->stack_alignment_estimated or something similar.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug middle-end/44536] OMP: missing error with default(none)

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-06-15 12:49 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536

[Bug middle-end/44536] OMP: missing error with default(none)

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-15 12:27 ---
Subject: Bug 44536

Author: jakub
Date: Tue Jun 15 12:27:01 2010
New Revision: 160783

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160783
Log:
PR fortran/44536
* langhooks.h (struct lang_hooks_for_decls): Add omp_report_decl.
* langhooks-def.h (LANG_HOOKS_OMP_REPORT_DECL): Define.
(LANG_HOOKS_DECLS): Add it.
* gimplify.c (omp_notice_variable): Call
lang_hooks.decls.omp_report_decl.

* trans-openmp.c (gfc_omp_predetermined_sharing): Don't return
OMP_CLAUSE_DEFAULT_SHARED for artificial vars with
GFC_DECL_SAVED_DESCRIPTOR set.
(gfc_omp_report_decl): New function.
* trans.h (gfc_omp_report_decl): New prototype.
* f95-lang.c (LANG_HOOKS_OMP_REPORT_DECL): Redefine.

* gfortran.dg/gomp/pr44536.f90: New test.
* gfortran.dg/gomp/sharing-3.f90: Remove xfail.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr44536.f90
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/f95-lang.c
branches/gcc-4_4-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_4-branch/gcc/fortran/trans.h
branches/gcc-4_4-branch/gcc/gimplify.c
branches/gcc-4_4-branch/gcc/langhooks-def.h
branches/gcc-4_4-branch/gcc/langhooks.h
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536

[Bug middle-end/44536] OMP: missing error with default(none)

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-15 12:17 ---
Subject: Bug 44536

Author: jakub
Date: Tue Jun 15 12:17:16 2010
New Revision: 160780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160780
Log:
PR fortran/44536
* langhooks.h (struct lang_hooks_for_decls): Add omp_report_decl.
* langhooks-def.h (LANG_HOOKS_OMP_REPORT_DECL): Define.
(LANG_HOOKS_DECLS): Add it.
* gimplify.c (omp_notice_variable): Call
lang_hooks.decls.omp_report_decl.

* trans-openmp.c (gfc_omp_predetermined_sharing): Don't return
OMP_CLAUSE_DEFAULT_SHARED for artificial vars with
GFC_DECL_SAVED_DESCRIPTOR set.
(gfc_omp_report_decl): New function.
* trans.h (gfc_omp_report_decl): New prototype.
* f95-lang.c (LANG_HOOKS_OMP_REPORT_DECL): Redefine.

* gfortran.dg/gomp/pr44536.f90: New test.
* gfortran.dg/gomp/sharing-3.f90: Remove xfail.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44536.f90
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/f95-lang.c
branches/gcc-4_5-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_5-branch/gcc/fortran/trans.h
branches/gcc-4_5-branch/gcc/gimplify.c
branches/gcc-4_5-branch/gcc/langhooks-def.h
branches/gcc-4_5-branch/gcc/langhooks.h
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536

[Bug middle-end/44536] OMP: missing error with default(none)

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-15 12:15 ---
Subject: Bug 44536

Author: jakub
Date: Tue Jun 15 12:15:26 2010
New Revision: 160779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160779
Log:
PR fortran/44536
* langhooks.h (struct lang_hooks_for_decls): Add omp_report_decl.
* langhooks-def.h (LANG_HOOKS_OMP_REPORT_DECL): Define.
(LANG_HOOKS_DECLS): Add it.
* gimplify.c (omp_notice_variable): Call
lang_hooks.decls.omp_report_decl.

* trans-openmp.c (gfc_omp_predetermined_sharing): Don't return
OMP_CLAUSE_DEFAULT_SHARED for artificial vars with
GFC_DECL_SAVED_DESCRIPTOR set.
(gfc_omp_report_decl): New function.
* trans.h (gfc_omp_report_decl): New prototype.
* f95-lang.c (LANG_HOOKS_OMP_REPORT_DECL): Redefine.

* gfortran.dg/gomp/pr44536.f90: New test.
* gfortran.dg/gomp/sharing-3.f90: Remove xfail.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr44536.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/fortran/trans.h
trunk/gcc/gimplify.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/gomp/sharing-3.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-15 11:36 ---
I don't have any wrong-code testcases.
__attribute__((noinline, noclone)) void
f (long x)
{
  long a, b, c, d;
  asm ("");
  __builtin_alloca (1);
}

int
main (void)
{
  f (1234567890);
  return 0;
}

shows the same issue at -O0 -g as I see on redhat/gcc-4_4-branch on the trunk
between r145138 (which I've backported to 4.4-RH, perhaps I'll need to back it
out) and r146817 (SSA expand).  In between those two commits the trunk first
sets DECL_ALIGN to 256 bits on one of the variables (as offset 32 gives and is
still smaller or equal to MAX_SUPPORTED_STACK_ALIGNMENT) and then
expand_stack_var is called on it again and bumps
crtl->stack_alignment_estimated
to 256 (something that isn't really needed).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

[matz at gcc dot gnu dot org]

--- Comment #1 from matz at gcc dot gnu dot org  2010-06-15 11:19 ---
We have a slightly problematic ordering issue here.  Here's what I
think should be made the case:
  DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that.
  (and for calculating offsets from stack-ptr we can calculate the
   alignment directly)

If that were the case already we wouldn't have the problem of having to
maintain DECL_ALIGN.  Of course the problem is, that MEM_ALIGN is actually
generated from DECL_ALIGN during expansion itself.  It follows that it
actually wouldn't help at all to fixup only DECL_ALIGN after the final
stack alignment is known.  We would also have to walk all RTL and fixup
MEM_ALIGN too (in possibly non-obvious ways).  If we wouldn't do that
but start with minimal DECL_ALIGN we have only managed to produce very
suboptimal code.  On some architecture even so unoptimal as to use unaligned
instructions were aligned ones would be possible.  And we wouldn't necessarily
be able to fixup _that_ after the fact.

Now, the mentioned ordering problem is, that we align the stack only after
all instructions are converted (and hence all stack-vars are expanded).  We
can't do it before, because the necessity for stack-alignment depends on
the actually emitted stack-vars.  And doing it afterwards will lead to the 
need for walking all instructions again, fixing DECL_ALIGN and MEM_ALIGN
(and changing instructions to use more optimal versions of the alignment
now is somehow better).

I think the only correct way is for expand_stack_alignment to align the
stack exactly so that all DECL_ALIGN and MEM_ALIGN entries are correct.
In other words I think it would be a bug for expand_stack_alignment to
generate an actual stack alignment that would lessen the alignment of
stack vars.

To that effect I think I'd rather want to see a reproducer for 4.5/4.6
and fix the bug in expand_stack_alignment (possibly in the target hooks)
than trying to fiddle with the insn chain.

Weren't there some DRAP fixes after 4.4?  I seem to remember some patches
flying by at that time-frame.  Perhaps you can also create a reproducer
for 4.5 just before expand-from-ssa?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug lto/44464] ICE during linux kernel whopr build

[jamborm at gcc dot gnu dot org]

--- Comment #20 from jamborm at gcc dot gnu dot org  2010-06-15 11:09 
---
Subject: Bug 44464

Author: jamborm
Date: Tue Jun 15 11:09:12 2010
New Revision: 160777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160777
Log:
2010-06-15  Martin Jambor  

PR lto/44464
* tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name
on the newly dead SSA name.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-sra.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464

[Bug target/44542] New: expand_one_stack_var_at may set DECL_ALIGN to a too high value

[jakub at gcc dot gnu dot org]

On say -O0:
void foo (long x)
{
  long a, b, c, d;
  __builtin_alloca (1);
}

some of the variables get much higher DECL_ALIGN than they in the end really
have.  I don't have a testcase which shows miscompilation on the trunk, still
it seems to be a latent bug.  IMHO it should instead set DECL_ALIGN to the
maximum of requested DECL_ALIGN and alignment from offset for minimum possible
stack alignment and only after expansion when it is finalized what stack
alignment it will have it can be increased if needed.  On 4.4-RH I've run into
another issue (perhaps also latent on the trunk) - if expand_stack_var is
called twice on the same variable, the first time it is given a stack slot and
DECL_ALIGN set to a very high number (e.g. for offset 32 it is 256 bits) and
next time the function doesn't do almost anything (DECL_RTL_SET_P is true),
except for increasing requested alignment to the given one, so it ends up
wanting to realign the stack.


-- 
   Summary: expand_one_stack_var_at may set DECL_ALIGN to a too high
value
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542

[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization

[siarhei dot siamashka at gmail dot com]

--- Comment #4 from siarhei dot siamashka at gmail dot com  2010-06-15 
10:34 ---
Created an attachment (id=20913)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20913&action=view)
a fixed testcase

A fixed testcase attached.

The main problem here is that denormals are not handled in a 'civilized' way by
gcc at the moment. They are just silently and unconditionally treated in a
relaxed way, and that might be neither wanted nor expected by the user. And
'readelf -A' shows the following EABI tags for the generated object file, even
not marking it in a special way with the regards to denormals handling:
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703

[Bug tree-optimization/44258] [4.5 Regression] possible SRA wrong-code generation.

[jamborm at gcc dot gnu dot org]

--- Comment #16 from jamborm at gcc dot gnu dot org  2010-06-15 10:05 
---
This is now fixed on both the trunk and the 4.5 branch.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258

[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA

[jamborm at gcc dot gnu dot org]

--- Comment #19 from jamborm at gcc dot gnu dot org  2010-06-15 10:04 
---
This is now fixed on both the trunk and the 4.5 branch.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423

[Bug tree-optimization/44258] [4.5 Regression] possible SRA wrong-code generation.

[jamborm at gcc dot gnu dot org]

--- Comment #15 from jamborm at gcc dot gnu dot org  2010-06-15 10:03 
---
Subject: Bug 44258

Author: jamborm
Date: Tue Jun 15 10:03:35 2010
New Revision: 160776

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160776
Log:
2010-06-15  Martin Jambor  

PR tree-optimization/44258
* tree-sra.c (build_access_subtree): Return false iff there is a
partial overlap.
(build_access_trees): Likewise.
(analyze_all_variable_accesses): Disqualify candidates if
build_access_trees returns true for them.

* testsuite/gcc.dg/tree-ssa/pr44258.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr44258.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258

[Bug bootstrap/44458] [4.6 Regression] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2010-06-15 09:58 ---
Reverting Steven patch with your fix is enough to get back bootstrap:

http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01497.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458

[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA

[jamborm at gcc dot gnu dot org]

--- Comment #18 from jamborm at gcc dot gnu dot org  2010-06-15 09:48 
---
Subject: Bug 44423

Author: jamborm
Date: Tue Jun 15 09:48:39 2010
New Revision: 160775

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160775
Log:
2010-06-15  Martin Jambor  

PR tree-optimization/44423
* tree-sra.c (dump_access): Dump also grp_assignment_read.
(analyze_access_subtree): Pass negative allow_replacements to children
if the current type is scalar.

* testsuite/gcc.dg/tree-ssa/pr44423.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr44423.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423

[Bug fortran/44529] [F03] array allocation with SOURCE

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2010-06-15 09:39:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44529

[Bug fortran/44541] New: [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD

[burnus at gcc dot gnu dot org]

Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature), but it also
applies to polymorphic variables with INTENT(OUT) (i.e. to F2003).

In either cases, a potentially existing default initializer of the *effective
type* needs to be applied. That means that this data has to be available in the
vtable.

See also: http://j3-fortran.org/pipermail/j3/2010-June/003621.html

(Thanks to Janus for spotting the problem (for MOLD) at the first place; thanks
to Bill Long for confirmation and mentioning INTENT(OUT); and to Aleksandar
Donev for the comments.)

Testing shows that other vendors have also overlooked these cases.
(For intent out, there seem to be compiler which do not set the variable at all
(e.g. gfortran) or those which only use the base type for the initialization;
similarly, for MOLD where unspecified initialization happens (via malloc),
possibly with base-type initialization on top.)

-- INTENT(OUT) test case -
! Expected: a= 1  b= 3
  implicit none
  type t
integer :: a = 1
  end type t
  type, extends(t) :: t2
integer :: b = 3
  end type t2

  type(t2) :: y
  y%a = 44
  y%b = 55
  call intent_out (y)
  print *, 'a=', y%a, ' b=', y%b
contains
  subroutine intent_out(x)
class(t), intent(out) :: x
select type (x)
  type is (t2)
  print *, 'a=', x%a, ' b=', x%b
end select
  end subroutine
end

-- MOLD test case 
! Expected:
!  a= 1  b= 3
! (Wrong is "a= 1  b= 0" or "a= 0  b= 0" or garbage)
implicit none
type t
  integer :: a = 1
end type t

type, extends(t) :: t2
  integer :: b = 3
end type t2

class(t), allocatable :: x, y

allocate (t2 :: y)
select type (y)
  type is (t2)
y%a = 44
y%b = 55
end select

allocate ( x, mold=y)
select type (x)
  type is (t2)
   print *, 'a=', x%a, ' b=', x%b
end select
end


-- 
   Summary: [OOP] wrong code for polymorphic variable with
INTENT(OUT)/Alloc w/ MOLD
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 43388


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541

[Bug c++/44540] [4.6 Regression] ICE: in add_substitution, at cp/mangle.c:386 with -fkeep-inline-functions

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-06-15 07:28 ---
Created an attachment (id=20912)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20912&action=view)
reduced testcase, -fkeep-inline-functions is not needed there

As the original testcase, this ICEs only in 4.6 too:
$ /mnt/svn/gcc-trunk/binary-160687-lto-fortran-checking-yes-rtl/bin/g++
pr44540.C
pr44540.C: In function 'void foo()':
pr44540.C:3:6: internal compiler error: in add_substitution, at cp/mangle.c:386

However, in 4.5 and 4.4 (both with checking enabled), the symbol might be
mangled wrongly - the "volatile" looks superfluous. It seems to be caused by
the "noreturn" attribute.

$ /mnt/svn/gcc-4_5/binary-160526-lto-fortran-checking-yes-rtl/bin/g++ pr44540.C
/usr/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/tmp/ccCkV1Jt.o: In function `foo()':
pr44540.C:(.text+0x5): undefined reference to `baz(char const*, ...)'
pr44540.C:(.text+0xa): undefined reference to `bar(void ( volatile*)(char
const*, ...))'
collect2: ld returned 1 exit status

4.6 shows the same message (including "volatile") when the "printf" attribute
is removed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44540