[Bug target/32187] Complex __float128 is rejected

[and_j_rob at yahoo dot com]

--- Comment #9 from and_j_rob at yahoo dot com  2010-05-03 07:22 ---
Created an attachment (id=20540)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20540&action=view)
Was a C/C++ comparison

I found a similar problem while comparing C/C++ complexes, I'm on a x86_64 mac,
and was trying to learn about how the ABI works (with the attached code) when I
stumbled upon this.

Here is an overview of different combinations of floats and languages.

complex<*>..|.C..|.C++
++
long double.|.(good).|.(good)
__float80...|.(syntax error).|.(good)
__float128..|.(syntax error).|.(internal compiler error)

the ICE is
test.cpp:25: internal compiler error: in write_builtin_type, at
cp/mangle.c:1793

so I think what caused the ICE was the std::complex<__float128> snippet.


-- 


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

[Bug tree-optimization/29212] ICE with -fipa-pta

[jv244 at cam dot ac dot uk]

--- Comment #13 from jv244 at cam dot ac dot uk  2010-05-03 07:46 ---
these might be fixed in current trunk as a result of the fixes to PR43879


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  BugsThisDependsOn||43879


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

[Bug libstdc++/43968] New: undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

libmudflap.c++/pass41-frag.cxx test case fails with -static [1] due to link
problem in libstdc++:

FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed to produce
executable

The problem can be triggered with following command:

/home/uros/gcc-build/gcc/g++ -B/home/uros/gcc-build/gcc
-I/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/alphaev68-unknown-linux-gnu
-I/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include
-I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++
-L/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs
-static pass41-frag.cxx

and compilation fails with:

/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:421:
undefined reference to `std::num_get > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:422:
undefined reference to `std::num_put > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:423:
undefined reference to `std::money_get > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:424:
undefined reference to `std::money_put > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:426:
undefined reference to `std::num_get > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:427:
undefined reference to `std::num_put > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:428:
undefined reference to `std::money_get > >::id'
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(locale.o):/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/src/../../../../gcc-svn/trunk/libstdc++-v3/src/locale.cc:429:
undefined reference to `std::money_put > >::id'
collect2: ld returned 1 exit status

Without -static, everything works OK.

[1] http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00240.html


