[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu dot org]

--- Comment #18 from mikael at gcc dot gnu dot org  2010-06-26 09:06 ---
(In reply to comment #17)
> The reason for the failures with entry_* is
> 
> [macbook] f90/bug% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/entry_10.f90
> f951(52154) malloc: *** error for object 0x1419161b0: pointer being freed was
> not allocated
> *** set a breakpoint in malloc_error_break to debug
> f951: internal compiler error: Abort trap
I will look into these. 

> 
> For the transpose test the runtime error is
> 
> At line 16 of file /opt/gcc/_clean/gcc/testsuite/gfortran.dg/transpose_2.f90
> Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (3/2)
> 
> instead of 
> 
> Fortran runtime error: Incorrect extent in return value of TRANSPOSE intrinsic
> in dimension 1: is 2, should be 3
I get these too, but the difference is just because the shape mismatch is now
caught by the scalarizer instead of the libgfortran.

> 
> I have also a dozen ICEs in my favorite can of worms, for instance with
> 
> 
> 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
> 
> 
> [macbook] f90/bug% gfc pr42051_3.f90
> pr42051_3.f90:21:0: internal compiler error: Segmentation fault
> Please submit a full bug report,
> 
I will have a look too.


Thanks for testing.
There are probably some other regressions still uncaught. 
I will have to do a full valgrind-testing-enabled testsuite run at some point.
:-(


-- 


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

[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2010-06-26 09:18 ---
Subject: Re:  [4.6 Regression]
 c-c++-common/torture/complex-sign-add.c

On Fri, 25 Jun 2010, sje at cup dot hp dot com wrote:

> --- Comment #5 from sje at cup dot hp dot com  2010-06-25 22:47 ---
> I verified that this works in r160902 and fails in 160903.

Thanks for further investigating.

> In 160902 I get this (partial) psuedo-code:
> 
>   IMAGPART_EXPR  = 0.0;
>   D.1749_4 = -0.0;
>   IMAGPART_EXPR  = D.1749_4;
>   D.1760_12 = IMAGPART_EXPR ;
>   D.1762_14 = IMAGPART_EXPR ;
>   D.1764_16 = D.1760_12 + D.1762_14;
>   IMAGPART_EXPR  = D.1764_16;
>   D.1754_9 = IMAGPART_EXPR ;
>   D.1755_10 = (double) D.1754_9;
>   printf (&"%f\n"[0], D.1755_10);
> 
> In 160903 I get:
> 
>   b1$imag_4 = -0.0;
>   c1$imag_10 = b1$imag_4 + 0.0;
>   D.1749_7 = c1$imag_10;
>   D.1750_8 = (double) D.1749_7;
>   printf (&"%f\n"[0], D.1750_8);
> 
> I am not sure if it is significant that in the first one I have:
> 
> D.1764_16  = 0.0 + (- 0.0)
> 
> and in the second one I have:
> 
> c1$imag_10 = (- 0.0) + 0.0
> 
> I.e. the order of the -0.0 is different.

Even floating-point addition is commutative.  The difference
is because we canonicalize 0.0 + b1$imag_4 to have the
constant in 2nd place.

> Looking at the assembly code in 160902 I see (paraphrasing):
> 
>  fmov f8 = f0
>  fneg f6 = f0
>  fadd.s f6 = f8, f6
> 
> and in 160903 I see:
> 
>  fneg f6 = f0
>  fadd.s f6 = f6, f0

I suppose f0 is a special register for 0.0?  Googling around
finds me references that f0 is treated specially wrt zero
signs at least when used in fmadd operations.

> Changing the new code by hand to swap the arguments to fadd around does
> seem to fix things in the new code.  But, oddly enough, if I swap the
> arguments around in the old (good) code it doesn't break, I am not sure why.

Which would hint at this is exactly the problem.

Thus, with -fsigned-zeros we cannot use the f0 register in
arithmetic but have to copy it to a regular register first?

So, does

   fneg f6 = f0
   fmov f8 = f0
   fadd.s f6 = f6, f8

work?

Richard.


-- 


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

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-26 09:28 ---
Another way would probably be to ensure that f0 always appears as first operand
by adjusting the various patterns in ia64.md to only allow fr_reg_operand
in the 2nd operand slot of addsf3 (and maybe other patterns).

At least the *maddsf4 pattern incorrectly allows fr_reg_or_fp01_operand
for the third operand which is not correct if signed zeros are supported.

HJ, can you investigate?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |target


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

[Bug fortran/44678] New: ICE with -fdump-parse-tree and select type

[tkoenig at gcc dot gnu dot org]

$ gfortran -fdump-parse-tree select_type_1.f03

...

Interner Fehler bei (1):
show_code_node(): Bad statement code


-- 
   Summary: ICE with -fdump-parse-tree and select type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-26 10:05 ---
Testcase which should fail at all optimization levels
(assuming that fadd.s f4, f0 is internally going through the
mac unit as fmac.s f4, f1, f0)

float __attribute__((noinline))
foo (float x)
{
  float y = x + 0.0;
  return __builtin_copysignf (1.0, y);
}
int main()
{
  if (foo (-0.0) != 1.0)
__builtin_abort ();
  return 0;
}


-- 


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

[Bug libstdc++/44679] New: [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)

[doko at ubuntu dot com]

building 30_threads/condition_variable_any/cons/1.cc with the 4.4 branch

g++ -fstack-protector -std=c++0x any.cc -o any

and running the binary on a system with the shared libstdc++.so installed from
the 4.5 branch aborts.

#include 
#include 

int main()
{
  bool test __attribute__((unused)) = true;

  try 
{
  std::condition_variable_any c1;
}
  catch (const std::system_error& e)
{
  perror("system_error");
  exit(1);
}
  catch (...)
{
  perror("system_error");
  exit(2);
}

  return 0;
}


*** stack smashing detected ***: ./any terminated
=== Backtrace: =
/lib/libc.so.6(__fortify_fail+0x37)[0x7fae2e3c3947]
/lib/libc.so.6(__fortify_fail+0x0)[0x7fae2e3c3910]
./any[0x4009b7]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7fae2e2e2d8d]
./any[0x400839]
=== Memory map: 
0040-00401000 r-xp  09:01 8172845   
/scratch/packages/gcc/4.4/u/any
0060-00601000 rw-p  09:01 8172845   
/scratch/packages/gcc/4.4/u/any
00748000-00769000 rw-p  00:00 0  [heap]
7fae2e2c4000-7fae2e43e000 r-xp  09:00 919600
/lib/libc-2.12.so
7fae2e43e000-7fae2e63e000 ---p 0017a000 09:00 919600
/lib/libc-2.12.so
7fae2e63e000-7fae2e642000 r--p 0017a000 09:00 919600
/lib/libc-2.12.so
7fae2e642000-7fae2e643000 rw-p 0017e000 09:00 919600
/lib/libc-2.12.so
7fae2e643000-7fae2e648000 rw-p  00:00 0
7fae2e648000-7fae2e65d000 r-xp  09:00 2888799   
/usr/lib/gcc-snapshot/lib/libgcc_s.so.1
7fae2e65d000-7fae2e85c000 ---p 00015000 09:00 2888799   
/usr/lib/gcc-snapshot/lib/libgcc_s.so.1
7fae2e85c000-7fae2e85d000 rw-p 00014000 09:00 2888799   
/usr/lib/gcc-snapshot/lib/libgcc_s.so.1
7fae2e85d000-7fae2e8df000 r-xp  09:00 922106
/lib/libm-2.12.so
7fae2e8df000-7fae2eade000 ---p 00082000 09:00 922106
/lib/libm-2.12.so
7fae2eade000-7fae2eadf000 r--p 00081000 09:00 922106
/lib/libm-2.12.so
7fae2eadf000-7fae2eae rw-p 00082000 09:00 922106
/lib/libm-2.12.so
7fae2eae-7fae2ebc4000 r-xp  09:00 2888785   
/usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.15
7fae2ebc4000-7fae2edc3000 ---p 000e4000 09:00 2888785   
/usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.15
7fae2edc3000-7fae2edcb000 r--p 000e3000 09:00 2888785   
/usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.15
7fae2edcb000-7fae2edcd000 rw-p 000eb000 09:00 2888785   
/usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.15
7fae2edcd000-7fae2ede2000 rw-p  00:00 0
7fae2ede2000-7fae2ee03000 r-xp  09:00 918062
/lib/ld-2.12.so
7fae2eff3000-7fae2eff8000 rw-p  00:00 0
7fae2f00-7fae2f002000 rw-p  00:00 0
7fae2f002000-7fae2f003000 r--p 0002 09:00 918062
/lib/ld-2.12.so
7fae2f003000-7fae2f004000 rw-p 00021000 09:00 918062
/lib/ld-2.12.so
7fae2f004000-7fae2f005000 rw-p  00:00 0
7fff0acec000-7fff0ad01000 rw-p  00:00 0 
[stack]
7fff0ad9f000-7fff0ada r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0 
[vsyscall]
Aborted


-- 
   Summary: [4.5/4.6 regression]
30_threads/condition_variable_any/cons/1.cc fails with -
fstack-protector (built with 4.4, run with 4.5)
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

[amylaar at gcc dot gnu dot org]

--- Comment #7 from amylaar at gcc dot gnu dot org  2010-06-26 10:22 ---
The patches have been tested & posted to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02492.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02452.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02495.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02618.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02645.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02649.html


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[redi at gcc dot gnu dot org]

--- Comment #10 from redi at gcc dot gnu dot org  2010-06-26 10:26 ---
I disagree that it would be useful, it would encourage non-portable code, and
I'd rather be told about the missing definition.


-- 


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

[Bug libstdc++/44680] New: [4.5/4.6 regression] regex_traits/char/value.cc built with 4.4, run with 4.5's libstdc++ fails

[doko at ubuntu dot com]

the binary built with 4.4 and run with 4.5's libstdc++ shared library fails:

#include 
# include 
# define VERIFY(fn) assert(fn)

// Tests the value() function of the regex_traits class.
void test01()
{
  bool test __attribute__((unused)) = true;
  std::tr1::regex_traits t;
  VERIFY( t.value('7', 8)  == 7 );
  VERIFY( t.value('7', 10) == 7 );
  VERIFY( t.value('7', 16) == 7 );
  VERIFY( t.value('9', 8)  == -1 );
  VERIFY( t.value('9', 10) == 9 );
  VERIFY( t.value('9', 16) == 9 );
  VERIFY( t.value('d', 8)  == -1 );
  VERIFY( t.value('d', 10) == -1 );
  VERIFY( t.value('d', 16) == 13 );
}

int
main()
{ 
  test01();
  return 0;
};


FAIL: tr1/7_regular_expressions/regex_traits/char/value.cc execution test

value.exe:
/scratch/packages/gcc/4.4/u/gcc-4.4-4.4.4/src/libstdc++-v3/testsuite/tr1/7_regular_expressions/
regex_traits/char/value.cc:35: void test01(): Assertion `t.value('9', 8) == -1'
failed.

FAIL: tr1/7_regular_expressions/regex_traits/wchar_t/value.cc execution test

value.exe:
/scratch/packages/gcc/4.4/u/gcc-4.4-4.4.4/src/libstdc++-v3/testsuite/tr1/7_regular_expressions/
regex_traits/wchar_t/value.cc:35: void test01(): Assertion `t.value('9', 8) ==
-1' failed.


-- 
   Summary: [4.5/4.6 regression] regex_traits/char/value.cc built
with 4.4, run with 4.5's libstdc++ fails
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[redi at gcc dot gnu dot org]

--- Comment #11 from redi at gcc dot gnu dot org  2010-06-26 10:33 ---
[class.static.data]/3
If a static data member is of const literal type, its declaration in the class
definition can specify a brace-or-equal-initializer ... The member shall
still be defined in a namespace scope if it is used in the program and
the namespace scope definition shall not contain an initializer.

[basic.def.odr] explains what "used" means.

The code is invalid, I don't think it does users a service to accept it.


-- 


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[manu at gcc dot gnu dot org]

--- Comment #12 from manu at gcc dot gnu dot org  2010-06-26 10:35 ---
(In reply to comment #11)
> [class.static.data]/3
> If a static data member is of const literal type, its declaration in the class
> definition can specify a brace-or-equal-initializer ... The member shall
> still be defined in a namespace scope if it is used in the program and
> the namespace scope definition shall not contain an initializer.
> 
> [basic.def.odr] explains what "used" means.
> 
> The code is invalid, I don't think it does users a service to accept it.

So is g++ accepting invalid code?


-- 


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[redi at gcc dot gnu dot org]

--- Comment #13 from redi at gcc dot gnu dot org  2010-06-26 10:38 ---
(In reply to comment #11)
> definition

Bah, that entity is the "fi" ligature, it should say definition


(In reply to comment #12)
> So is g++ accepting invalid code?

Yes, but it's a violation of the ODR, no diagnostic is required (it's not
possible to tell until link time that there's no definition.) 

There are DOZENS of duplicates of this bug, they are all invalid.


-- 


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[manu at gcc dot gnu dot org]

--- Comment #14 from manu at gcc dot gnu dot org  2010-06-26 10:53 ---
> (In reply to comment #12)
> > So is g++ accepting invalid code?
> 
> Yes, but it's a violation of the ODR, no diagnostic is required (it's not
> possible to tell until link time that there's no definition.) 
> 
> There are DOZENS of duplicates of this bug, they are all invalid.

However, it links in the if-else case. I understand that ?: may be used as a
lvalue, but in this case, it is not and the value may be inlined in the same
way as in if-else (I guess that is what Andrew's patch did). If the standard is
clear that this should not work, then so be it. 

Let's close this as INVALID, because I don't know how we could improve the
diagnostics here to help users. I wish we could but I cannot see how it can be
done. I guess that would require an integrated super-smart linker, I wonder if
the LLVM project is going to suggest that next?


-- 


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

[Bug libstdc++/44680] [4.5/4.6 regression] regex_traits/char/value.cc built with 4.4, run with 4.5's libstdc++ fails

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-26 11:23 
---
Regex was completely broken / unusable, before yesterday's first seriou stab at
it.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/44679] [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-26 11:27 
---
Jon, can you have a quick look to this? Thanks in advance


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||redi at gcc dot gnu dot org


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

[Bug tree-optimization/44676] [4.5/4.6 Regression] ICE: in loop_entry_phi_arg, at graphite-sese-to-poly.c:89 with -fgraphite-identity -fprofile-generate

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.1


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

[Bug tree-optimization/44674] [4.5/4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:953 with -fprofile-generate

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.1


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

[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++

[hubicka at gcc dot gnu dot org]

--- Comment #1 from hubicka at gcc dot gnu dot org  2010-06-26 11:39 ---
Subject: Bug 44671

Author: hubicka
Date: Sat Jun 26 11:38:57 2010
New Revision: 161428

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161428
Log:
PR middle-end/44671
* cgraphunit.c (cgraph_function_versioning): Remove wrong
cgraph_make_decl_local
call; fix typo copying RTL data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c


-- 


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

[Bug tree-optimization/44674] [4.5/4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:953 with -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-26 11:53 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-26 11:53:20
   date||


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

[Bug tree-optimization/44674] [4.5/4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:953 with -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-26 13:25 ---
Subject: Bug 44674

Author: rguenth
Date: Sat Jun 26 13:24:57 2010
New Revision: 161431

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161431
Log:
2010-06-26  Richard Guenther  

PR middle-end/44674
* tree-ssa-alias.c (refs_may_alias_p_1): Allow all kind of
decls.  Handle LABEL_DECLs like FUNCTION_DECLs.

* gcc.dg/pr44674.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr44674.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c


-- 


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

[Bug c/44681] New: usage of macro in loop boundary leads to crash

[jd at cococo dot de]

When porting my software from Win32 to Linux, i had to recompile it with gcc
under Mingw and also under Linux. There was a hurdle, because the loop shown
below in b) crashed after a while on both platforms. (I was happy to find the
location of the bug with gdb!) After rearranging the code like c) it worked
properly.
Sorry, but i am not able to provide test data. Maybe someone will see at once,
where the problem is located.

Greetings
Jens
http://cococo.de

a) prerequisite
#define max(a,b)a>b?a:b

b) buggy variant (for loop in line 13)
//--
//copy column left to right
//--
void copyvector(Tree pre,Tree left,int lc,Tree right,int rc) {
  int nr;
  callsofcopyvector++;
  //check initialization of precondition
  defval(left,right,rc,coeff(left,0,lc));
  right->functype=left->functype;
  right->bordertype=left->bordertype;
  right->symtype=left->symtype;
  right->reversive=left->reversive;
  for (nr=0;nr <= max(left->rows,right->rows);nr++) {//now do composition of
functions
 if (nr <= right->rows)
asg(right,nr,rc,0);
 if ((nr <= left->rows) && (nr <= right->rows)) {
Tree ur=coeff(left,nr,lc);
//debug(coeff(left,nr,0))
asg(right,nr,rc,ur);
 }
  }
  asg(right,0,rc,pre);
  checkunreachable(right,right,rc);
  return;
}
c) working variant
//--
//copy column left to right
//--
void copyvector(Tree pre,Tree left,int lc,Tree right,int rc) {
  int nr,mav=max(left->rows,right->rows);
  callsofcopyvector++;
  //check initialization of precondition
  defval(left,right,rc,coeff(left,0,lc));
  right->functype=left->functype;
  right->bordertype=left->bordertype;
  right->symtype=left->symtype;
  right->reversive=left->reversive;
  for (nr=0;nr <= mav;nr++) {//now do composition of functions
 if (nr <= right->rows)
asg(right,nr,rc,0);
 if ((nr <= left->rows) && (nr <= right->rows)) {
Tree ur=coeff(left,nr,lc);
//debug(coeff(left,nr,0))
asg(right,nr,rc,ur);
 }
  }
  asg(right,0,rc,pre);
  checkunreachable(right,right,rc);
  return;
}


-- 
   Summary: usage of macro in loop boundary leads to crash
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jd at cococo dot de


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

[Bug c++/44682] New: warning: variable �x� set but not used

[wouter dot vermaelen at scarlet dot be]

> cat bug.ii
struct Base1 {
virtual ~Base1() {}
};
struct Base2 {
virtual ~Base2() {}
};
struct Foo : Base1, Base2 {};

void f(Foo&);

void g(void* v) {
Base2* base = static_cast(v);
Foo* foo = static_cast(base);
f(*foo);
}


> g++ -Wall -c bug.ii
bug.ii: In function ‘void g(void*)’:
bug.ii:12:9: warning: variable ‘base’ set but not used
[-Wunused-but-set-variable]


I'm using SVN revision tr...@161411 on linux x86_64.


-- 
   Summary: warning: variable ‘x’ set but not used
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be


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

[Bug tree-optimization/44674] [4.5/4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:953 with -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-26 13:32 ---
Subject: Bug 44674

Author: rguenth
Date: Sat Jun 26 13:32:17 2010
New Revision: 161432

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161432
Log:
2010-06-26  Richard Guenther  

PR middle-end/44674
* tree-ssa-alias.c (refs_may_alias_p_1): Allow all kind of
decls.  Handle LABEL_DECLs like FUNCTION_DECLs.

* gcc.dg/pr44674.c: New testcase.

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


-- 


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

[Bug tree-optimization/44674] [4.5/4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:953 with -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-06-26 13:33 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||ice-on-valid-code
  Known to fail||4.5.0
 Resolution||FIXED


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

[Bug c++/44673] static const variable works in if/else, fails at linking in ternary

[redi at gcc dot gnu dot org]

--- Comment #15 from redi at gcc dot gnu dot org  2010-06-26 13:46 ---
(In reply to comment #14)
> 
> However, it links in the if-else case.

The variable is not "used" in the [basic.def.odr] sense, because the
lvalue-to-rvalue conversion occurs immediately.

> I understand that ?: may be used as a
> lvalue, but in this case, it is not and the value may be inlined in the same
> way as in if-else (I guess that is what Andrew's patch did). If the standard 
> is
> clear that this should not work, then so be it. 

The lvalue-to-rvalue conversion doesn't happen immediately to either the second
or third operand, it happens to the result of the conditional expression.

Andrew's idea might be allowed by the as-if rule, but I'm not sure. It must not
change the behaviour of valid programs. And in any case, the original example
is invalid. Supporting it is not important IMHO.

> Let's close this as INVALID, because I don't know how we could improve the
> diagnostics here to help users. I wish we could but I cannot see how it can be
> done. I guess that would require an integrated super-smart linker, I wonder if
> the LLVM project is going to suggest that next?

closing again


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/44679] [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-06-26 14:01 ---
condition_variable_any was completely broken in 4.4 and its ABi changed when we
implemented it for real. Obviously we can't preserve ABI between a broken,
incomplete implementation and a working one, so I'm not really worried about
this "bug". If anyone was able to use the condition_variable_any in 4.4 I'd
like to know how they did it!


-- 


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

[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-06-26 14:25 ---
I now see compile-time on polyhedron sky-rocketed with enabling prefetching at
-O3 by default.  See

http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-1-0.html

This isn't acceptable - please work on this.


-- 


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

[Bug libstdc++/44679] [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-06-26 14:51 ---
closing for the reasons given above


-- 

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=44679

[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-26 15:55 ---
Subject: Bug 44393

Author: rguenth
Date: Sat Jun 26 15:55:05 2010
New Revision: 161434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161434
Log:
2010-06-26  Richard Guenther  

PR tree-optimization/44393
* tree-loop-distribution.c (generate_loops_for_partition): Fix
stmt removal and VOP renaming.
(generate_memset_zero): Remove redundant stmt updating.
* tree-flow.h (mark_virtual_ops_in_bb): Remove.
* tree-cfg.c (mark_virtual_ops_in_bb): Likewise.

* gcc.dg/pr44393.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr44393.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-loop-distribution.c


-- 


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

[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-26 15:57 ---
Subject: Bug 44393

Author: rguenth
Date: Sat Jun 26 15:57:17 2010
New Revision: 161435

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161435
Log:
2010-06-26  Richard Guenther  

PR tree-optimization/44393
* tree-loop-distribution.c (generate_loops_for_partition): Fix
stmt removal and VOP renaming.
(generate_memset_zero): Remove redundant stmt updating.
* tree-flow.h (mark_virtual_ops_in_bb): Remove.
* tree-cfg.c (mark_virtual_ops_in_bb): Likewise.

* gcc.dg/pr44393.c: New testcase.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr44393.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-cfg.c
branches/gcc-4_5-branch/gcc/tree-flow.h
branches/gcc-4_5-branch/gcc/tree-loop-distribution.c


-- 


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

[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-26 15:58 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.5.0
 Resolution||FIXED


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

[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-06-26 16:07 ---
On Linux/ia32, I also see:

FAIL: abi_check
FAIL: 23_containers/unordered_map/erase/1.cc execution test
FAIL: 23_containers/unordered_map/erase/24061-map.cc execution test
FAIL: 23_containers/unordered_map/insert/array_syntax.cc execution test
FAIL: 23_containers/unordered_map/insert/map_range.cc execution test
FAIL: 23_containers/unordered_map/insert/map_single.cc execution test
FAIL: 23_containers/unordered_map/requirements/citerators.cc execution test
FAIL: 23_containers/unordered_map/requirements/exception/basic.cc execution
test
FAIL:
23_containers/unordered_map/requirements/exception/generation_prohibited.cc
execution test
FAIL:
23_containers/unordered_map/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_multimap/erase/1.cc execution test
FAIL: 23_containers/unordered_multimap/erase/24061-multimap.cc execution test
FAIL: 23_containers/unordered_multimap/insert/multimap_range.cc execution test
FAIL: 23_containers/unordered_multimap/insert/multimap_single.cc execution test
FAIL: 23_containers/unordered_multimap/requirements/citerators.cc execution
test
FAIL: 23_containers/unordered_multimap/requirements/exception/basic.cc
execution test
FAIL:
23_containers/unordered_multimap/requirements/exception/generation_prohibited.cc
execution test
FAIL:
23_containers/unordered_multimap/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_multiset/erase/1.cc execution test
FAIL: 23_containers/unordered_multiset/erase/24061-multiset.cc execution test
FAIL: 23_containers/unordered_multiset/insert/multiset_range.cc execution test
FAIL: 23_containers/unordered_multiset/insert/multiset_single.cc execution test
FAIL: 23_containers/unordered_multiset/requirements/citerators.cc execution
test
FAIL: 23_containers/unordered_multiset/requirements/exception/basic.cc
execution test
FAIL:
23_containers/unordered_multiset/requirements/exception/generation_prohibited.cc
execution test
FAIL:
23_containers/unordered_multiset/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_set/erase/1.cc execution test
FAIL: 23_containers/unordered_set/erase/24061-set.cc execution test
FAIL: 23_containers/unordered_set/insert/set_range.cc execution test
FAIL: 23_containers/unordered_set/insert/set_single.cc execution test
FAIL: 23_containers/unordered_set/requirements/citerators.cc execution test
FAIL: 23_containers/unordered_set/requirements/exception/basic.cc execution
test
FAIL:
23_containers/unordered_set/requirements/exception/generation_prohibited.cc
execution test
FAIL:
23_containers/unordered_set/requirements/exception/propagation_consistent.cc
execution test
FAIL: ext/pb_ds/example/basic_set.cc execution test
FAIL: ext/pb_ds/example/tree_intervals.cc execution test
FAIL: ext/pb_ds/example/tree_order_statistics.cc execution test
FAIL: ext/pb_ds/regression/tree_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc execution test
FAIL: tr1/6_containers/unordered_map/erase/1.cc execution test
FAIL: tr1/6_containers/unordered_map/erase/24061-map.cc execution test
FAIL: tr1/6_containers/unordered_map/insert/array_syntax.cc execution test
FAIL: tr1/6_containers/unordered_map/insert/map_range.cc execution test
FAIL: tr1/6_containers/unordered_map/insert/map_single.cc execution test
FAIL: tr1/6_containers/unordered_multimap/erase/1.cc execution test
FAIL: tr1/6_containers/unordered_multimap/erase/24061-multimap.cc execution
test
FAIL: tr1/6_containers/unordered_multimap/insert/multimap_range.cc execution
test
FAIL: tr1/6_containers/unordered_multimap/insert/multimap_single.cc execution
test
FAIL: tr1/6_containers/unordered_multiset/erase/1.cc execution test
FAIL: tr1/6_containers/unordered_multiset/erase/24061-multiset.cc execution
test
FAIL: tr1/6_containers/unordered_multiset/insert/multiset_range.cc execution
test
FAIL: tr1/6_containers/unordered_multiset/insert/multiset_single.cc execution
test
FAIL: tr1/6_containers/unordered_set/erase/1.cc execution test
FAIL: tr1/6_containers/unordered_set/erase/24061-set.cc execution test
FAIL: tr1/6_containers/unordered_set/insert/set_range.cc execution test
FAIL: tr1/6_containers/unordered_set/insert/set_single.cc execution test

Revision 161428 doesn't fix them.


-- 


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

[Bug c/44683] New: Optimization bug with copysign builtin

[dickinsm at gmail dot com]

Here's a minimal test-case:

-


int copysign_bug(double x)
{
  if (x * 0.5 == x)
return 1;
  else if (copysign(1.0, x) < 0.0)
return 2;
  else
return 3;
}

int main(void) {
  double x;
  x = -0.0;
  printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));

  x = 0.0;
  printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));

  return 0;
}

---

I'm compiling and executing the above code (filename copysign_bug.c) on
OpenSolaris build snv_134 running in Parallels on a Macbook Pro (Intel Core 2
Duo), using the following command line:

gcc-4.4 -m64 -fno-inline -g -O3 copysign_bug.c -o copysign_bug &&
./copysign_bug

I get the results:

copysign_bug(-0) = 3
copysign_bug(0) = 3

I was expecting to see the results:

copysign_bug(-0) = 2
copysign_bug(0) = 3

I get the latter results if I omit the '-O3' flag, or if I compile with
-fno-builtin-copysign and link with the math library.

gcc build information:

dicki...@eratosthenes:~/trunk$ gcc-4.4 -v -save-temps -m64 -lm
-fno-builtin-copysign -fno-inline -g copysign_bug.c
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.4.4/configure --prefix=/usr/local
--program-suffix=-4.4 --with-mpfr-include=/usr/include/mpfr
--with-gmp-include=/usr/include/gmp --with-as=/usr/bin/gas --with-gnu-as
--with-ld=/usr/bin/ld --without-gnu-ld --enable-shared --enable-multilib
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.4 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-fno-builtin-copysign'
'-fno-inline' '-g' '-mtune=generic'
 /usr/local/libexec/gcc/i386-pc-solaris2.11/4.4.4/cc1 -E -quiet -v -imultilib
amd64 copysign_bug.c -m64 -mtune=generic -fno-builtin-copysign -fno-inline -g
-fworking-directory -fpch-preprocess -o copysign_bug.i
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../../i386-pc-solaris2.11/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/include
 /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-fno-builtin-copysign'
'-fno-inline' '-g' '-mtune=generic'
 /usr/local/libexec/gcc/i386-pc-solaris2.11/4.4.4/cc1 -fpreprocessed
copysign_bug.i -quiet -dumpbase copysign_bug.c -m64 -mtune=generic -auxbase
copysign_bug -g -version -fno-builtin-copysign -fno-inline -o copysign_bug.s
GNU C (GCC) version 4.4.4 (i386-pc-solaris2.11)
compiled by GNU C version 4.4.4, GMP version 4.3.1, MPFR version
2.4.1-p5.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131015
Compiler executable checksum: f408a824c22e56e60b321448197fb865
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-fno-builtin-copysign'
'-fno-inline' '-g' '-mtune=generic'
 /usr/bin/gas -v -V -Qy --64 -s -o copysign_bug.o copysign_bug.s
GNU assembler version 2.19 (i386-pc-solaris2.11) using BFD version (GNU
Binutils) 2.19
COMPILER_PATH=/usr/local/libexec/gcc/i386-pc-solaris2.11/4.4.4/:/usr/local/libexec/gcc/i386-pc-solaris2.11/4.4.4/:/usr/local/libexec/gcc/i386-pc-solaris2.11/:/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/:/usr/local/lib/gcc/i386-pc-solaris2.11/:/usr/ccs/bin/
LIBRARY_PATH=/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/:/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../amd64/:/lib/amd64/:/usr/lib/amd64/:/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/:/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-fno-builtin-copysign'
'-fno-inline' '-g' '-mtune=generic'
 /usr/local/libexec/gcc/i386-pc-solaris2.11/4.4.4/collect2 -V -Y
P,/lib/64:/usr/lib/64 -Qy /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o
/usr/lib/amd64/values-Xa.o
/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/crtbegin.o
-L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64
-L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../amd64 -L/lib/amd64
-L/usr/lib/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4
-L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/../../.. -lm copysign_bug.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/crtend.o
/usr/lib/amd64/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1689


-- 
   Summary: Optimization bug with copysign builtin
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dickinsm at gmail dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug c/44683] Optimization bug with copysign builtin

[dickinsm at gmail dot com]

--- Comment #1 from dickinsm at gmail dot com  2010-06-26 17:01 ---
Created an attachment (id=21012)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21012&action=view)
Preprocessed source file


-- 


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

[Bug c/44683] Optimization bug with copysign builtin

[dickinsm at gmail dot com]

--- Comment #2 from dickinsm at gmail dot com  2010-06-26 18:16 ---
I'm also seeing this bug in gcc 4.5.0 on OS X, and it's been independently
confirmed in gcc 4.4.3 on Fedora 12 (see http://bugs.python.org/issue9069).


-- 


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

[Bug c/44683] Optimization bug with copysign builtin

[dickinsm at gmail dot com]

--- Comment #3 from dickinsm at gmail dot com  2010-06-26 18:26 ---
Apologies;  I seem to have messed up the original bug report, by accidentally
pasting a slightly edited version of the original bug file.  The minimal
test-case is as follows:


#include 
#include 

int copysign_bug(double x)
{
  if (x && (x * 0.5 == x))// note the extra "x &&" here
return 1;
  if (copysign(1.0, x) < 0.0)
return 2;
  else
return 3;
}

int main(void) {
  double x;
  x = -0.0;
  printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));

  x = 0.0;
  printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));

  return 0;
}


-- 


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

[Bug middle-end/44684] New: [4.6 regression] FAIL: g++.dg/opt/pmf1.C

[hjl dot tools at gmail dot com]

On Linux/x86, revision 161433 gave

FAIL: g++.dg/opt/pmf1.C (internal compiler error)
FAIL: g++.dg/opt/pmf1.C (test for excess errors)

/export/gnu/import/git/gcc-eas/gcc/testsuite/g++.dg/opt/pmf1.C:75:1: internal
compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:812^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

Revision 161428 is OK.


-- 
   Summary: [4.6 regression] FAIL: g++.dg/opt/pmf1.C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44684] [4.6 regression] FAIL: g++.dg/opt/pmf1.C

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-06-26 18:44 ---
It may be caused by revision 161431:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01349.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/44684] [4.6 regression] FAIL: g++.dg/opt/pmf1.C

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-06-26 18:57 ---
Since the patch is backported to 4.5 branch. This bug
may also impact 4.5.


-- 


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

[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling

[borntraeger at de dot ibm dot com]

--- Comment #6 from borntraeger at de dot ibm dot com  2010-06-26 20:30 
---
Richard,

can you check if compute_miss_rate is the problem?
does the attached patch helps?

thanks

Christian


-- 


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

[Bug middle-end/44684] [4.6 regression] FAIL: g++.dg/opt/pmf1.C

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-26 21:46 ---
Huh, I did test -m32 and didn't see this.  4.5 is affected only with
checking enabled.

Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-26 21:46:35
   date||


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

[Bug fortran/44678] ICE with -fdump-parse-tree and select type

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2010-06-26 22:03 ---
I have a patch.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-26 22:03:18
   date||


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

[Bug fortran/44678] ICE with -fdump-parse-tree and select type

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2010-06-26 22:54 ---
Subject: Bug 44678

Author: tkoenig
Date: Sat Jun 26 22:54:39 2010
New Revision: 161444

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161444
Log:
2010-06-27  Thomas Koenig  

PR fortran/44678
* dump-parse-tree.c (show_code_node):  Show namespace for
EXEC_BLOCK.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c


-- 


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

[Bug fortran/44678] ICE with -fdump-parse-tree and select type

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2010-06-26 22:56 ---
Fixed, closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/44683] Optimization bug with copysign builtin

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-26 22:57 ---
Confirmed.  Somewhere during RTL opts we thread a jump the wrong way.  Also
happens with SSE math.

int __attribute__((noinline,noclone))
copysign_bug (double x)
{
  if (x != 0.0 && (x * 0.5 == x))
return 1;
  if (__builtin_copysign(1.0, x) < 0.0)
return 2;
  else
return 3;
}
int main(void)
{
  double x = -0.0;
  if (copysign_bug (x) != 2)
__builtin_abort ();
  return 0;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |rtl-optimization
 Ever Confirmed|0   |1
 GCC target triplet|i386-pc-solaris2.11 |i?86-*-*
   Keywords||wrong-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-06-26 22:57:46
   date||


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

[Bug rtl-optimization/44683] [4.4/4.5/4.6 Regression] Optimization bug with copysign builtin

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.4
Summary|Optimization bug with   |[4.4/4.5/4.6 Regression]
   |copysign builtin|Optimization bug with
   ||copysign builtin
   Target Milestone|--- |4.4.5


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

[Bug middle-end/44684] [4.6 regression] FAIL: g++.dg/opt/pmf1.C

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-06-26 23:28 ---
On Linux/x86-64, revision 161432 failed to compile SPEC CPU 2006
with similar error:

g++ -c -o XercesXPath.o -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER 
-O2 -ffast-math   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX XercesXPath.cpp
g++ -c -o XPath.o -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER 
-O2 -ffast-math   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX XPath.cpp
...
XPath.cpp:5696:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:812
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

g++ -c -o messageoutput.o -DSPEC_CPU -DNDEBUG-O2 -ffast-math  
-DSPEC_CPU_LP64   messageoutput.cpp
...
messageoutput.cpp:1126:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:812
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[rwild at gcc dot gnu dot org]

-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rwild at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug rtl-optimization/44683] [4.4/4.5/4.6 Regression] Optimization bug with copysign builtin

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-06-27 03:04 ---
It is caused by revision 134833:

http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg01062.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||espindola at google dot com


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