-- 
   Summary: undefined references to `std::{num_get, num_put,
money_get, money_put}< [...] >::id' with -static
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
 GCC build triplet: alpha-linux-gnu
  GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu


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

[Bug libstdc++/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-05-03 08:14 ---
The testcase:

#include 
#include 

int
main (int argc, char *argv[])
{
std::string myStr = "Hello, World!";
std::cout << myStr << std::endl;
return 0;
}


-- 


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2010-05-03 09:01 ---
(In reply to comment #8)

> It may be a good idea by itself. However, since AMD64 uses movd instead
> of movq, some non-GNU assemblers may not support movq. Why change it
> when nothing is broken?

Indeed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/29212] ICE with -fipa-pta

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2010-05-03 09:16 
---
Fixed long ago.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/43964] [4.6 Regression] 4.6-20100501 (r158965) bootstrap failure on ARM, ira-color.c triggers -Werror

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|4.6-20100501 (r158965)  |[4.6 Regression] 4.6-
   |bootstrap failure on ARM,   |20100501 (r158965) bootstrap
   |ira-color.c triggers -Werror|failure on ARM, ira-color.c
   ||triggers -Werror
   Target Milestone|--- |4.6.0


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

[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

[rdsandiford at googlemail dot com]

--- Comment #13 from rdsandiford at googlemail dot com  2010-05-03 09:53 
---
Subject: Re:  [4.5/4.6 regression] ICE in reload_cse_simplify_operands

"mkuvyrkov at gcc dot gnu dot org"  writes:
> --- Comment #10 from mkuvyrkov at gcc dot gnu dot org  2010-04-23 10:20 
> ---
> The problem seems to be in Richard's patch
> (http://article.gmane.org/gmane.comp.gcc.patches/130602) checked in r120961.
>
> All and all, it seems that revision 120961 should be reverted to enable 'T'
> constraint for (flag_pic && !TARGET_PCREL).
>
> The 's' constraint is defined as
> ==
>   case 's':
> if (CONST_INT_P (op)
> || (GET_CODE (op) == CONST_DOUBLE
> && GET_MODE (op) == VOIDmode))
>   break;
>   case 'i':
> if (CONSTANT_P (op))
>   win = 1;
> break;
> ==
>
> So, unless I'm missing something, the statement
> "... 's' doesn't accept anything if flag_pic"
> is just wrong.

I meant "flag_pic && !TARGET_PCREL", since only the !TARGET_PCREL case
matters for 'T'.  And that was right at the time that I wrote it.
The interesting definition of 's' isn't the one you quote, but the one
in reload:

  case 's':
if (CONST_INT_P (operand)
|| (GET_CODE (operand) == CONST_DOUBLE
&& GET_MODE (operand) == VOIDmode))
  break;
  case 'i':
if (CONSTANT_P (operand)
&& (! flag_pic || LEGITIMATE_PIC_OPERAND_P (operand)))
  win = 1;
break;

That is, 's' operands have to satisfy LEGITIMATE_PIC_OPERAND_P when
generating PIC.  I'm not sure which version you were quoting, but if it
was constrain_operands, that's a special case.  constrain_operands can
rely on the predicates to check for legitimate PIC operands, so there's
no need to repeat the check there.

At the time I committed the patch, LEGITIMATE_PIC_OPERAND_P was
defined as follows:

#define LEGITIMATE_PIC_OPERAND_P(X) \
  (!symbolic_operand (X, VOIDmode)  \
   || (TARGET_PCREL && REG_STRICT_P))

Thus no symbolic constant was a legitimate PIC operand for
flag_pic && !TARGET_PCREL.  Thus nothing satisfied 's' when
flag_pic && !TARGET_PCREL.

The 'T' constraint is defined as follows:

  satisifies(T) == satisifies(s) && !TARGET_PCREL

so it followed that nothing should match 'T' when flag_pic.

So the patch was correct at the time it was committed.  Please
understand that reverting it is the wrong thing to do.  It would
reintroduce the original bug: that constraints _must not_ match
something that the associated predicates do not.  Only the other
way is allowed: predicates can allow things that the constraints
don't, within certain limits.

For example, let's say you have an insn that matches:

(define_insn "subsi3"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=mda,m,d,a")
(minus:SI (match_operand:SI 1 "general_operand" "0,0,0,0")
  (match_operand:SI 2 "general_src_operand"
"I,dT,mSrT,mSrs")))]
  ""
  "@
   subq%.l %2, %0
   sub%.l %2,%0
   sub%.l %2,%0
   sub%.l %2,%0"
  [(set_attr "type" "aluq_l,alu_l,alu_l,alu_l")
   (set_attr "opy" "2")])

And let's suppose that operand 2 is a register that is equal to:

  (symbol_ref "x")

If 'T' allows any CONST, SYMBOL_REF or LABEL_REF when flag_pic &&
!TARGET_PCREL (as in your suggested patch), reload could quite happily
establish that operand 2 is (symbol_ref "x"), see that it matches 'T',
and use it.  This will then lead to an unrecognisable insn, because
although the constant matches the 'T' constraint, it doesn't match
general_src_operand.

Instead, the bug is that the 'T' constraint wasn't updated by the TLS
support at the same time as LEGITIMATE_PIC_OPERAND_P was.  An easy thing
to miss, of course.  I think the correct patch is the one I'm about
to attach.

Richard


-- 


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

[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

[rsandifo at gcc dot gnu dot org]

--- Comment #14 from rsandifo at gcc dot gnu dot org  2010-05-03 09:55 
---
Created an attachment (id=20541)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20541&action=view)
proposed patch


-- 


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

[Bug tree-optimization/43965] Missed VRP and/or jump-threading

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-05-03 09:55 ---
Confirmed.  This is a case where we'd have to do some interesting VRP and
jump-threading.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-05-03 09:55:51
   date||
Summary|doubled code (x86)  |Missed VRP and/or jump-
   ||threading


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

[Bug tree-optimization/43966] redundant predicated checks not removed by VRP or jump-threading

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-05-03 09:59 ---
Well, this is another case where the predication by if (mData) makes this
hard to optimize.  Not impossible, but hard.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-05-03 09:59:47
   date||
Summary|redundant checks not removed|redundant predicated checks
   ||not removed by VRP or jump-
   ||threading


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

[Bug fortran/43969] New: [OOP] CLASS(foo), ALLOCATABLE component bad initialization

[sfilippone at uniroma2 dot it]

Hello,
The attached code asserts that an ALLOCATABLE inner component starts its life
as ALLOCATED, which is contrary to everything I know about allocatables. 
- log ---
[sfili...@donald bug16]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured)
../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100430 (experimental) (GCC) 
[sfili...@donald bug16]$ gfortran -o testd16 testd16.f03
[sfili...@donald bug16]$ ./testd16 
 Check on allocated:  T
-
Salvatore


-- 
   Summary: [OOP]  CLASS(foo), ALLOCATABLE component bad
initialization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
 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=43969

[Bug fortran/43969] [OOP] CLASS(foo), ALLOCATABLE component bad initialization

[sfilippone at uniroma2 dot it]

--- Comment #1 from sfilippone at uniroma2 dot it  2010-05-03 10:12 ---
Created an attachment (id=20542)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20542&action=view)
test case


-- 


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

[Bug driver/43970] New: configure --with-local-prefix=no does nothing

[joerg dot richter at pdv-fs dot de]

$ gcc -v
Using built-in specs.
COLLECT_GCC=/tools/pkg/gcc/4.5.0/bin/gcc
COLLECT_LTO_WRAPPER=/tools/pkg/gcc/4.5.0/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: gcc-4.5.0/configure --enable-languages=c,c++
--disable-bootstrap --disable-nls --with-local-prefix=no
--with-as=/tools/pkg/binutils/2.19/bin/as
--with-ld=/tools/pkg/binutils/2.19/bin/ld --prefix=/tools/pkg/gcc/4.5.0
Thread model: posix
gcc version 4.5.0 (GCC) 

I got this '--with-local-prefix=no' from looking at gcc/configure

But it doesn't work as expected:

$ touch a.c
$ gcc -v a.c
...
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /tools/pkg/gcc/4.5.0/include
 /tools/pkg/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/include
 /tools/pkg/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/include-fixed
 /usr/include
End of search list.
...

/usr/local/include is still there.
What is the correct way to have no local prefix?


-- 
   Summary: configure --with-local-prefix=no does nothing
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de


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

[Bug c/43971] New: index domain error in tree-ssa-structalias.c:3450

[dcb314 at hotmail dot com]

I just tried to compile the Linux kernel version linux-2.6.34-rc6
with the C compiler version 4.6 snapshot 20100501 and it said

init/main.c: In function 'do_one_initcall':
init/main.c:915:1: internal compiler error: vector VEC(ce_s,base) index domain
error, in do_structure_copy at tree-ssa-structalias.c:3450
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -fno-delete-null-pointer-checks -Os
required.


-- 
   Summary: index domain error in tree-ssa-structalias.c:3450
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c/43971] index domain error in tree-ssa-structalias.c:3450

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2010-05-03 10:24 ---
Created an attachment (id=20543)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20543&action=view)
gzipped C source code


-- 


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

[Bug debug/43972] New: [4.5/4.6 Regression] ICE in loc_cmp

[jakub at gcc dot gnu dot org]

struct { int *b1; } *f1 ();
short v1[1];
struct S { int b2; };
void
foo (struct S *a1, union { char *b3; unsigned *b4; int *b5; } *a2)
{
  int d;
  switch (d)
{
case 0:
  {
int c = a1->b2, i;
if (f1 () == 0)
  *a2->b3++ = 2;
else if (((long) (f1 () - f1 ())) ^ ((long) f1 ()->b1 - ((long) f1 () &
8)))
  *a2->b3++ = (long) f1 - ((long) f1 () & 0xff);
else
  *a2->b4++ = (long) f1;
for (i = 0; i < c; i++)
  *a2->b5++ = (long) v1;
foo (a1, a2);
  }
}
}

ICEs with -g -O2 -fpic on x86_64-linux with:
rh588154.i: In function 'foo':
rh588154.i:24:1: internal compiler error: in loc_cmp, at var-tracking.c:2681
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5/4.6 Regression] ICE in loc_cmp
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
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=43972

[Bug debug/43972] [4.5/4.6 Regression] ICE in loc_cmp

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-03 10:34 ---
 (value/u:DI 24:19029 @0x171db88/0x172c120)
offset 0
  (reg:SI 4 si)
  (mem/c:QI (value:DI 26:3872 @0x171dbb8/0x172c180) [11 %sfp+-1 S1 A8])
  (mem:SI (value/u:DI 52:52 @0x171de28/0x172d4b0) [2 *D.2766_31+0 S4 A32])
  (value/u:QI 25:25 @0x171dba0/0x172c150)
  (value/u:SI 53:53 @0x171de40/0x172d4e0)

the modes differ a lot here.


-- 


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

[Bug fortran/43969] [OOP] CLASS(foo), ALLOCATABLE component bad initialization

[sfilippone at uniroma2 dot it]

--- Comment #2 from sfilippone at uniroma2 dot it  2010-05-03 10:37 ---
Created an attachment (id=20544)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20544&action=view)
Extended text case

With this and a fresh build at r158988 I get the following: 

[sfili...@donald bug16]$ ./testd16 
 Check on allocated:  T
 Check on allocated 3:  T
At line 18 of file testd16.f03
Fortran runtime error: Attempting to allocate already allocated array 'try2'


-- 


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

[Bug bootstrap/43964] [4.6 Regression] 4.6-20100501 (r158965) bootstrap failure on ARM, ira-color.c triggers -Werror

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2010-05-03 10:43 ---
Created an attachment (id=20545)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20545&action=view)
suggested fix for PR43964

Confirmed r158911 to be the cause of this bootstrap failure.  Attached patch
should fix it.  So far tested with bootstrap on i686-linux and cross to arm. 
I'm now running a full bootstrap (all languages except ada) on arm, expect 12
hours or so for it to complete.


-- 


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

[Bug c/43973] New: alpha libiberty/regex.c fails to compile with -O2 without -mbwx (internal compiler error)

[jay dot krell at cornell dot edu]

This code reduced from libiberty/regex.c

typedef unsigned char UCHAR;

void insert_op2 (UCHAR *loc, UCHAR *end)
{
   UCHAR *pfrom = end;
   UCHAR *pto = end + 1;

  while (pfrom != loc)
*--pto = *--pfrom;
}


jbook2:~ jay$ alpha-dec-vms-gcc -c re.c

jbook2:~ jay$ alpha-dec-vms-gcc -c -O2 re.c
re.c: In function 'insert_op2':
re.c:10:1: error: unrecognizable insn:
(insn 58 57 59 5 re.c:9 (set (reg:DI 120)
(plus:SI (subreg/s:SI (reg/v/f:DI 108 [ pfrom ]) 0)
(const_int 1 [0x1]))) -1 (nil))
re.c:10: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: alpha libiberty/regex.c fails to compile with -O2
without -mbwx (internal compiler error)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
 GCC build triplet: Mac/x86
  GCC host triplet: alpha-dec-vms
GCC target triplet: alpha-dec-vms


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

[Bug libstdc++/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-05-03 10:52 
---
Before we do anything here, you should try to explain why the problem happens
only on alpha, because on x86_64 it doesn't and those symbols are exported
("V"). Are the symbols exported on alpha? Are we **really** sure that aging
target is otherwise ok, binutils included?


-- 


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

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

--- Comment #53 from jv244 at cam dot ac dot uk  2010-05-03 10:57 ---
testcase in comment #40 now works. Comment #42 still fails.


-- 


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

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[loaden at gmail dot com]

--- Comment #15 from loaden at gmail dot com  2010-05-03 11:11 ---
The problem is too serious! I have 4G memory, but not able to compile wxWidgets
2.8.10.


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2010-05-03 11:16 ---
Subject: Re:  [4.6 Regression] FAIL:
 gcc.c-torture/compile/pr42196-2.c

On Sun, 2 May 2010, irar at il dot ibm dot com wrote:

> --- Comment #10 from irar at il dot ibm dot com  2010-05-02 12:12 ---
> Looks like it's caused by:
> r158157 | rguenth | 2010-04-09 13:40:14 +0300 (Fri, 09 Apr 2010) | 28 lines
> 
> The problem is in getting vectype for f1_2:
> 
> foo (int b, double f1, double f2, int c1, int c2)
> {
> ...
>   float D.1999;
>   float D.1998;
> ...
> 
> :
>   D.1998_3 = (float) f1_2(D);
>   REALPART_EXPR  = D.1998_3;
>   D.1999_5 = (float) f2_4(D);
>   IMAGPART_EXPR  = D.1999_5;
>   D.2012_10 = u.ci;
>   goto ;
> 
> An immediate fix would be to replace the assert in 
> 
>   /* If op0 is an external or constant def use a vector type with
>  the same size as the output vector type.  */
>   if (!vectype)
> vectype = get_same_sized_vectype (TREE_TYPE (op0), vectype_out);
>   gcc_assert (vectype);
> 
> with 'return false', since get_same_sized_vectype currently just redirects to
> get_vectype_for_scalar_type. But the comment (and the future intent) seems
> incorrect for external defs, as f1 and f2 in this test.

Well.  For loops we'd have disqualified it as there is no vector
type for the external def (well, the stmt inside the loop).
So we do not do this for SLP?  In that case
yes, if we can return false at this point then we should replace this
(and similar) asserts with return false.  Or we should fix
the code that scans the BB initially and sets vector types properly?

Thanks,
Richard.


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug debug/43972] [4.5/4.6 Regression] ICE in loc_cmp

[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=43972

[Bug c/43971] index domain error in tree-ssa-structalias.c:3450

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-05-03 11:27 ---
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-05-03 11:27:20
   date||


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

[Bug libstdc++/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2010-05-03 11:46 ---
(In reply to comment #2)
> Before we do anything here, you should try to explain why the problem happens
> only on alpha, because on x86_64 it doesn't and those symbols are exported
> ("V"). Are the symbols exported on alpha? Are we **really** sure that aging
> target is otherwise ok, binutils included?

In the hope it helps, this is what I get from
libstdc++-v3/src/.libs/libstdc++.a:

$ c++filt _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
std::num_get >
>::id

$ nm libstdc++.a | grep
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
 U
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
 u
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE


-- 


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

[Bug libstdc++/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2010-05-03 11:50 ---
As shown, these symbols are exported as "u":

`u'
  The symbol is a unique global symbol.  This is a GNU
  extension to the standard set of ELF symbol bindings.  For
  such a symbol the dynamic linker will make sure that in the
  entire process there is just one symbol with this name and
  type in use.


-- 


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

[Bug libstdc++/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-05-03 11:52 
---
This is what I get on x86_64:

nm libstdc++.a | grep
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
 U
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
 U
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
 V
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE

thus, seems a target problem to me.


-- 


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

[Bug c/43974] New: Undefined symbol main in crt1.o when compiling shared libs on Solaris

[bjoern at j3e dot de]

Comiling any shared library on Solaris with LDFLAGS "-Wl,-z,defs" to make sure
that there are no unresoloved symbols results in:

Undefined   first referenced
 symbol in file
main   
/usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/crt1.o
ld: fatal: Symbol referencing errors. No output written to bin/libtalloc.so.2

It looks like there is a wrong assumption about a shared library having to have
a symbol "main" on gcc on Solaris. More recent gcc releases than the above
example are also affected.


-- 
   Summary: Undefined symbol main in crt1.o when compiling shared
libs on Solaris
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern at j3e dot de


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

[Bug debug/43972] [4.5/4.6 Regression] ICE in loc_cmp

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-03 11:55 ---
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-03 11:55:05
   date||


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

[Bug c++/43975] New: g++ function resolution failure

[internet at calumgrant dot net]

The following does not compile (minimal test case):

#include 

int main()
{
int vec;

struct comparator
{
bool operator()(int a, int b) const { return a

struct comparator
{
bool operator()(int a, int b) const { return ahttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43975

[Bug c++/43975] g++ function resolution failure

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-05-03 12:06 
---
Yes, in C++03 you cannot instantiate a template with a local type. C++1x will
be different.


-- 

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

[Bug c/43973] alpha libiberty/regex.c fails to compile with -O2 without -mbwx (internal compiler error)

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-05-03 12:09 ---
Confirmed with a cross from x86_64-pc-linux-gnu to alpha-dec-vms.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-03 12:09:50
   date||


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

[Bug target/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-05-03 12:12 ---
(In reply to comment #5)
> This is what I get on x86_64:

> thus, seems a target problem to me.

Do you have any advice, where/how these symbols get exported? I would like to
analyze the failure, so we can blame some other tool ;)

(No, I'm not sure that binutils work correctly...)


-- 


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

[Bug target/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-05-03 12:17 
---
In locale-inst.o


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

--- Comment #12 from irar at il dot ibm dot com  2010-05-03 12:30 ---

> Well.  For loops we'd have disqualified it as there is no vector
> type for the external def (well, the stmt inside the loop).

I don't think that's true. With -fno-tree-pre we get the same ICE for loop
vectorization for:

#define N 64

union U
{
  __complex__ int ci;
  __complex__ float cf;
};

union U u[N];

void foo (double f1, double f2)
{
  int i;

  for (i=0; i So we do not do this for SLP?  In that case
> yes, if we can return false at this point then we should replace this
> (and similar) asserts with return false.  Or we should fix
> the code that scans the BB initially and sets vector types properly?

The loop scan that sets vector types, only checks lhs types (or the smallest
type in stmt) in order to decide on vectorization factor. There is a similar
scan for BBs in vect_analyze_stmt (only to set vector types for stmts) and it
also looks only at lhs. 

The failure occurs in analysis, so it's ok to return false at this point. 
But I don't understand why external def has to have the same size as the lhs?
(And it is, of course, possible that both types are vectorizable, but still the
rhs type is bigger than the lhs type).

Thanks,
Ira

> 
> Thanks,
> Richard.
> 


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenther at suse dot de]

--- Comment #13 from rguenther at suse dot de  2010-05-03 12:35 ---
Subject: Re:  [4.6 Regression] FAIL:
 gcc.c-torture/compile/pr42196-2.c

On Mon, 3 May 2010, irar at il dot ibm dot com wrote:

> --- Comment #12 from irar at il dot ibm dot com  2010-05-03 12:30 ---
> 
> > Well.  For loops we'd have disqualified it as there is no vector
> > type for the external def (well, the stmt inside the loop).
> 
> I don't think that's true. With -fno-tree-pre we get the same ICE for loop
> vectorization for:
> 
> #define N 64
> 
> union U
> {
>   __complex__ int ci;
>   __complex__ float cf;
> };
> 
> union U u[N];
> 
> void foo (double f1, double f2)
> {
>   int i;
> 
>   for (i=0; i {
>   __real__ u[i].cf = f1;
>   __imag__ u[i].cf = f2;
> }
> }
> 
> > So we do not do this for SLP?  In that case
> > yes, if we can return false at this point then we should replace this
> > (and similar) asserts with return false.  Or we should fix
> > the code that scans the BB initially and sets vector types properly?
> 
> The loop scan that sets vector types, only checks lhs types (or the smallest
> type in stmt) in order to decide on vectorization factor. There is a similar
> scan for BBs in vect_analyze_stmt (only to set vector types for stmts) and it
> also looks only at lhs. 

Ah, my followup AVX patches look at all operands.

> The failure occurs in analysis, so it's ok to return false at this point. 
> But I don't understand why external def has to have the same size as the lhs?
> (And it is, of course, possible that both types are vectorizable, but still 
> the
> rhs type is bigger than the lhs type).

It tries to get a _vector_ type of the same size.  In theory each
vectorization method can choose whatever vector size suits them
most (as for external defs they need to build up a vector of equivalent
elements anyway).  So with AVX we can do V4DF -> V4SF vectorization,
if the double is an external def the vectorization method could choose
to create a vector with double size.  But the reasonable default for
now is th force a same-sized vector type as that is what the vectorizer
was tested for until now (well, until I get the followup patch cleaned
up and posted again).

So yes, if we can return false we should probably do so instead of
asserting (maybe assert that if we are supposed to create vectorized
stmts and thus cannot fail that we indeed have a vector type here).

Richard.


-- 


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

[Bug c++/31584] ICE on probably invalid code

[numerical dot simulation at web dot de]

--- Comment #6 from numerical dot simulation at web dot de  2010-05-03 
12:53 ---
Hi!

Though I love the fact that this code now compiles, I am still unsure whether
this is the right thing to have.
>From http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#502 I see 
>that 
the proposed resolution (February, 2010) stands against what David Vandevoorde
said in
http://groups.google.de/group/comp.lang.c++.moderated/browse_thread/thread/8c3b8a84ed78b003/4d9603171894a75d?hl=de#4d9603171894a75d
and the enum now is dependent and so IMHO the code should not compile.
Maybe I missed something. Could you please shed some more light on this?

Markus Werle


-- 

numerical dot simulation at web dot de changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug c++/31584] [DR502] ICE on probably invalid code

[redi at gcc dot gnu dot org]

--- Comment #7 from redi at gcc dot gnu dot org  2010-05-03 13:01 ---
I didn't realise there was a DR about this, confirm ...


-- 

redi 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-05-03 13:01:44
   date||
Summary|ICE on probably invalid code|[DR502] ICE on probably
   ||invalid code


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

[Bug c++/31584] [DR502] ICE on probably invalid code

[redi at gcc dot gnu dot org]

--- Comment #8 from redi at gcc dot gnu dot org  2010-05-03 13:02 ---
... and suspend until the issue is ready


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug c/43973] alpha libiberty/regex.c fails to compile with -O2 without -mbwx (internal compiler error)

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2010-05-03 13:46 ---
Hm, in expand_assignment (), around line 4408 in expr.c, we expand

MEM[base: pfrom_8, offset: 1]

to

(mem:QI (plus:DI (subreg/s:SI (reg/v/f:DI 108 [ pfrom ]) 0)
(const_int 1 [0x1])) [0 *pfrom_8 S1 A8])

IMO, the usage of subregs is kind of suspicious since this is invalid RTX.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug debug/43478] Missing DW_AT_location for a variable

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-05-03 14:38 ---
I've also bootstrapped the first patch today, unfortunately on i686-linux it
regresses forall_7.f90 testcase - gsi_skip_debug is called with after = 1
on sequence D.3267_429 = 125 + 5; (pointing at the only stmt in there).
This calls gsi_next_nondebug which sets gsi->ptr to NULL - end_p situation
and the following gsi_prev fails on assertion.  I believe for after == true
we can't use gsi_next_nondebug, instead it should be a loop using
gsi_one_before_end_p predicate or something similar.


-- 


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

[Bug c++/43976] New: warning about increased alignment during casting printed even though variable is properly aligned

[thiago at kde dot org]

Source: https://bugs.webkit.org/show_bug.cgi?id=38045

Given the following code:

$ cat test.cpp
struct Foo
{
char __attribute__((aligned(4))) c[sizeof(int)];
};

char junk;
Foo f;

int main()
{
int *i = reinterpret_cast(&f.c);
*i = 0;
}

When compiled for ARM produces the warning:
$ arm-none-linux-gnueabi-g++ -Wcast-align -O3 -fsyntax-only /tmp/test.cpp
test.cpp:11: warning: cast from 'char (*)[4]' to 'int*' increases required
alignment of target type

Note that we requested that Foo::c be aligned to 4 bytes, which is the required
alignment for int. The assembly dump of the build confirms that the alignment
was honoured:

junk:
.space  1
.space  3
.type   f, %object
.size   f, 4
f:
.space  4

According to Dirk Müller, the following code is at fault (I have no idea where
it's from):
  /* Warn about possible alignment problems.  */
  if (STRICT_ALIGNMENT && warn_cast_align
  && (complain & tf_warning)
· && !VOID_TYPE_P (type)
· && TREE_CODE (TREE_TYPE (intype)) != FUNCTION_TYPE
· && COMPLETE_TYPE_P (TREE_TYPE (type))
· && COMPLETE_TYPE_P (TREE_TYPE (intype))
· && TYPE_ALIGN (TREE_TYPE (type)) > TYPE_ALIGN (TREE_TYPE (intype)))
·   warning (OPT_Wcast_align, "cast from %qT to %qT "
 "increases required alignment of target type", intype, type);

As it only verifies the aligment of the type in question (char*), not of the
variable in question (&f.c).


-- 
   Summary: warning about increased alignment during casting printed
even though variable is properly aligned
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thiago at kde dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-linux-gnueabi


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

[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref

[brtnfld at hdfgroup dot org]

--- Comment #11 from brtnfld at hdfgroup dot org  2010-05-03 14:50 ---
(In reply to comment #10)
> Can this be closed? Is there something left to do here?
> 
As of gfortran 4.4.4 (and 4.5.1) the program in comment #7 does not compile but
gives the same error:

Error: CHARACTER argument 'buf' to 'c_loc' at (1) must have a length of 1


-- 


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

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

[zsojka at seznam dot cz]

--- Comment #25 from zsojka at seznam dot cz  2010-05-03 14:56 ---
Created an attachment (id=20546)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20546&action=view)
next testcase, second part will follow


-- 


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

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

[zsojka at seznam dot cz]

--- Comment #26 from zsojka at seznam dot cz  2010-05-03 15:02 ---
Created an attachment (id=20547)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20547&action=view)
next testcase

Reduced from libstdc++-v3/testsuite/23_containers/bitset/operations/1.cc

I am happy those testcases helped with gcc development, and I hope this one
will too.

Command line:
$ g++ -O[123] -fipa-pta pr43879-4_1.C pr43879-4_2.C && ./a.out
Aborted

For some reason, b1.i is expected to be zero:
(diff from asm output for a bit different testcase)
101c98
<   cmp QWORD PTR [rsp+48], rbx # b2.i, b1$i
---
>   cmp QWORD PTR [rsp+48], 0   # b2.i,


-- 


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

[Bug debug/43972] [4.5/4.6 Regression] ICE in loc_cmp

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-03 15:43 ---
Subject: Bug 43972

Author: jakub
Date: Mon May  3 15:42:43 2010
New Revision: 158989

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158989
Log:
PR debug/43972
* config/i386/i386.c (ix86_delegitimize_address): Make sure the
result mode matches original rtl mode.

* gcc.dg/debug/pr43972.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/pr43972.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/43972] [4.5/4.6 Regression] ICE in loc_cmp

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-03 15:46 ---
Subject: Bug 43972

Author: jakub
Date: Mon May  3 15:46:43 2010
New Revision: 158990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158990
Log:
PR debug/43972
* config/i386/i386.c (ix86_delegitimize_address): Make sure the
result mode matches original rtl mode.

* gcc.dg/debug/pr43972.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/debug/pr43972.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/43973] alpha libiberty/regex.c fails to compile with -O2 without -mbwx (internal compiler error)

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2010-05-03 16:12 ---
Can you try this patch:

--cut here--
Index: alpha.c
===
--- alpha.c (revision 158970)
+++ alpha.c (working copy)
@@ -842,7 +842,8 @@ alpha_legitimate_address_p (enum machine
 #endif

   /* Register plus a small constant offset is valid.  */
-  if (GET_CODE (x) == PLUS)
+  if (mode == DImode
+  && GET_CODE (x) == PLUS)
 {
   rtx ofs = XEXP (x, 1);
   x = XEXP (x, 0);
--cut here--

The core of the problem is 32bit POINTER_MODE, defined in vms.h and the fact,
that nothing prevents non-DImode address_operands from entering various
expanders. These expanders wrongly assume that decorating match_operand with DI
will magically fix wrong mode.


-- 


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

[Bug c/43971] index domain error in tree-ssa-structalias.c:3450

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-05-03 16:12 ---
Subject: Bug 43971

Author: rguenth
Date: Mon May  3 16:12:12 2010
New Revision: 158991

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158991
Log:
2010-05-03  Richard Guenther  

PR tree-optimization/43971
* tree-ssa-structalias.c (get_constraint_for_1): Fix
constraints in the !flag_delete_null_pointer_checks case.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr43971.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

[steven at gcc dot gnu dot org]

--- Comment #27 from steven at gcc dot gnu dot org  2010-05-03 16:56 ---
Zdenek, has anyone told you how amazing your contribution is here? Wow!


-- 


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

[Bug target/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2010-05-03 17:25 ---
(In reply to comment #7)
> In locale-inst.o

Strange, on alpha it is defined in compatibility-ldbl.o.


-- 


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

[Bug target/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-05-03 17:41 
---
Ah yes, it's probably because of the strange workarounds put in place for long
double. Anyway, if you encounter special issues having to do with that, Jakub
is the reference person.


-- 


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

[Bug target/43968] undefined references to `std::{num_get, num_put, money_get, money_put}< [...] >::id' with -static

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2010-05-03 17:44 ---
(In reply to comment #9)
> Ah yes, it's probably because of the strange workarounds put in place for long
> double. Anyway, if you encounter special issues having to do with that, Jakub
> is the reference person.

Added to CC.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-03 17:44:18
   date||


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

[Bug c++/43953] ICE: dependent_type_p, at cp/pt.c:17404

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-01 13:58:34 |2010-05-03 17:54:28
   date||


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

[Bug fortran/43592] Unexpected INTERFACE statement in INTERFACE block at (1)

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2010-05-03 17:57 ---
Subject: Bug 43592

Author: kargl
Date: Mon May  3 17:57:14 2010
New Revision: 158998

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158998
Log:
2010-05-03  Steven G. Kargl  

PR fortran/43592
* fortran/parse.c (parse_interface): Do not dereference a NULL pointer.

2010-05-03  Steven G. Kargl  

PR fortran/43592
* gfortran.dg/unexpected_interface.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/unexpected_interface.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/43977] New: Patches from oldlto branch to be salvaged

[steven at gcc dot gnu dot org]

This is a bug to keep track of the patches committed to the oldlto branch but
never merged to the trunk. The interesting patches to "salvage" are mostly
related to elimination of TREE_LIST.


-- 
   Summary: Patches from oldlto branch to be salvaged
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org


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

[Bug other/43977] Patches from oldlto branch to be salvaged

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2010-05-03 18:08 ---
Created an attachment (id=20548)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20548&action=view)
List of commits to the oldlto branch upto the rename point

The attached list was generated with:

svn diff svn://gcc.gnu.org/svn/gcc/branches/l...@124989 2>&1 | tee oldlto.txt

At r124989 the branch was renamed from branches/lto to branches/oldlto (to
restart the LTO effort with a different design). Up to that point there were
242 commits.

I plan to go through the whole list, and edit this attachment whenever a commit
is no longer relevant (either dropped, or merged, or rewritten, etc.).


-- 


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

[Bug other/43977] Patches from oldlto branch to be salvaged

[steven at gcc dot gnu dot org]

-- 

steven 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-05-03 18:09:18
   date||


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

[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 -> 4.4 regression, needed for auto-dependencies)

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-05-03 18:09 ---
If real life allows, I'll give it another try for 4.6 - started twice already
but there are quite a few options to handle. However, if you feel like it, dig
in. Help is always welcome :)

Closing as dupe of PR31588.

*** This bug has been marked as a duplicate of 31588 ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options

[dfranke at gcc dot gnu dot org]

--- Comment #12 from dfranke at gcc dot gnu dot org  2010-05-03 18:09 
---
*** Bug 43954 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/43953] [4.5/4.6 regression] ICE: dependent_type_p, at cp/pt.c:17404

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|ICE: dependent_type_p, at   |[4.5/4.6 regression] ICE:
   |cp/pt.c:17404   |dependent_type_p, at
   ||cp/pt.c:17404
   Target Milestone|--- |4.5.1


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

[Bug java/42143] [4.3/4.4/4.5/4.6 Regression] gcj creates "dummy" variables

[glarkin at FreeBSD dot org]

--- Comment #7 from glarkin at FreeBSD dot org  2010-05-03 18:36 ---
(In reply to comment #6)
> So can someone please comment on this?
> 

I recently encountered this problem while using gcc/gcj 4.5 with ecj-4.5.jar to
compile the pdftk utility (http://www.accesspdf.com/pdftk/) on FreeBSD.  I
maintain the pdftk port for FreeBSD, and I previously used gcc/gcj 4.2 with
ecj-4.3.jar without any problems.

I found a workaround by patching the pdftk Makefiles like so:

 ##
 # implicit rules for creating A from B

 %.o : %.java
$(GCJ) $(GCJFLAGS) -c $< -o $@
+   ${OBJCOPY} -L '_ZGr8_$$_dummy' $@

The FreeBSD objcopy command changes the .dummy resource from global scope to
local scope in each .o file.  After doing that, the pdftk link phase succeeded
instead of dying with a ton of "duplicate symbol" errors.

After searching for the source of the duplicate symbol, I think I found it
here:

http://gcc.gnu.org/ml/java-patches/2009-q1/msg00049.html

If the patch included in this message is the source of the duplicate symbol
problem, then I wonder if it could be fixed like so?

String someRandomString = ();
ZipEntry entry = new ZipEntry(".dummy" + someRandomString);

Feedback welcome,
Greg Larkin


-- 

glarkin at FreeBSD dot org changed:

   What|Removed |Added

 CC||glarkin at FreeBSD dot org


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

[Bug java/43302] [Regression] gcc creates "dummy" resources in object files

[glarkin at FreeBSD dot org]

--- Comment #3 from glarkin at FreeBSD dot org  2010-05-03 18:37 ---
(In reply to comment #2)
> Experimenting with -save-temps I noticed that the .dummy resource is in the
> .jar generated by ecj which seems to point to it as the main suspect.
> 

I believe that's correct - please see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143#c7

Thank you,
Greg Larkin


-- 

glarkin at FreeBSD dot org changed:

   What|Removed |Added

 CC||glarkin at FreeBSD dot org


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

[Bug c++/43978] New: dereferencing pointer ���� does break strict-aliasing rules

[musiphil at bawi dot org]

I get this warning while compiling the program below with g++-4.4.3:

$ g++ -O2 -Wall test.cc
test.cc: In function ¡®int main()¡¯:
test:8: warning: dereferencing pointer ¡®¡¯ does break
strict-aliasing
rules
/usr/include/c++/4.4/bits/stl_list.h:214: note: initialized from here

I don't see anything suspicious in the following program, but there
should be a reason for the warning. I asked on comp.lang.c++.moderated:
http://groups.google.com/group/comp.lang.c++.moderated/msg/fa12790662f5279d
but I couldn't get a satisfactory explanation, and someone suggested this
might be a bug of gcc.

I have searched for an existing report of this bug and found many similar
ones, but the sample codes didn't look very relevant to this problem, or
the others compiled fine without the warning. Sorry if this is a duplicate;
please feel free to mark this as a duplicate and point me to the existing
one in that case.

/*  1 */ #include 
/*  2 */
/*  3 */ struct X
/*  4 */ {
/*  5 */struct P
/*  6 */{
/*  7 */const void* p;
/*  8 */bool operator==(const P& o) const { return p == o.p; }
/*  9 */};
/* 10 */
/* 11 */typedef std::list PL;
/* 12 */
/* 13 */struct I
/* 14 */{
/* 15 */PL::const_iterator itr;
/* 16 */bool operator==(I o) const { return *itr == *o.itr; }
/* 17 */bool operator!=(I o) const { return !(*this == o); }
/* 18 */I& operator++() { ++itr; return *this; }
/* 19 */};
/* 20 */
/* 21 */PL list;
/* 22 */
/* 23 */I begin() const { I i = {list.begin()}; return i; }
/* 24 */I end()   const { I i = {list.end()};   return i; }
/* 25 */ };
/* 26 */
/* 27 */ int main()
/* 28 */ {
/* 29 */X x;
/* 30 */for (X::I it = x.begin(); it != x.end(); ++it) { }
/* 31 */ }

Line 214 of /usr/include/c++/4.4/bits/stl_list.h looks like this:

/* 182 */   /**
/* 183 */*  @brief A list::const_iterator.
/* 184 */*
/* 185 */*  All the functions are op overloads.
/* 186 */   */
/* 187 */   template
/* 188 */ struct _List_const_iterator
/* 189 */ {
/* ... */
/* 210 */   // Must downcast from List_node_base to _List_node to get to
/* 211 */   // _M_data.
/* 212 */   reference
/* 213 */   operator*() const
/* 214 */   { return static_cast<_Node*>(_M_node)->_M_data; }
/* ... */
/* 260 */ };

$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--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-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

$ uname -a
Linux localhost 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010
i686 GNU/Linux


-- 
   Summary: dereferencing pointer ¡®¡¯ does break strict-
aliasing rules
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: musiphil at bawi dot org


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

[Bug c++/43978] dereferencing pointer ���� does break strict-aliasing rules

[musiphil at bawi dot org]

--- Comment #1 from musiphil at bawi dot org  2010-05-03 18:48 ---
Created an attachment (id=20549)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20549&action=view)
the source file that triggers the warning


-- 


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

[Bug c++/43978] dereferencing pointer ���� does break strict-aliasing rules

[musiphil at bawi dot org]

--- Comment #2 from musiphil at bawi dot org  2010-05-03 18:48 ---
Created an attachment (id=20550)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20550&action=view)
the preprocessed file


-- 


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

[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 -> 4.4 regression, needed for auto-dependencies)

[kirr at landau dot phys dot spbu dot ru]

--- Comment #2 from kirr at landau dot phys dot spbu dot ru  2010-05-03 
19:23 ---
Daniel, thanks for reply.

As I see it, yes, PR31588 would be handy enhancement, but this bug is different
-- it's a _regression_ -- it used to work in 4.3 and stopped in 4.4.

And when I say "it used to work" I don't mean generating dependencies for
f90/f95 sources (PR31588 mentions e.g. USE), but only generating dependencies
from plain preprocessor.

Please, let's not break what used to work.
Is it ok reopen?


P.S. I'd like to help as time permits, but hacking on GCC codebase is out of my
skills at present. If that would help I'm able and will be glad to try patches
and do other testing as well.

Sorry and thanks,
Kirill


-- 


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

[Bug fortran/40011] Problems with -fwhole-file

[jvdelisle at gcc dot gnu dot org]

--- Comment #54 from jvdelisle at gcc dot gnu dot org  2010-05-03 19:24 
---
We should get the case in comment 40 added to the test suite if not already so
we do not regress it later.


-- 


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

[Bug other/43977] Patches from oldlto branch to be salvaged

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-05-03 19:35 ---
(From update of attachment 20548)
>
>r124989 | olga | 2007-05-23 14:49:49 +0200 (Wed, 23 May 2007)
>
>r124502 | dberlin | 2007-05-07 18:32:09 +0200 (Mon, 07 May 2007)
>
>r123283 | ian | 2007-03-28 01:45:22 +0200 (Wed, 28 Mar 2007)
>
>r118667 | mmitchel | 2006-11-10 23:22:12 +0100 (Fri, 10 Nov 2006)
>
>r117638 | sandra | 2006-10-11 18:35:33 +0200 (Wed, 11 Oct 2006)
>
>r117615 | sandra | 2006-10-10 23:50:59 +0200 (Tue, 10 Oct 2006)
>
>r117606 | sandra | 2006-10-10 19:27:58 +0200 (Tue, 10 Oct 2006)
>
>r117580 | zadeck | 2006-10-09 19:27:31 +0200 (Mon, 09 Oct 2006)
>
>r117359 | sandra | 2006-10-02 02:48:00 +0200 (Mon, 02 Oct 2006)
>
>r117276 | olga | 2006-09-28 13:08:12 +0200 (Thu, 28 Sep 2006)
>
>r117124 | sandra | 2006-09-22 00:55:52 +0200 (Fri, 22 Sep 2006)
>
>r117113 | sandra | 2006-09-21 18:55:30 +0200 (Thu, 21 Sep 2006)
>
>r117107 | pinskia | 2006-09-21 07:19:15 +0200 (Thu, 21 Sep 2006)
>
>r117105 | sandra | 2006-09-21 03:30:17 +0200 (Thu, 21 Sep 2006)
>
>r117073 | pinskia | 2006-09-20 08:45:17 +0200 (Wed, 20 Sep 2006)
>
>r117031 | sandra | 2006-09-18 19:47:55 +0200 (Mon, 18 Sep 2006)
>
>r116947 | sandra | 2006-09-14 17:17:36 +0200 (Thu, 14 Sep 2006)
>
>r116857 | sandra | 2006-09-11 23:06:45 +0200 (Mon, 11 Sep 2006)
>
>r116847 | zadeck | 2006-09-11 15:54:11 +0200 (Mon, 11 Sep 2006)
>
>r116840 | mmitchel | 2006-09-11 07:18:15 +0200 (Mon, 11 Sep 2006)
>
>r116785 | sandra | 2006-09-08 21:55:51 +0200 (Fri, 08 Sep 2006)
>
>r116784 | zadeck | 2006-09-08 20:13:52 +0200 (Fri, 08 Sep 2006)
>
>r116759 | zadeck | 2006-09-07 22:41:49 +0200 (Thu, 07 Sep 2006)
>
>r116713 | pinskia | 2006-09-06 07:12:55 +0200 (Wed, 06 Sep 2006)
>
>r116677 | mmitchel | 2006-09-04 06:50:19 +0200 (Mon, 04 Sep 2006)
>
>r116335 | sandra | 2006-08-23 01:50:50 +0200 (Wed, 23 Aug 2006)
>
>r116181 | sandra | 2006-08-16 17:09:53 +0200 (Wed, 16 Aug 2006)
>
>r116179 | kazu | 2006-08-16 05:00:51 +0200 (Wed, 16 Aug 2006)
>
>r116161 | kazu | 2006-08-15 19:46:35 +0200 (Tue, 15 Aug 2006)
>
>r116156 | sandra | 2006-08-15 17:53:59 +0200 (Tue, 15 Aug 2006)
>
>r116150 | mmitchel | 2006-08-15 08:05:33 +0200 (Tue, 15 Aug 2006)
>
>r116133 | kazu | 2006-08-14 19:49:38 +0200 (Mon, 14 Aug 2006)
>
>r116126 | kazu | 2006-08-14 16:10:20 +0200 (Mon, 14 Aug 2006)
>
>r116125 | kazu | 2006-08-14 15:35:38 +0200 (Mon, 14 Aug 2006)
>
>r116122 | kazu | 2006-08-14 05:43:24 +0200 (Mon, 14 Aug 2006)
>

[Bug other/43977] Patches from oldlto branch to be salvaged

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-05-03 19:36 ---
OK, that didn't work... I'll just comment per revision.


-- 


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

[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 -> 4.4 regression, needed for auto-dependencies)

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-03 19:45 ---
(In reply to comment #2)
On Monday 03 May 2010 21:23:26 you wrote:
> And when I say "it used to work" I don't mean generating dependencies for
> f90/f95 sources (PR31588 mentions e.g. USE), but only generating
> dependencies from plain preprocessor.

What you ask for is "just" a subset of PR31588. If that gets fixed, your
request will be fixed as well.

Feel free to re-open if you believe that it would be worth to fix the subset
first.


> If that would help I'm able and will be glad to try patches and do 
> other testing as well.

I'll keep that in mind :)


-- 


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

[Bug c++/43978] dereferencing pointer ���� does break strict-aliasing rules

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-05-03 19:47 
---
Richard, can you have a look? It is the same as 42032?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug c++/43978] dereferencing pointer ���� does break strict-aliasing rules

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-05-03 19:53 
---
For sure cannot be reproduced with 4.5 and mainline.


-- 


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

[Bug c++/43980] New: Using __sync_fetch_and_add produces linking errors on OpenSolaris

[kgardas at objectsecurity dot com]

Hello,
my gcc is my own built:

$ c++ -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.4.2/configure --prefix=/usr/local/gcc-4.4.2
--with-as=/usr/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld
--enable-shared --enable-threads --enable-languages=c++
--with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr
Thread model: posix
gcc version 4.4.2 (GCC) 

I'm trying to compile as simple as possible __sync_fetch_and_add testcase:

#include 

using namespace std;

int
main()
{
  int x = 2;
  int y = __sync_fetch_and_add(&x, 1);
  cerr << "y: " << y << endl;
  return y;
}

but the problem is that linking of this fails:

$ c++ sync_fetch_and_add_test.cc 
Undefined   first referenced
 symbol in file
__sync_fetch_and_add_4  /var/tmp//cc17aqlv.o
ld: fatal: symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status

I've tried the same on OpenSuSE 11.2 with distro provided GNU C++ 4.4.1 and the
testcase links fine. Is there any known issue why GNU C++ does not support this
on OpenSolaris 2009.06?
Thanks!
Karel


-- 
   Summary: Using __sync_fetch_and_add produces linking errors on
OpenSolaris
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity 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=43980

[Bug c++/43980] Using __sync_fetch_and_add produces linking errors on OpenSolaris

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-03 20:00 ---
I think you need -march=i486 on solaris for this to work.  At least with 4.4. 
Now with 4.5, it is a different story.


-- 


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

[Bug c++/43980] Using __sync_fetch_and_add produces linking errors on OpenSolaris

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-05-03 20:03 
---
I suspect this is just the usual issue with i386, which does not provide the
atomic builtins. You should try with, eg, -march=i486, and if the problem goes
away this is a duplicate of some other 30 PRs ;)


-- 


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

[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2010-05-03 20:03 ---
Mine. I think fixing comment #0 is as easy as the following two-liner:


Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 158970)
+++ gcc/fortran/symbol.c(working copy)
@@ -4720,6 +4720,8 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
 sprintf (name, ".class.%s.%d.a", ts->u.derived->name, (*as)->rank);
   else if ((*as) && (*as)->rank)
 sprintf (name, ".class.%s.%d", ts->u.derived->name, (*as)->rank);
+  else if (attr->pointer)
+sprintf (name, ".class.%s.p", ts->u.derived->name);
   else if (attr->allocatable)
 sprintf (name, ".class.%s.a", ts->u.derived->name);
   else


Apparently this doesn't even induce any testsuite regressions. However, the ICE
in comment #4 will need some additional care.

Btw, the ICE in comment #0 is gone already since fortran-dev has been merged to
trunk.


-- 

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-05-03 20:03:44
   date||


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

[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

[schwab at linux-m68k dot org]

--- Comment #15 from schwab at linux-m68k dot org  2010-05-03 20:17 ---
The patch is ok, please check it in.


-- 


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

[Bug target/42910] invalid memcpy() in trivial tail-call with large struct

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2010-05-03 20:26 ---
This isn't really a different bug.

*** This bug has been marked as a duplicate of 42909 ***


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/42909] inefficient code for trivial tail-call with large struct parameter

[schwab at linux-m68k dot org]

--- Comment #3 from schwab at linux-m68k dot org  2010-05-03 20:26 ---
*** Bug 42910 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/43980] Using __sync_fetch_and_add produces linking errors on OpenSolaris

[kgardas at objectsecurity dot com]

--- Comment #3 from kgardas at objectsecurity dot com  2010-05-03 20:30 
---
Folks,
please close this. Indeed, when I add -march=i486 I get no linker errors
anymore. Thanks for your fast help! Karel


-- 


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

[Bug c++/43980] Using __sync_fetch_and_add produces linking errors on OpenSolaris

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-05-03 20:37 
---
Ok


-- 

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

[Bug other/43977] Patches from oldlto branch to be salvaged

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-05-03 20:46 ---
Created an attachment (id=20551)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20551&action=view)
Ported: r114283 r114291 r114307 r114348 r114396 r114397 r114400 r114401


-- 


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

[Bug c++/43680] [DR 1022] G++ is too aggressive in optimizing away bounds checking with enums

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2010-05-03 21:16 ---
Subject: Bug 43680

Author: jason
Date: Mon May  3 21:16:40 2010
New Revision: 159006

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159006
Log:
PR c++/43680
gcc:
* c.opt (-fstrict-enums): New.
* doc/invoke.texi (C++ Dialect Options): Document -fstrict-enums.
gcc/cp:
* decl.c (finish_enum): Use the TYPE_MIN_VALUE and TYPE_MAX_VALUE
from the selected underlying type unless -fstrict-enums.  Set
ENUM_UNDERLYING_TYPE to have the restricted range.
* cvt.c (type_promotes_to): Use ENUM_UNDERLYING_TYPE.
* class.c (check_bitfield_decl): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/opt/enum2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cvt.c
trunk/gcc/cp/decl.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wswitch-1.C
trunk/gcc/testsuite/g++.dg/warn/pr33738.C


-- 


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

[Bug fortran/42547] Issues in intrinsics.texi documentation

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2010-05-03 21:39 ---
I think my last intrinsic.texi patch fixed all of the
issues raised by James.  Closing with fixed.  If you
find an issue please open a new PR.


r158352 | kargl | 2010-04-14 11:32:51 -0700 (Wed, 14 Apr 2010) | 8 lines

2010-04-14  Steven G. Kargl  

* fortran/intrinsic.texi: Add the missing specific name of intrinsic
procedure where the specific name is identical to the generic name.
Fix inconsistent or mismatch in the argument names in intrinsic
procedure descriptions.  Add the SCALAR allocatable description to
ALLOCATED.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/43729] Mach-O LTO support needed for darwin

[mrs at gcc dot gnu dot org]

--- Comment #37 from mrs at gcc dot gnu dot org  2010-05-03 21:39 ---
First question to decide is what direction they want to go with it, that's an
LTO question.  Once that is decided, if the direction to do is to change
darwin.c, I have given the 3 lines to do that, what remains undone with that
solution is testing, and the correct spelling of LTO_SYM, both of which are LTO
issues.  I could create a patch with the addition of the three lines, but that
isn't any harder than just cutting and pasting the three lines given, I don't
think.  Let me know the spelling and I can.


-- 


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

[Bug c++/43875] [C++0x] ICE on invalid lambda return

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-05-03 21:44 ---
Fixed for 4.5.1.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug testsuite/43758] [4.6 Regression] 19 new GCC h...@158360 regressions

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-03 21:44:59
   date||


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

[Bug target/43729] Mach-O LTO support needed for darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #38 from howarth at nitro dot med dot uc dot edu  2010-05-03 
22:01 ---
Mike,
   I was more interested about the second option since you seem to indicate
that the first option would pessimize the the LTO code generation on i386
darwin. Or did I misunderstand that comment?


-- 


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

[Bug target/43729] Mach-O LTO support needed for darwin

[steven at gcc dot gnu dot org]

--- Comment #39 from steven at gcc dot gnu dot org  2010-05-03 22:15 ---
I still don't understand the 32 bits problem.

Without LTO, there is this code in the for 2008_0.i:
L_mumble$non_lazy_ptr:
.indirect_symbol _mumble

In the WPA code mumble is gone in the code for 2008_1.i (and so is the
whole declaration for mumble) but the .indirect_symbol is also not in the WPA
asm for 2008_0.i.

Something in the darwin backend appears to believe that _mumble has already
been written to the assembler files. 


-- 


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[wilson at codesourcery dot com]

--- Comment #3 from wilson at codesourcery dot com  2010-05-03 22:28 ---
Subject: Re:  suboptimal MIPS widening multiply accumulate

On Tue, 2010-04-27 at 09:33 +, rguenth at gcc dot gnu dot org wrote:
> For more general optimization you might want to move all this code to
> the tree pass before expansion that detects widening multiplication.
> The DOT_PROD_EXPR tree code can be used to carry the information to
> the expander.

I didn't understand the point here at first, but after updating my tree
and rebuilding I now see Bernd's patch to add the new widening_mul
optimization pass which I hadn't noticed before.  The MIPS macc/madd
support is now even more broken than before.  I can generate them at -O
but not at -O2 now, as the code in expand_expr_real_2 doesn't handle
WIDEN_MULT_EXPR which is created at -O2 by the new code.

So as Richard Guenther mentioned, the solution seems to be to remove the
old code in expand_expr_real_2 and add something new in
tree-ssa-math-opt.c to replace it.  This means we won't be able to
generate widening multiply accumulate with -O, but we will at -O2.  This
is probably acceptable, though it makes the solution more complicated
than I had originally expected.

Jim


-- 


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[wilson at gcc dot gnu dot org]

--- Comment #4 from wilson at gcc dot gnu dot org  2010-05-03 22:36 ---
Created an attachment (id=20552)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20552&action=view)
trivial solution for original problem

This fixes the original problem, but does not fix the new breakage caused by
Bernd's patch to add the new optimize_widening_mul pass.  So this works at -O
but not at -O2.


-- 


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

[Bug java/43839] libjava incorrectly uses -liconv in testsuite, jni.exp when using --with-libiconv-prefix

[mrs at gcc dot gnu dot org]

--- Comment #10 from mrs at gcc dot gnu dot org  2010-05-03 22:38 ---
Subject: Bug 43839

Author: mrs
Date: Mon May  3 22:37:50 2010
New Revision: 159009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159009
Log:
PR 43839
* testsuite/Makefile.am: Override automake for site.exp creation
and add entry to set libiconv.
* testsuite/Makefile.in: Regenerate.
* testsuite/libjava.jni/jni.exp (gcj_jni_get_cxxflags_invocation):
Add new global variable libiconv to handle alternative libiconv
locations.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/testsuite/Makefile.am
trunk/libjava/testsuite/Makefile.in
trunk/libjava/testsuite/libjava.jni/jni.exp


-- 


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

[Bug libstdc++/43554] profile-mode version of forward_list missing

[rus at google dot com]

--- Comment #2 from rus at google dot com  2010-05-03 22:46 ---
It's not clear from the description what the problem is here.  The profile mode
doesn't instrument either forward_list or slist at this point, so all
inclusions of  should fall back to normal mode.

Could you please clarify the problem?


-- 

rus at google dot com changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug target/43729] Mach-O LTO support needed for darwin

[mrs at gcc dot gnu dot org]

--- Comment #40 from mrs at gcc dot gnu dot org  2010-05-03 22:47 ---
Jack, if I follow what you want, that's an LTO fix, I don't know the LTO code. 
I don't know that that fix is even possible.  I think one must do the LTO_SYM
fix, if I had to guess.  I don't have the time to embark upon learning all the
LTO bits to that work.


-- 


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

[Bug libstdc++/43554] profile-mode version of forward_list missing

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-05-03 23:06 
---
Silvius, this is not a bug proper, instead an *enhancement* request: it seems
quite obvious to me, if only for consistency, that we want to provide
debug-mode and profile-mode versions of forward_list too, like all the other
containers, no?!?


-- 


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