date:20100902

As reported by Fran,cois-Xavier at
http://gcc.gnu.org/ml/fortran/2010-08/msg00484.html

a)

  integer(kind=8) :: i
  i = 0
  print *, kind(ior (i, z"ff1e"))
  print *, kind(ior (0_8, z"ff1e"))
  end

gives different different results for the compile-time and run-time evaluation.

b) F2008 allows BOZ in bit intrinsics, which need to be properly handled; for
IOR(I,J) one has:
* I or J can be BOZ or integers, but they can't both be BOZ.
* "Result Characteristics. Same as I if I is of type integer; otherwise, same
as J."


-- 
   Summary: BOZ kinds differently handled, F2008: BOZ in bit
intrinsics
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c/45512] New: null pointer dereference in gcc

2010-09-02 Thread regehr at cs dot utah dot edu

[reg...@gamow tmp426]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r163740-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r163740-install
--program-prefix=r163740- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100901 (experimental) (GCC) 

[reg...@gamow tmp426]$ cat small.c

int g_9;
int *g_8 = &g_9;
int g_56;
int *g_209 = &g_56;

int func_103 (int p_104)
{
  if (1 != *g_8)
{
  unsigned char l_107[3];
  g_56 &= l_107[2];
}
  else
for (0; g_56; 0)
  &p_104;
  return p_104;
}

void func_85 (int,int);

void int320 (int * p_51, int p_52, unsigned p_53)
{
  int l;
  func_85 (func_103 (0), *g_209);
  l = func_103 (0);
}

[reg...@gamow tmp426]$ current-gcc -O2 small.c

small.c: In function 'func_103':
small.c:6:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: null pointer dereference in gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 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=45512

[Bug c++/20681] [4.3/4.4/4.5/4.6 Regression] wrong "control reaches" warning with switches



--- Comment #27 from pinskia at gcc dot gnu dot org  2010-09-03 04:53 
---
*** Bug 45497 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/45497] [4.3/4.4/4.5/4.6 Regression] bogus warning at -O0 (control reaches end of non-void function).



--- Comment #5 from pinskia at gcc dot gnu dot org  2010-09-03 04:53 ---
Not to mention t2.cpp is really a dup of bug 20681.  And yes this is a dup of
that bug as this is a switch that is causing issue.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/45497] [4.3/4.4/4.5/4.6 Regression] bogus warning at -O0 (control reaches end of non-void function).



--- Comment #4 from pinskia at gcc dot gnu dot org  2010-09-03 04:51 ---
Reopening as that bug was marked as being fixed in 4.4.0 but this is not.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

2010-09-02 Thread runipg at broadcom dot com

--- Comment #7 from runipg at broadcom dot com  2010-09-03 03:31 ---
Subject: Re:  Bug with anonymous unions and bit-fields

Wow, So there is a diff inside and outside a struct? 

This is very counter-intuitive but I am  to accept your explanation if that's
what the language says. 

Thanks so much for looking into it and responding. Sorry if it is not a bug, I
googled for anything similar before filing it.

-Runip

On 02-Sep-2010, at 6:11 PM, pinskia at gcc dot gnu dot org
 wrote:

> 
> 
> --- Comment #5 from pinskia at gcc dot gnu dot org  2010-09-03 01:10 
> ---
>  union {
>unsigned int a : 1,
>   b : 4;
>unsigned int data;
>  };
> 
> 
> This is an union of three elements each over lapping, that is a:1 overlaps 
> with
> b:4 and data.  So this is expected behavior as far as I can tell.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 

-- 

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

[Bug ada/45499] Ada bootstrap broken



--- Comment #4 from hjl dot tools at gmail dot com  2010-09-03 02:39 ---
(In reply to comment #3)
> Subject: Re:  Ada bootstrap broken
> 
> I don't see where a -Y option would come from or what would accept it.

Y can be any letter from A to Z and a to z. See PR 45504 for an example.


-- 


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

[Bug c++/45509] program abort after compiled with gcc-4.5.1

2010-09-02 Thread howarth at nitro dot med dot uc dot edu



--- Comment #3 from hjl dot tools at gmail dot com  2010-09-03 02:02 ---
It is hard to tell without a small testcase.


-- 


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

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function



--- Comment #41 from howarth at nitro dot med dot uc dot edu  2010-09-03 
01:58 ---
Created an attachment (id=21681)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21681&action=view)
don't redefine MAIN_STACK_BOUNDARY so -fstack-usage can work


-- 


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

[Bug c++/45501] Compiler does not find template function if member is addressed with "this"

2010-09-02 Thread jason at gcc dot gnu dot org



--- Comment #3 from jason at gcc dot gnu dot org  2010-09-03 01:36 ---
prn and this->prn are equivalent.  Specifically, the type of *this is the
current scope, so although it is a dependent type it is not a dependent scope
and .template should not be needed.


-- 

jason 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-09-03 01:36:05
   date||


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

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294



--- Comment #1 from rmansfield at qnx dot com  2010-09-03 01:13 ---
Created an attachment (id=21680)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21680&action=view)
preprocessed source


-- 


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

[Bug c++/45510] Bug with anonymous unions and bit-fields



--- Comment #6 from pinskia at gcc dot gnu dot org  2010-09-03 01:13 ---
You can use a GCC extension of anonymous structs:
struct bfa {
  union {
struct {
unsigned int a : 1,
   b : 4;
};
unsigned int data;
  };
};

To get the behavior you want.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/45511] New: ICE in neon_valid_immediate, at config/arm/arm.c:8294

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnu
--with-headers=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.6.0 20100902 (experimental) [trunk revision 163787] (GCC) 

$ ./xgcc -B. ~/ice.i -c -O3 -ftree-vectorize -mfpu=neon -mfloat-abi=softfp -S
/home/ryan/ice.i: In function 'OverrideFloat16Precisions':
/home/ryan/ice.i:37:59: warning: assignment from incompatible pointer type
[enabled by default]
/home/ryan/ice.i:35:49: internal compiler error: in neon_valid_immediate, at
config/arm/arm.c:8294
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instruction


-- 
   Summary: ICE in neon_valid_immediate, at config/arm/arm.c:8294
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu


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

[Bug c++/45510] Bug with anonymous unions and bit-fields



--- Comment #5 from pinskia at gcc dot gnu dot org  2010-09-03 01:10 ---
  union {
unsigned int a : 1,
   b : 4;
unsigned int data;
  };


This is an union of three elements each over lapping, that is a:1 overlaps with
b:4 and data.  So this is expected behavior as far as I can tell.


-- 


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #4 from paolo dot carlini at oracle dot com  2010-09-03 01:09 
---
Fair enough, but first blush I also don't see any text in the C++ Standard
guaranteeing the behavior you want, wondered if you actually can get it with
other compilers, maybe as implementation defined. Somebody else will properly
triage this PR, anyway...


-- 


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

2010-09-02 Thread runipg at broadcom dot com



--- Comment #3 from runipg at broadcom dot com  2010-09-03 01:03 ---
Subject: Re:  Bug with anonymous unions and bit-fields

That was fast and interesting that two other compilers behave the same. 
Unfortunately I don't have access to any other compiler.  I am simply 
befuddled by the behavior though. I wouldn't file a bug, if I thought it 
was frivolous.

paolo dot carlini at oracle dot com wrote:
> --- Comment #2 from paolo dot carlini at oracle dot com  2010-09-03 00:02 
> ---
> Without having seriously looked into your code, I note that two completely
> different, closed source compilers (ICC and SunStudio) leads to the same
> behavior as GCC at runtime. Does your code actually "work" (behaves like you
> expect) somewhere?
>
>
>   


-- 


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

[Bug ada/45499] Ada bootstrap broken

2010-09-02 Thread joseph at codesourcery dot com



--- Comment #3 from joseph at codesourcery dot com  2010-09-03 00:25 ---
Subject: Re:  Ada bootstrap broken

I don't see where a -Y option would come from or what would accept it.

I can see an issue with some Ada code not accepting the separate arguments 
"-I -".  I'm testing a workaround that makes gcc.c canonicalize -I to 
joined arguments for the purposes of specs, like -L, although the proper 
fix would be for the Ada front-end maintainers to make the Ada front end 
work with decoded options rather than doing fragile reparsing of options 
inside Ada code that is liable to get out of sync with the core compiler's 
notion of what is an option and what is an option argument (or failing 
that, at least to make the Ada code handle -I properly with both joined 
and separate arguments).


-- 


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

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

2010-09-02 Thread mikedalpee at enginsol dot com



--- Comment #15 from mikedalpee at enginsol dot com  2010-09-03 00:24 
---
I have spent a lot more time playing around with this, and after running the
exception1 program numerous times, the behaviour oscillates between working
correctly or not working at all.  So there appears to be some sort of race
condition during the the stack unwinding process that results from a thread
cancellation.  

In particular, it does not appear that the thread is being reliably cancelled
at the pthread_testcancel call - sometimes f2 seems to run beyond the
pthread_testcancel, which causes the throw to execute, and results in an abort
(seems to want to act like an uncaught exception propagated out).  If you
comment out the throw, f2 will sometimes continue to construct additional
objects past 50. I have also noticed that sometimes a bunch of the Y objects
get destructed, but then the program suddenly summarily exits.  I also tried
setting the cancellation type to asynchronous, but that doesn't make any
difference - sometimes it works, sometimes it don't. Its very unpredictable.

In any case, I need someone to tell me if this is the appropriate place to have
aired this particular bug, or would it be better placed in the glibc bugzilla.
I really do need this to work reliably so my 400K+ SLOC port can have a chance
to work without requiring a major redesign of the underlying thread framework.
FYI, this has been working flawlessly under Solaris/Sun Studio C++ for the last
10 years.


-- 


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

[Bug c++/45509] program abort after compiled with gcc-4.5.1

2010-09-02 Thread wung at synopsys dot com



--- Comment #2 from wung at synopsys dot com  2010-09-03 00:07 ---
Hopefully this is what you need.  The info is from the debug build.

Program received signal SIGABRT, Aborted.
0x002a987f425d in raise () from /lib64/tls/libc.so.6
(gdb) where
#0  0x002a987f425d in raise () from /lib64/tls/libc.so.6
#1  0x002a987f5a5e in abort () from /lib64/tls/libc.so.6
#2  0x002a986c1c6a in _Unwind_Resume () from /lib64/libgcc_s.so.1
#3  0x002a959296a7 in Fw::CE::Variant::operator QList (
this=0x2a95c85280) at variant.cpp:2810
#4  0x002a9f249730 in layout::oasisSaveOptions::parseVarList (var=...,
a_compre...@0x7fbfff8aec, a_compa...@0x7fbfff8ae7,
a_modalv...@0x7fbfff8ae6, errString=...) at oasisSaveOptions.cpp:190
#5  0x002a9f248c1e in layout::oasisSaveOptions::toVariant (this=0xf70e00,
a_Var=...) at oasisSaveOptions.cpp:55
#6  0x002a95877880 in defaultInfo (this=0xf6b100, val=..., con=0xf70e00,
publicDefault=true, module=0x0) at default.h:116
#7  0x002a95876ef0 in Fw::Core::DefaultsManager::registerDefault (
name=..., converter=0xf70e00, overwrite=true, value=..., isPublic=true,
module=0x0) at default.cpp:45
#8  0x002a9f168053 in layout::layoutModule::onLoad (this=0xd0c910)
at layoutModule.cpp:3807
#9  0x002a9588809b in Fw::Core::Framework::registerModule (this=0xa48540,
module=0xd0c910) at framework.cpp:691
#10 0x002a95887e68 in Fw::Core::Framework::loadModule (this=0xa48540,
path=...) at framework.cpp:643
#11 0x00417e54 in icwbevApp::init (this=0x7fbfffe8d0) at main.cpp:305
#12 0x00418995 in icwbevGUIApp::init (this=0x7fbfffe890)
at main.cpp:537
#13 0x00418c1b in icwbevGUIApp::createQApplication (this=0x7fbfffe890)
at main.cpp:603
#14 0x002a9741f7cb in TqApplication::exec() ()
   from
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../3rd_party/tq3.0.0/amd64/lib/libtq.so.3
#15 0x00416b0e in main (argc=1, argv=0x7fbfffea58) at main.cpp:723
(gdb) info shared
>FromTo  Syms Read   Shared Object Library
0x002a95556a80  0x002a95566d27  Yes (*) /lib64/ld-linux-x86-64.so.2
0x002a957e4a80  0x002a9595ce18  Yes
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../fw-stage-g/lib/amd64/libframework-g.so
0x002a95c9d9c0  0x002a95cbace8  Yes
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../fw-stage-g/lib/amd64/libsnps_winman.so.1
0x002a95f5f520  0x002a9646fd68  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/3rd_party/qt/4.3.3/amd64/lib/libQtGui.so.4
0x002a96878f70  0x002a9695ace8  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/3rd_party/qt/4.3.3/amd64/lib/libQtCore.so.4
0x002a96bf38a0  0x002a96c34fe8  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/3rd_party/qt/4.3.3/amd64/lib/libQtNetwork.so.4
0x002a96e6e750  0x002a96ee60d8  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../3pty/tcl/8.4/amd64-O/lib/libtcl8.4.so
0x002a9713c4e0  0x002a971d84e8  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../3pty/tcl/8.4/amd64-O/lib/libtk8.4.so
0x002a9741cf10  0x002a9742c918  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../3rd_party/tq3.0.0/amd64/lib/libtq.so.3
0x002a9766a540  0x002a97675448  Yes (*)
/usr/X11R6/lib64/libXext.so.6
0x002a97792880  0x002a97802bb8  Yes (*)
/usr/X11R6/lib64/libX11.so.6
0x002a97976f70  0x002a97984cd8  Yes (*)
/usr/X11R6/lib64/libICE.so.6
0x002a97a8e880  0x002a97a93d98  Yes (*) /usr/X11R6/lib64/libXi.so.6
0x002a97b9caa0  0x002a97ba91c8  Yes (*)
/usr/X11R6/lib64/libXmu.so.6
0x002a97cb01c0  0x002a97cbb0a8  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../fw-stage-g/lib/amd64/libz.so.1
0x002a97dc3f80  0x002a97dc4918  Yes (*) /lib64/libdl.so.2
0x002a97ecc100  0x002a97ed4048  Yes (*) /lib64/tls/libpthread.so.0
0x002a97fe4d90  0x002a9801deb8  Yes
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../fw-stage-g/lib/amd64/libcdpl-g.so
0x002a9822fdf0  0x002a98272b98  Yes (*) /lib64/tls/libm.so.6
0x002a98409e20  0x002a984747d6  Yes
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../fw-stage-g/lib/amd64/libstdc++.so.6
0x002a986bb060  0x002a986c3b08  Yes (*) /lib64/libgcc_s.so.1
0x002a987e2200  0x002a988c0a2c  Yes (*) /lib64/tls/libc.so.6
0x002a98a10f60  0x002a98a4e618  Yes (*)
/remote/ntih12/hdole/p4/test/fw/main/3rd_party/qt/4.3.3/amd64/lib/libQtXml.so.4
0x002a98c6a940  0x002a98c6efc8  Yes (*) /usr/X11R6/lib64/libSM.so.6
0x002a98d729f0  0x002a98d78638  Yes (*)
/usr/X11R6/lib64/libXrender.so.1
0x002a98e7c050  0x002a98e7d5b8  Yes (*)
/usr/X11R6/lib64/libXrandr.so.2
0x002a98f7f500  0x002a98f82308  Yes (*)
/usr/X11R6/lib64/libXfixes.so.3
0x002a99086240  0x002a9908a8e8

[Bug c++/45479] Exceptions not delivered properly after thread cancellation

2010-09-02 Thread mikedalpee at enginsol dot com



--- Comment #14 from mikedalpee at enginsol dot com  2010-09-03 00:05 
---
Created an attachment (id=21679)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21679&action=view)
Program that demostrates the bug


-- 

mikedalpee at enginsol dot com changed:

   What|Removed |Added

  Attachment #21633|0   |1
is obsolete||
  Attachment #21635|0   |1
is obsolete||
  Attachment #21637|0   |1
is obsolete||
  Attachment #21663|0   |1
is obsolete||
  Attachment #21664|0   |1
is obsolete||


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #2 from paolo dot carlini at oracle dot com  2010-09-03 00:02 
---
Without having seriously looked into your code, I note that two completely
different, closed source compilers (ICC and SunStudio) leads to the same
behavior as GCC at runtime. Does your code actually "work" (behaves like you
expect) somewhere?


-- 


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

[Bug c++/45510] New: Bug with anonymous unions and bit-fields

2010-09-02 Thread gcc-bugzilla at gcc dot gnu dot org


I have isolated the problem to a very small test program. 

 There are 2 tests in main, testa builds an anonymous union with
bit-fields in it. testb builds a similar anonymous union but this time with a
named structure in it but otherwise identical members.

 testa gives incorrect results (seems to ignore bit-fields). testb
gives correct results. 

 This is the output of the program.

testa
bf0.data=0
bf0.a=0
bf0.b=0
bf0.data=1
bf0.a=1
bf0.b=1
bf0.data=1
bf0.a=1
bf0.b=1
testb
bf0.data=0
bf0.my.a=0
bf0.my.b=0
bf0.data=1
bf0.my.a=1
bf0.my.b=0
bf0.data=3
bf0.my.a=1
bf0.my.b=1

Environment:
System: Linux lc-sj1-2293 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64


host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ./configure
--prefix=/tools/oss/packages/x86_64-rhel4/gcc/4.1.1 --with-gnu-as
--with-as=/tools/oss/packages/x86_64-rhel4/binutils/default/bin/as
--with-gnu-ld
--with-ld=/tools/oss/packages/x86_64-rhel4/binutils/default/bin/ld
--enable-languages=c,c++,objc

How-To-Repeat:

#include 
using namespace std;

struct bfa {
  union {
unsigned int a : 1,
   b : 4;
unsigned int data;
  };
};

struct bfb {
  struct my_struct {
unsigned int a : 1,
   b : 4;
  };

  union {
my_struct my;
unsigned int data;
  };
};

void
testa()
{
   cout << __func__ << endl;

   bfa bf0;
   bf0.data = 0;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.a=" << bf0.a << endl;
   cout << "bf0.b=" << bf0.b << endl;

   bf0.a = 1;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.a=" << bf0.a << endl;
   cout << "bf0.b=" << hex << bf0.b << endl;

   bf0.b = 1;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.a=" << bf0.a << endl;
   cout << "bf0.b=" << hex << bf0.b << endl;
}

void
testb()
{
   cout << __func__ << endl;

   bfb bf0;
   bf0.data = 0;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.my.a=" << bf0.my.a << endl;
   cout << "bf0.my.b=" << bf0.my.b << endl;

   bf0.my.a = 1;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.my.a=" << bf0.my.a << endl;
   cout << "bf0.my.b=" << hex << bf0.my.b << endl;

   bf0.my.b = 1;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.my.a=" << bf0.my.a << endl;
   cout << "bf0.my.b=" << hex << bf0.my.b << endl;
}

int
main(int argc, char** argv)
{
   testa();
   testb();
   return 0;
}


--- Comment #1 from runipg at broadcom dot com  2010-09-02 23:39 ---
Fix:
As mentioned testb is a work-around for the coding style used in testa.


-- 
   Summary: Bug with anonymous unions and bit-fields
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: runipg at broadcom dot com
 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=45510

[Bug ada/45499] Ada bootstrap broken



--- Comment #2 from hjl dot tools at gmail dot com  2010-09-02 23:32 ---
GCC driver now passes down '-Y XXX=FOO" instead of "-YXXX=FOO".
Ada compiler may not support it.


-- 


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

[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)



--- Comment #41 from manu at gcc dot gnu dot org  2010-09-02 23:10 ---
*** Bug 42884 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tstdenis at elliptictech dot
   ||com


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

[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable



--- Comment #20 from manu at gcc dot gnu dot org  2010-09-02 23:10 ---
The first testcase and the second are different issues. Both of them are old,
known and reported in bugzilla. None of them are trivial to fix. 

GCC developers would wish to make our compiler as powerful as to solve the
halting problem in less than a blink. Unfortunately, time, money, and
contributors willing to work on this particular problem are scarce. If you can
help in some way, please do so. Otherwise, thanks for the report anyway.

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/45085] [4.6 Regression] incorrect -Wuninitialized warning



--- Comment #7 from manu at gcc dot gnu dot org  2010-09-02 22:59 ---
WAITING is for waiting for submitters information. 


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24639
  nThis||
 Status|WAITING |ASSIGNED
   Keywords||patch


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

[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)



--- Comment #40 from manu at gcc dot gnu dot org  2010-09-02 22:50 ---
*** Bug 45493 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tadhunt at gmail dot com


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

[Bug c/45493] -Wuninitialized does not warn



--- Comment #4 from manu at gcc dot gnu dot org  2010-09-02 22:50 ---
CCP is responsible for this.

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/43850] ice: tree code �template_type_parm� is not supported in gimple streams

2010-09-02 Thread andrea dot bigagli at commprove dot com



--- Comment #11 from pinskia at gcc dot gnu dot org  2010-09-02 22:40 
---
(In reply to comment #10)
> What is the changeset that fixed this on trunk? I'd really need to try to 
> patch
> my 4.5.1 if possible bcs this bug is a showstopper for me

LTO is an experimental feature for 4.5.x.  That is it has been tested but there
could be some bugs in it.  It is designed to be able to test it and see the
improvements that are coming.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ice: tree code  |ice: tree code
   |template_type_parm is not |ï¿½template_type_parmï¿½ is
   |supported in gimple streams |not supported in gimple
   ||streams


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

[Bug c++/43850] ice: tree code ï¿½template_type_parmï¿½ is not supported in gimple streams



--- Comment #10 from andrea dot bigagli at commprove dot com  2010-09-02 
22:38 ---
What is the changeset that fixed this on trunk? I'd really need to try to patch
my 4.5.1 if possible bcs this bug is a showstopper for me


-- 


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

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined

2010-09-02 Thread r dot j dot hogan at reading dot ac dot uk



--- Comment #5 from r dot j dot hogan at reading dot ac dot uk  2010-09-02 
22:34 ---
Subject: Re:  Passing multi-dimensional array to function using
 C99 VLA function parameter format fails if function is inlined

Of course, that's fine.

On Thu, 2 Sep 2010, paolo dot carlini at oracle dot com wrote:

> 
> 
> --- Comment #4 from paolo dot carlini at oracle dot com  2010-09-02 22:31 
> ---
> Note that if the problem affects only the GCC delivered with that SUSE distro
> should be reported to SUSE, not here. Personally, I can't reproduce it with
> stock 4.3.2 or 4.3.3 or current FSF releases from 4.4 or 4.5 branches, thus
> unless we have contrary evidence this PR will be closed soon, I'm sorry.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45502
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 

-
Robin J. Hogan
Room 2L77  Tel: +44 118 378 6416
Dept of MeteorologyFax: +44 118 378 8905
University of ReadingEmail: r.j.ho...@reading.ac.uk
PO Box 243 Web: www.met.rdg.ac.uk/clouds
READING RG6 6BB, UK
-


-- 


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

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #4 from paolo dot carlini at oracle dot com  2010-09-02 22:31 
---
Note that if the problem affects only the GCC delivered with that SUSE distro
should be reported to SUSE, not here. Personally, I can't reproduce it with
stock 4.3.2 or 4.3.3 or current FSF releases from 4.4 or 4.5 branches, thus
unless we have contrary evidence this PR will be closed soon, I'm sorry.


-- 


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

[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?

2010-09-02 Thread r dot j dot hogan at reading dot ac dot uk



--- Comment #4 from pinskia at gcc dot gnu dot org  2010-09-02 22:28 ---
The problem with the configure is the libgcc specs are very target dependent. 
Anyways I don't see the issue with using -R in a wrapper script and while
bootstrapping in LIB_CFLAGS="-R" .


-- 


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

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined



--- Comment #3 from r dot j dot hogan at reading dot ac dot uk  2010-09-02 
22:16 ---
Subject: Re:  Passing multi-dimensional array to function using
 C99 VLA function parameter format fails if function is inlined

Thanks - I guess it must be quite specific to that build - I've now tested 
some other x86_64 machines with the same version of SuSE and they do show 
the bug, but the other machines I've tried don't:

i586-suse-linux gcc-4.2.1
i386-redhat-linux gcc-4.1.2
sparc-sun-solaris2.8 gcc-3.2.2

Robin.


On Thu, 2 Sep 2010, paolo dot carlini at oracle dot com wrote:

> 
> 
> --- Comment #2 from paolo dot carlini at oracle dot com  2010-09-02 18:35 
> ---
> I can't reproduce this with FSF 4.3.2, neither 4.3.3, neither anything more
> recent.
> 
> 
> -- 
> 
> paolo dot carlini at oracle dot com changed:
> 
>What|Removed |Added
> 
>  CC|r dot j dot hogan at reading|
>|dot ac dot uk   |
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45502
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You reported the bug, or are watching the reporter.
> You are on the CC list for the bug, or are watching someone who is.
> 

-
Robin J. Hogan
Room 2L77  Tel: +44 118 378 6416
Dept of MeteorologyFax: +44 118 378 8905
University of ReadingEmail: r.j.ho...@reading.ac.uk
PO Box 243 Web: www.met.rdg.ac.uk/clouds
READING RG6 6BB, UK
-


-- 


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

[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table

2010-09-02 Thread ebotcazou at gcc dot gnu dot org



--- Comment #4 from ebotcazou at gcc dot gnu dot org  2010-09-02 21:59 
---
It's IVOPTS so no way to get a reduced testcase.  The analysis is for the stock
sem_aggr.adb file compiled at -O2 -gnatpg for IA-64.  We have:

table.68_174 = .builtin_alloca (D.5147_173);

with pi->align = 16

  D.5252_266 = &*table.68_174;

with pi->align = 16 and then

 MEM[(struct sem_aggr__case_bounds[(size_type) .P_BOUNDS->LB0:.P_BOUNDS->UB0 >= .P_BOUNDS->LB0 ? (size_type) .P_BOUNDS->UB0 : (size_type)
.P_BOUNDS->LB0 + -1]
*)D.5252_266][D.6519_896]{lb: 1 sz: 12};

is replaced with

MEM[(struct sem_aggr__case_bounds[(size_type) .P_BOUNDS->LB0:.P_BOUNDS->UB0 >= .P_BOUNDS->LB0 ? (size_type) .P_BOUNDS->UB0 : (size_type)
.P_BOUNDS->LB0 + -1]
*)D.6658_890]

in IVOPTS.  And copy_ref_info reads:

  /* We can transfer points-to information from an old pointer
 or decl base to the new one.  */

But now duplicate_ssa_name_ptr_info duplicates more than the points-to info,
it also duplicates the alignment info, which is wrong for arrays since the
base decl (pointed to by D.5252_266) can be more aligned than the individual
elements (pointed to by D.6658_890).

Tentative patch (I cannot test it on IA-64 before next week):

Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c  (revision 163745)
+++ tree-ssa-loop-ivopts.c  (working copy)
@@ -5891,8 +5891,8 @@ copy_ref_info (tree new_ref, tree old_re
   else if (TREE_CODE (new_ref) == MEM_REF)
 new_ptr_base = TREE_OPERAND (new_ref, 0);

-  /* We can transfer points-to information from an old pointer
- or decl base to the new one.  */
+  /* We can transfer points-to information from an old pointer or base decl
+ to the new one, as well as some amount of alignment information.  */
   if (new_ptr_base
   && TREE_CODE (new_ptr_base) == SSA_NAME
   && POINTER_TYPE_P (TREE_TYPE (new_ptr_base))
@@ -5901,11 +5901,18 @@ copy_ref_info (tree new_ref, tree old_re
   tree base = get_base_address (old_ref);
   if (!base)
;
-  else if ((INDIRECT_REF_P (base)
-   || TREE_CODE (base) == MEM_REF)
-  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME)
-   duplicate_ssa_name_ptr_info
- (new_ptr_base, SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0)));
+  else if ((INDIRECT_REF_P (base) || TREE_CODE (base) == MEM_REF)
+  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
+  && SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0)))
+   {
+ struct ptr_info_def *pi;
+ duplicate_ssa_name_ptr_info
+   (new_ptr_base, SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0)));
+ pi = SSA_NAME_PTR_INFO (new_ptr_base);
+ pi->misalign
+   = -(TYPE_ALIGN (TREE_TYPE (new_ref)) / BITS_PER_UNIT)
+ & (pi->align - 1);
+   }
   else if (TREE_CODE (base) == VAR_DECL
   || TREE_CODE (base) == PARM_DECL
   || TREE_CODE (base) == RESULT_DECL)


-- 


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

[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table

2010-09-02 Thread ebotcazou at gcc dot gnu dot org



--- Comment #3 from ebotcazou at gcc dot gnu dot org  2010-09-02 21:54 
---
Recategorizing.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|ada |tree-optimization


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

[Bug c++/45509] program abort after compiled with gcc-4.5.1



--- Comment #1 from hjl dot tools at gmail dot com  2010-09-02 21:53 ---
Which libstdc++ is used at run-time? Please do

(gdb) info shared


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug java/45504] [4.6 Regression] Failed to bootstrap



--- Comment #5 from hjl dot tools at gmail dot com  2010-09-02 21:47 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00192.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||09/msg00192.html
   Target Milestone|--- |4.6.0


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

[Bug ada/45499] Ada bootstrap broken



--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-02 21:47 ---
I guess this is related to the recent option handling changes.  At least, it
worked fine yesterday and doesn't work today (I only see a-strunb.ads issues
myself).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg

2010-09-02 Thread kargl at gcc dot gnu dot org



--- Comment #5 from kargl at gcc dot gnu dot org  2010-09-02 21:46 ---
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00190.html


-- 


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

[Bug java/45504] [4.6 Regression] Failed to bootstrap



--- Comment #4 from hjl dot tools at gmail dot com  2010-09-02 21:38 ---
gcj used to pass -DXXX=XXX to jvgenmain.  Now it passes
"-D XXX=XXX" to jvgenmain.  But jvgenmain doesn't like it.


-- 


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

[Bug java/45504] [4.6 Regression] Failed to bootstrap



--- Comment #3 from hjl dot tools at gmail dot com  2010-09-02 21:16 ---
The problem is "-D XXX=XXX" no longer works:

[...@gnu-17 libjava]$ /export/build/gnu/gcc/build-i686-linux/./gcc/jvgenmain
-findirect-dispatch -D java.class.path=/usr/gcc-4.6/share/java/ecj.jar
org.eclipse.jdt.internal.compiler.batch.GCCMainmain
org.eclipse.jdt.internal.compiler.batch.GCCMainmain.i
Usage: /export/build/gnu/gcc/build-i686-linux/./gcc/jvgenmain [OPTIONS]...
CLASSNAMEmain [OUTFILE]

"-DXXX=XXX" works:

[...@gnu-17 libjava]$ /export/build/gnu/gcc/build-i686-linux/./gcc/jvgenmain
-findirect-dispatch -Djava.class.path=/usr/gcc-4.6/share/java/ecj.jar
org.eclipse.jdt.internal.compiler.batch.GCCMainmain
org.eclipse.jdt.internal.compiler.batch.GCCMainmain.i
[...@gnu-17 libjava]$ 


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-02 21:16:46
   date||


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

[Bug c++/45509] New: program abort after compiled with gcc-4.5.1

2010-09-02 Thread wung at synopsys dot com

Our program got an exception and abort when compiled and run on RHEL 4.6 with
gcc 4.5.1. It got this mysterious stack trace. It seems to occur due to
_Unwind_Resume doing something odd here.  
This code works with the gcc4.2.2 compiler.

#0  0x002a9890725d in raise () from /lib64/tls/libc.so.6
#1  0x002a98908a5e in abort () from /lib64/tls/libc.so.6
#2  0x002a987d4c6a in _Unwind_Resume () from /lib64/libgcc_s.so.1
#3  0x002a95941edd in Fw::CE::Variant::operator QList (
this=0x2a95b853e0) at variant.cpp:2477
#4  0x002a9f49e8a0 in layout::oasisSaveOptions::parseVarList (var=...,
a_compre...@0x7fbfff8a7c, a_compa...@0x7fbfff8a77,
a_modalv...@0x7fbfff8a76, errString=...) at oasisSaveOptions.cpp:184
#5  0x002a9f49de5a in layout::oasisSaveOptions::toVariant (this=0xfb9f80,
a_Var=...) at oasisSaveOptions.cpp:54
#6  0x002a9588f82c in defaultInfo (this=0xfb63e0, val=..., con=0xfb9f80,
publicDefault=true, module=0x0) at default.h:116
#7  0x002a9588ee9c in Fw::Core::DefaultsManager::registerDefault (
name=..., converter=0xfb9f80, overwrite=true, value=..., isPublic=true,
module=0x0) at default.cpp:45
#8  0x002a9f3bf8c7 in layout::layoutModule::onLoad (this=0xd5c960)
at layoutModule.cpp:3799
#9  0x002a958a0207 in Fw::Core::Framework::registerModule (this=0xaab1a0,
module=0xd5c960) at framework.cpp:688
#10 0x002a9589ffd4 in Fw::Core::Framework::loadModule (this=0xaab1a0,
path=...) at framework.cpp:640
#11 0x004182e6 in icwbevApp::init (this=0x7fbfffe870) at main.cpp:305
#12 0x00418e4d in icwbevGUIApp::init (this=0x7fbfffe830)
at main.cpp:531
#13 0x004190d3 in icwbevGUIApp::createQApplication (this=0x7fbfffe830)
at main.cpp:597
#14 0x002a9753a7cb in TqApplication::exec() ()
   from
/remote/ntih12/hdole/p4/test/fw/main/src/icwbev/../../3rd_party/tq3.0.0/amd64/lib/libtq.so.3
#15 0x00416fbe in main (argc=1, argv=0x7fbfffe9f8) at main.cpp:714

Even if we use the libgcc_s.so.1 that comes with the gcc 4.5.1, the program
gets the same abort.
Please provide some advices to this problem.

Gcc-4.5.1 was built on RHEL 4.6 O.S with the following configure switches:
Configured with: ../../src/gcc-4.5.1/configure
--prefix=/remote/depotsrc/depotsrc/amd64-2.4/local_install/gcc-4.5.1
--enable-bootstrap --enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran --disable-libgcj --with-cpu=generic
--build=x86_64-redhat-linux
Thread model: posix



-Seto


-- 
   Summary: program abort after compiled with gcc-4.5.1
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wung at synopsys dot com
 GCC build triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

2010-09-02 Thread mikpe at it dot uu dot se



--- Comment #2 from mikpe at it dot uu dot se  2010-09-02 20:55 ---
(In reply to comment #1)
> With r163667 and fixes for PR45444 applied I don't see issues with a v7-a
> bootstrap. Can we see if a later version works for you ? 

With r163777 and the proposed PR45444 fix applied I still get the same
bootstrap comparison failures after stage3 as before.

Your v7-a build probably triggers different code generation paths than my
armv5te with xscale tuning build.


-- 


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

[Bug java/45504] [4.6 Regression] Failed to bootstrap

2010-09-02 Thread dominiq at lps dot ens dot fr



--- Comment #2 from dominiq at lps dot ens dot fr  2010-09-02 20:54 ---
The failure is:

[macbook] i386/libjava% /opt/gcc/build_w/./gcc/gcj
-B/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/
-B/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/
-B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem
/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include -isystem
/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include -m32 -ffloat-store
-fomit-frame-pointer -g -O2 -m32 -m32 -o .libs/ecjx -findirect-dispatch
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain
-Djava.class.path=/opt/gcc/gcc4.6w/share/java/ecj.jar ecjx.o
-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava ./.libs/libgcj.dylib
-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src/.libs -ldl
-lz -v 
Reading specs from /opt/gcc/build_w/./gcc/specs
Reading specs from
/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=/opt/gcc/build_w/./gcc/gcj
COLLECT_LTO_WRAPPER=/opt/gcc/build_w/./gcc/lto-wrapper
Target: x86_64-apple-darwin10.4.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc4.6w
--enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64
--with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64
--enable-lto
Thread model: posix
gcc version 4.6.0 20100902 (experimental) [trunk revision 163785p5] (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-B'
'/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/' '-B'
'/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/' '-B'
'/opt/gcc/build_w/./gcc/' '-B'
'/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/' '-B'
'/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/' '-isystem'
'/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include' '-isystem'
'/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include' '-ffloat-store'
'-fomit-frame-pointer' '-g' '-O2' '-m32' '-o' '.libs/ecjx'
'-findirect-dispatch' '-D'
'java.class.path=/opt/gcc/gcc4.6w/share/java/ecj.jar'
'-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/.libs'
'-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava'
'-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src'
'-L/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src/.libs' '-v'
'-fbootclasspath=/sw64/share/java/antlr/antlr.jar:/sw64/share/java/bcel/bcel-5.2.jar:/sw64/share/java/commons-logging/commons-logging-adapters.jar:/sw64/share/java/commons-logging/commons-logging-api.jar:/sw64/share/java/commons-logging/commons-logging.jar:/sw64/share/java/commons-net/commons-net.jar:/sw64/share/java/freetts/cmu_time_awb.jar:/sw64/share/java/freetts/cmu_us_kal.jar:/sw64/share/java/freetts/cmudict04.jar:/sw64/share/java/freetts/cmulex.jar:/sw64/share/java/freetts/cmutimelex.jar:/sw64/share/java/freetts/en_us.jar:/sw64/share/java/freetts/freetts-jsapi10.jar:/sw64/share/java/freetts/freetts.jar:/sw64/share/java/jaf/activation.jar:/sw64/share/java/jakarta-bsf/bsf.jar:/sw64/share/java/jakarta-oro/jakarta-oro.jar:/sw64/share/java/jakarta-regexp/jakarta-regexp.jar:/sw64/share/java/jakarta-servletapi/servlet.jar:/sw64/share/java/javamail/dsn.jar:/sw64/share/java/javamail/imap.jar:/sw64/share/java/javamail/mail.jar:/sw64/share/java/javamail/mailapi.jar:/sw64/share/java/javamail/pop3.jar:/sw64/share/java/javamail/smtp.jar:/sw64/share/java/jdepend/jdepend.jar:/sw64/share/java/jsapi/jsapi.jar:/sw64/share/java/jsch/jsch.jar:/sw64/share/java/junit/junit.jar:/sw64/share/java/jzlib/jzlib.jar:/sw64/share/java/log4j/log4j.jar:/sw64/share/java/netrexx/NetRexxC.jar:/sw64/share/java/netrexx/NetRexxR.jar:/sw64/share/java/rhino/js.jar:/sw64/share/java/saxon-b/saxon8-dom.jar:/sw64/share/java/saxon-b/saxon8-dom4j.jar:/sw64/share/java/saxon-b/saxon8-jdom.jar:/sw64/share/java/saxon-b/saxon8-sql.jar:/sw64/share/java/saxon-b/saxon8-xom.jar:/sw64/share/java/saxon-b/saxon8-xpath.jar:/sw64/share/java/saxon-b/saxon8-xqj.jar:/sw64/share/java/saxon-b/saxon8.jar:/sw64/share/java/stax/stax-1.2.0_rc1-dev.jar:/sw64/share/java/stax/stax-api-1.0.jar:/sw64/share/java/stylebook/stylebook-1.0-b3_xalan-2.jar:/sw64/share/java/xalan-j/serializer.jar:/sw64/share/java/xalan-j/xalan.jar:/sw64/share/java/xerces-j/resolver.jar:/sw64/share/java/xerces-j/serializer.jar:/sw64/share/java/xerces-j/xercesImpl.jar:/sw64/share/java/xerces-j/xercesSamples.jar:/sw64/share/java/xerces-j/xml-apis.jar:/sw64/share/java

[Bug c++/45462] Bad optimization in -O3 sometimes

2010-09-02 Thread yotambarnoy at gmail dot com



--- Comment #14 from yotambarnoy at gmail dot com  2010-09-02 20:47 ---
Getting back to the original question, I did some reading online and I can't
figure out why this breaks the strict aliasing rules. 

Isn't void * some kind of special case? Shouldn't I be able to convert it to
whatever I need within the function without breaking aliasing? 

I think the problem is that gcc assumes that I want alignment (for the uint32 *
inside the struct) and doesn't realize I've used PACKED, so it decides that
it's undefined behavior. What do you guys think? This aliasing topic is so
confusing.


-- 


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

[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?

2010-09-02 Thread nicolai dot stange at zmaw dot de



--- Comment #3 from nicolai dot stange at zmaw dot de  2010-09-02 20:15 
---
> You could use a small wrapper script that adds R option instead of a  
> specs file or adds the specs file to the command line.
This would change nothing:
- The bootstrapping problem remains
- Whether I add a specs file or a wrapper script for every gcc release's
deployment doesn't make a great difference (except that I would not have to
check the default specs for changes every time)

It is not a question whether it is possible to work around it (I've already
done it), but whether it would be good to provide a more convenient way and
whether enough people would benefit from this patch to justify it.


-- 


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

[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg

2010-09-02 Thread kargl at gcc dot gnu dot org



--- Comment #4 from kargl at gcc dot gnu dot org  2010-09-02 20:12 ---
I may have a patch for this one.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-02 11:32:28 |2010-09-02 20:13:00
   date||


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

[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)

2010-09-02 Thread janus at gcc dot gnu dot org



--- Comment #3 from janus at gcc dot gnu dot org  2010-09-02 19:59 ---
(In reply to comment #1)
> Reduced test case:

Sorry, I messed this one up. Should be:


use, intrinsic :: iso_c_binding
type :: cType
  type(c_ptr) :: accelPtr = c_null_ptr
end type cType
type(cType), allocatable, dimension(:) :: filters
allocate(filters(1))
end 


-- 


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

[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?

2010-09-02 Thread pinskia at gmail dot com



--- Comment #2 from pinskia at gmail dot com  2010-09-02 19:55 ---
Subject: Re:   New: Does adding configure-options for specs-hardcoding make
sense?

You could use a small wrapper script that adds R option instead of a  
specs file or adds the specs file to the command line.

On Sep 2, 2010, at 12:48 PM, "nicolai dot stange at zmaw dot de"
 wrote:

> Hi everybody,
>
> I'm not involved in any gcc development nor am I familiar with gcc  
> and its
> components and thus, the attached patch is just a place to start  
> from if you
> agree with me that my request for adding more control over the specs  
> via
> configure options makes sense.
>
> My problem is this one:
> At our site, we provide many versions of several compilers,  
> including the great
> GCC, at non-standard locations. The problem is with the runtime  
> search paths
> for the libgcc_s, ...: The runtime linker always finds the most  
> wrong one: The
> one from Blastwave in /opt/csw/lib (this is Solaris-specific, but if  
> it were
> Linux or sth. other, it would also find the wrong libgcc_s, shipped  
> with the
> distribution, or none at all).
>
> Asking the kind guys in #gcc at freenode, they told me that I might  
> want to
> supply a specs file. Hmm, I want to set site-wide specs for all users
> transparently. Reading the sourcecode of gcc, I recognized that I  
> can put a
> complete specs file to /lib/gcc///specs.
> (I didn't find any documentation about that feature, so maybe this  
> lack of docs
> is another bug?).
>
> But this solution has two drawbacks for me:
> - I'm bootstrapping and the linking of the runtime libraries for the  
> target
> would not be influenced by placing this specs-file _after_  
> installation. Ok, I
> could go with LDFLAGS_FOR_TARGET, but this would make the whole  
> thing more
> non-convenient (at least in my opionion).
> - Creating that specs-file for every GCC-release makes automating  
> the GCC
> deployment harder: At first I have to check if the default-specs are  
> still the
> same, the I have to modify them to insert a runtime search path for  
> the new
> installation location and then I have to put it at the right  
> location. It seems
> that I have to exercise some bash/sed/diff/m4-tasks...
>
> Another solution would be this:
> Adding a --with-link-libgcc-specs option to the configure in the
> gcc-subdirectory, I could configure gcc with
> ../gcc-4.5.1/configure
> --with-link-libgcc-specs="\${!m64:-R/opt/gcc-4.5.1/lib}\${m64:-R/opt/ 
> gcc-4.5.1/lib/sparcv9}"
> ...
> (btw: "-R" is the "-rpath"-equivalent of the Sun Linker on Solaris)
>
> If this user-supplied spec would be prepended/appended to the default
> link_libgcc spec, all would be fine.
>
> The attached patch is for link_libgcc spec only, but maybe altering  
> the other
> specs by configure-options might be useful for other people under  
> other
> circumstances, too?
>
> Please note again, that the attached patch is just a quick hack, if  
> you agree
> to add those options, one should have a closer look.
>
> Best wishes
>
> Nicolai
>
>
> -- 
>   Summary: Does adding configure-options for specs- 
> hardcoding make
>sense?
>   Product: gcc
>   Version: 4.5.1
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: middle-end
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: nicolai dot stange at zmaw dot de
> GCC build triplet: sparc-sun-solaris2.10
>  GCC host triplet: sparc-sun-solaris2.10
> GCC target triplet: sparc-sun-solaris2.10
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
>


-- 


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

Re: [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense?

2010-09-02 Thread Andrew Pinski

You could use a small wrapper script that adds R option instead of a  
specs file or adds the specs file to the command line.


On Sep 2, 2010, at 12:48 PM, "nicolai dot stange at zmaw dot de" > wrote:



Hi everybody,

I'm not involved in any gcc development nor am I familiar with gcc  
and its
components and thus, the attached patch is just a place to start  
from if you
agree with me that my request for adding more control over the specs  
via

configure options makes sense.

My problem is this one:
At our site, we provide many versions of several compilers,  
including the great
GCC, at non-standard locations. The problem is with the runtime  
search paths
for the libgcc_s, ...: The runtime linker always finds the most  
wrong one: The
one from Blastwave in /opt/csw/lib (this is Solaris-specific, but if  
it were
Linux or sth. other, it would also find the wrong libgcc_s, shipped  
with the

distribution, or none at all).

Asking the kind guys in #gcc at freenode, they told me that I might  
want to

supply a specs file. Hmm, I want to set site-wide specs for all users
transparently. Reading the sourcecode of gcc, I recognized that I  
can put a

complete specs file to /lib/gcc///specs.
(I didn't find any documentation about that feature, so maybe this  
lack of docs

is another bug?).

But this solution has two drawbacks for me:
- I'm bootstrapping and the linking of the runtime libraries for the  
target
would not be influenced by placing this specs-file _after_  
installation. Ok, I
could go with LDFLAGS_FOR_TARGET, but this would make the whole  
thing more

non-convenient (at least in my opionion).
- Creating that specs-file for every GCC-release makes automating  
the GCC
deployment harder: At first I have to check if the default-specs are  
still the
same, the I have to modify them to insert a runtime search path for  
the new
installation location and then I have to put it at the right  
location. It seems

that I have to exercise some bash/sed/diff/m4-tasks...

Another solution would be this:
Adding a --with-link-libgcc-specs option to the configure in the
gcc-subdirectory, I could configure gcc with
../gcc-4.5.1/configure
--with-link-libgcc-specs="\${!m64:-R/opt/gcc-4.5.1/lib}\${m64:-R/opt/ 
gcc-4.5.1/lib/sparcv9}"

...
(btw: "-R" is the "-rpath"-equivalent of the Sun Linker on Solaris)

If this user-supplied spec would be prepended/appended to the default
link_libgcc spec, all would be fine.

The attached patch is for link_libgcc spec only, but maybe altering  
the other
specs by configure-options might be useful for other people under  
other

circumstances, too?

Please note again, that the attached patch is just a quick hack, if  
you agree

to add those options, one should have a closer look.

Best wishes

Nicolai


--
  Summary: Does adding configure-options for specs- 
hardcoding make

   sense?
  Product: gcc
  Version: 4.5.1
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: middle-end
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: nicolai dot stange at zmaw dot de
GCC build triplet: sparc-sun-solaris2.10
 GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


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

[Bug tree-optimization/45506] tree_mem_ref_addr, at tree-ssa-address.c:278



--- Comment #2 from hjl dot tools at gmail dot com  2010-09-02 19:49 ---
It is caused by revision 163733:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00024.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-02 19:49:24
   date||
Summary| tree_mem_ref_addr, at tree-|tree_mem_ref_addr, at tree-
   |ssa-address.c:278   |ssa-address.c:278
   Target Milestone|--- |4.6.0


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

[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?

2010-09-02 Thread nicolai dot stange at zmaw dot de



--- Comment #1 from nicolai dot stange at zmaw dot de  2010-09-02 19:49 
---
Created an attachment (id=21678)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21678&action=view)
Adds --with-link-libgcc-specs to gcc-4.5.1/gcc/configure

Made against release 4.5.1


-- 


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

[Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense?

2010-09-02 Thread nicolai dot stange at zmaw dot de

Hi everybody,

I'm not involved in any gcc development nor am I familiar with gcc and its
components and thus, the attached patch is just a place to start from if you
agree with me that my request for adding more control over the specs via
configure options makes sense.

My problem is this one:
At our site, we provide many versions of several compilers, including the great
GCC, at non-standard locations. The problem is with the runtime search paths
for the libgcc_s, ...: The runtime linker always finds the most wrong one: The
one from Blastwave in /opt/csw/lib (this is Solaris-specific, but if it were
Linux or sth. other, it would also find the wrong libgcc_s, shipped with the
distribution, or none at all).

Asking the kind guys in #gcc at freenode, they told me that I might want to
supply a specs file. Hmm, I want to set site-wide specs for all users
transparently. Reading the sourcecode of gcc, I recognized that I can put a
complete specs file to /lib/gcc///specs.
(I didn't find any documentation about that feature, so maybe this lack of docs
is another bug?).

But this solution has two drawbacks for me:
- I'm bootstrapping and the linking of the runtime libraries for the target
would not be influenced by placing this specs-file _after_ installation. Ok, I
could go with LDFLAGS_FOR_TARGET, but this would make the whole thing more
non-convenient (at least in my opionion).
- Creating that specs-file for every GCC-release makes automating the GCC
deployment harder: At first I have to check if the default-specs are still the
same, the I have to modify them to insert a runtime search path for the new
installation location and then I have to put it at the right location. It seems
that I have to exercise some bash/sed/diff/m4-tasks...

Another solution would be this:
Adding a --with-link-libgcc-specs option to the configure in the
gcc-subdirectory, I could configure gcc with
../gcc-4.5.1/configure
--with-link-libgcc-specs="\${!m64:-R/opt/gcc-4.5.1/lib}\${m64:-R/opt/gcc-4.5.1/lib/sparcv9}"
...
(btw: "-R" is the "-rpath"-equivalent of the Sun Linker on Solaris)

If this user-supplied spec would be prepended/appended to the default
link_libgcc spec, all would be fine.

The attached patch is for link_libgcc spec only, but maybe altering the other
specs by configure-options might be useful for other people under other
circumstances, too?

Please note again, that the attached patch is just a quick hack, if you agree
to add those options, one should have a closer look.

Best wishes

Nicolai

--
Summary: Does adding configure-options for specs-hardcoding make
sense?
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolai dot stange at zmaw dot de
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10

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

[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)



--- Comment #2 from burnus at gcc dot gnu dot org  2010-09-02 19:47 ---
Forgot to mention: Initial report and test case was by Andrew Benson (thanks!)

Janus reported that the culprit is Rev. 163744
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163744
which is the patch for PR fortran/44541


-- 


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

[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)

2010-09-02 Thread janus at gcc dot gnu dot org



--- Comment #1 from janus at gcc dot gnu dot org  2010-09-02 19:45 ---
Reduced test case:

use, intrinsic :: iso_c_binding
type :: cType
  type(c_ptr) :: accelPtr => c_null_ptr
end type cType
type(cType), allocatable, dimension(:) :: filters
allocate(filters(1))
end


The failure was supposedly introduced by r163744.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-02 19:45:28
   date||


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

[Bug fortran/36931] unneeded temporary for array intrinsic binop scalar

2010-09-02 Thread tkoenig at gcc dot gnu dot org



--- Comment #4 from tkoenig at gcc dot gnu dot org  2010-09-02 19:33 ---
Working on it.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2010-05-09 20:32:32 |2010-09-02 19:33:43
   date||


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

[Bug fortran/45507] New: [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)

Reported at http://gcc.gnu.org/ml/fortran/2010-09/msg00061.html

Working: 163780 / 163718
Failing: 163661 / 163773

Error: Can't convert TYPE(c_ptr) to INTEGER(4)


module filter
  use, intrinsic :: iso_c_binding
  type :: cType
 type(c_ptr) :: accelPtr = c_null_ptr
  end type cType
  type filterType
 type(cType) :: accel
  end type filterType
  type(filterType), allocatable, dimension(:) :: filters
contains
  subroutine load()
allocate(filters(1))
return
  end subroutine load
end module filter


-- 
   Summary: [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr)
to INTEGER(4)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #2 from paolo dot carlini at oracle dot com  2010-09-02 18:35 
---
I can't reproduce this with FSF 4.3.2, neither 4.3.3, neither anything more
recent.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|r dot j dot hogan at reading|
   |dot ac dot uk   |


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

[Bug tree-optimization/45506] tree_mem_ref_addr, at tree-ssa-address.c:278



--- Comment #1 from rmansfield at qnx dot com  2010-09-02 18:33 ---
Created an attachment (id=21676)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21676&action=view)
preprocessed source


-- 


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

[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi



--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-02 18:33 ---
Created an attachment (id=21677)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21677&action=view)
gcc46-pr45500.patch

Untested fix.


-- 


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

[Bug tree-optimization/45506] New: tree_mem_ref_addr, at tree-ssa-address.c:278

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c++ --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100902 (experimental) [trunk revision 163787] (GCC) 
$ ./xgcc -B.  ~/ice.i -g -O
/home/ryan/ice.i: In function fini_array:
/home/ryan/ice.i:29:27: warning: initialisation makes pointer from integer
without a cast [enabled by default]
/home/ryan/ice.i: In function _do_exit_fini:
/home/ryan/ice.i:36:26: internal compiler error: in tree_mem_ref_addr, at
tree-ssa-address.c:278
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary:  tree_mem_ref_addr, at tree-ssa-address.c:278
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90



--- Comment #1 from burnus at gcc dot gnu dot org  2010-09-02 18:32 ---
That's a -m32 (fails) vs. -m64 (works) issue, cf.
http://gcc.gnu.org/ml/fortran/2010-09/msg00062.html


-- 


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

[Bug middle-end/43760] [4.6 regression] New test failures

2010-09-02 Thread sje at cup dot hp dot com



--- Comment #7 from sje at cup dot hp dot com  2010-09-02 18:26 ---
I wonder if we should attack this from a different angle.  We have been trying
to make the .pred.mutex.rel info more accurate to avoid this warning.  If we
can't do that I wonder if we should make GCC more conservative about doing two
predicated writes in a single instruction group.  This would make the code
slower but it might be an infrequent enough occurance that it doesn't matter.

Also, I currently see gfortran.dg/maxlocval_3.f90 failing with this message and
when I look at the assembly code, there are two predicated writes that are
using two consecutive pr registers (p12 and p13) but they are not set in a
single cmp instructions.  They are set seperately and I believe that both could
be true which would mean that we are generating invalid code.

I am going to test a patch that changes rws_access_regno to not allow two
predicated register write in the same instruction group.


-- 


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

[Bug java/45504] [4.6 Regression] Failed to bootstrap

2010-09-02 Thread dominiq at lps dot ens dot fr



--- Comment #1 from dominiq at lps dot ens dot fr  2010-09-02 18:06 ---
The same here on x86_64-apple-darwin10.4.0.


-- 


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

[Bug fortran/45505] New: [4.6 Regression] gfortran.dg/pr25923.f90

On Linux/x86, revision 163781 gave

FAIL: gfortran.dg/pr25923.f90  -O   (test for warnings, line 13)
FAIL: gfortran.dg/pr25923.f90  -O  (test for excess errors)

Revision 163775 is OK. It may be caused by revision 163776:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00067.html


-- 
   Summary: [4.6 Regression] gfortran.dg/pr25923.f90
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
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=45505

[Bug java/45504] New: [4.6 Regression] Failed to bootstrap

2010-09-02 Thread r dot j dot hogan at reading dot ac dot uk

On Linux/ia64, revision 163772 gave

Usage: /export/gnu/import/svn/gcc-test/bld/./gcc/jvgenmain [OPTIONS]...
CLASSNAMEmain [OUTFILE]
make[6]: *** [gjdoc] Error 1

Revision 163755 is OK.


-- 
   Summary: [4.6 Regression] Failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
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=45504

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined



--- Comment #1 from r dot j dot hogan at reading dot ac dot uk  2010-09-02 
17:56 ---
Created an attachment (id=21675)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21675&action=view)
Output from "-save-temps"


-- 


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

[Bug other/45503] New: "make distclean" Does Not Remove All Local Configuration Data

2010-09-02 Thread tom dot browder at gmail dot com

After an aborted or clean build in a directory outside the gcc source tree,
"make distclean" is supposed to remove all configuration information.  However,
that is not the case for at least one target (pdf).  Using gcc-4.5.1 in my
build directory (as a bash user):

$ cd gcc_build
$ ../gcc-4.5.1/configure
... # nothing unusual
$ make pdf
... # nothing unusual except pdf target seems to
# result in LOTs of extra compilation

Come back the next day

$ export CC=/usr/local/bin/gcc-4.5.1
$ cd gcc_build
$ make distclean
$ ls -aCF
./  ../  fixincludes/
$ ../gcc-5.5.1/configure
... # nothing unusual
$ make pdf
make[1]: Entering directory `/usr/local/src/gcc_build'
make[2]: Entering directory `/usr/local/src/gcc_build'
make[2]: Leaving directory `/usr/local/src/gcc_build'
Configuring in ./fixincludes
configure: loading cache ./config.cache
configure: error: `CC' has changed since the previous run:
configure:   former value:  `gcc'
configure:   current value: `/usr/local/bin/gcc-4.5.1'
configure: error: in `/usr/local/src/gcc_build/fixincludes':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start
over
make[1]: *** [configure-fixincludes] Error 1
make[1]: Leaving directory `/usr/local/src/gcc_build'
make: *** [do-pdf] Error 2


-- 
   Summary: "make distclean" Does Not Remove All Local Configuration
Data
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot browder at gmail dot com


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

[Bug c/45502] New: Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined

2010-09-02 Thread r dot j dot hogan at reading dot ac dot uk

The following code passes a multidimensional array to a function that uses the
C99 format for accepting an array when the size is not known at compile time.
The code outputs incorrect numbers (like 6.91992e-310) if the function "show"
gets inlined, which happens if I do one of these:
  gcc -Wall -save-temps -std=c99 -O2 -finline-functions bug.c -o bug
  gcc -Wall -save-temps -std=c99 -O3 bug.c -o bug
Using less optimization (e.g. -O1) or using the __attribute__((noinline)) on
the "show" function results in correct operation, so I presume it is the
inlining that is not working.

-- bug.c -
#include 
void show(int n, int m, double a[n][m]) {
  int i, j;
  for (i = 0; i < n; i++) {
for (j = 0; j < m; j++) {
  fprintf(stderr, "a[%d][%d] = %g\n", i, j, a[i][j]);
}
  }  
}

int main(int argc, char** argv) {
  double b[3][2] = {{1.1, 2.1}, {3.1, 4.1}, {5.1, 6.1}};
  show(3,2,b);
  return 0;
}


>> gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)


-- 
   Summary: Passing multi-dimensional array to function using C99
VLA function parameter format fails if function is
inlined
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot j dot hogan at reading dot ac dot uk
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug c++/45501] Compiler does not find template function if member is addressed with "this"

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #2 from paolo dot carlini at oracle dot com  2010-09-02 17:44 
---
As a matter of fact, basing on my rough understanding of '.template', GCC may
well be correct: my rule of thumb is that 'template' is required when the
construct before the period depends on a template parameter: by itself prn,
being a Printer, doesn't; this->prn does, because this points to a
MultiInfoPrinter.


-- 


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

[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c

2010-09-02 Thread howarth at nitro dot med dot uc dot edu



--- Comment #22 from howarth at nitro dot med dot uc dot edu  2010-09-02 
17:39 ---
(In reply to comment #21)
> Created an attachment (id=21670)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21670&action=view) [edit]
> gcc46-pr45484.patch
> 
... 

Jakub,
Thanks. This patch when applied to r163660 on x86_64-apple-darwin10 appears
to
totally eliminate the ICEs which were occurring 50% of time previously.


-- 


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

[Bug target/45478] attribute((target())) causes crashes at various places

2010-09-02 Thread salvatore dot filippone at uniroma2 dot it



--- Comment #4 from zsojka at seznam dot cz  2010-09-02 17:32 ---
Created an attachment (id=21674)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21674&action=view)
another testcase

This needs -O as well:
$ gcc -O pr45478-4.c

Related valgrind output:
$ valgrind cc1 -O -quiet pr45478-4.c
...
==17845== Invalid write of size 1
==17845==at 0x877B2AA: mark_reg_pointer (emit-rtl.c:1121)
==17845==by 0x89B97B6: assign_parm_setup_reg (function.c:3137)
==17845==by 0x89BA9F7: assign_parms (function.c:3368)
==17845==by 0x89BF1C6: expand_function_start (function.c:4666)
==17845==by 0x84C594E: gimple_expand_cfg (cfgexpand.c:3825)
==17845==by 0x8EEB8F3: execute_one_pass (passes.c:1568)
==17845==by 0x8EEBAC7: execute_pass_list (passes.c:1623)
==17845==by 0x97772D8: tree_rest_of_compilation (tree-optimize.c:452)
==17845==by 0xA3362AC: cgraph_expand_function (cgraphunit.c:1469)
==17845==by 0xA336517: cgraph_expand_all_functions (cgraphunit.c:1548)
==17845==by 0xA336B09: cgraph_optimize (cgraphunit.c:1804)
==17845==by 0xA334877: cgraph_finalize_compilation_unit (cgraphunit.c:1012)
==17845==  Address 0x4b6c45c is 3 bytes after a block of size 1 alloc'd
==17845==at 0x40287FE: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17845==by 0xB6A0D6A: xrealloc (xmalloc.c:177)
==17845==by 0x8778B49: gen_reg_rtx (emit-rtl.c:901)
==17845==by 0x84B764D: expand_one_register_var (cfgexpand.c:846)
==17845==by 0x84B80B6: expand_one_var (cfgexpand.c:993)
==17845==by 0x84B910C: expand_used_vars (cfgexpand.c:1330)
==17845==by 0x84C58CF: gimple_expand_cfg (cfgexpand.c:3807)
==17845==by 0x8EEB8F3: execute_one_pass (passes.c:1568)
==17845==by 0x8EEBAC7: execute_pass_list (passes.c:1623)
==17845==by 0x97772D8: tree_rest_of_compilation (tree-optimize.c:452)
==17845==by 0xA3362AC: cgraph_expand_function (cgraphunit.c:1469)
==17845==by 0xA336517: cgraph_expand_all_functions (cgraphunit.c:1548)
==17845== 
==17845== Invalid read of size 4
==17845==at 0xAF5EFFF: count_reg_usage (cse.c:6583)
==17845==by 0xAF6029A: count_reg_usage (cse.c:6681)
==17845==by 0xAF5F593: count_reg_usage (cse.c:6608)
==17845==by 0xAF5F804: count_reg_usage (cse.c:6625)
==17845==by 0xAF61651: delete_trivially_dead_insns (cse.c:6800)
==17845==by 0xAE3E705: rest_of_handle_jump2 (cfgcleanup.c:2425)
==17845==by 0x8EEB8F3: execute_one_pass (passes.c:1568)
==17845==by 0x8EEBAC7: execute_pass_list (passes.c:1623)
==17845==by 0x8EEBAE3: execute_pass_list (passes.c:1624)
==17845==by 0x97772D8: tree_rest_of_compilation (tree-optimize.c:452)
==17845==by 0xA3362AC: cgraph_expand_function (cgraphunit.c:1469)
==17845==by 0xA336517: cgraph_expand_all_functions (cgraphunit.c:1548)
==17845==  Address 0x4b6fb78 is not stack'd, malloc'd or (recently) free'd
==17845== 
==17845== Invalid write of size 4
==17845==at 0xAF5F004: count_reg_usage (cse.c:6583)
==17845==by 0xAF6029A: count_reg_usage (cse.c:6681)
==17845==by 0xAF5F593: count_reg_usage (cse.c:6608)
==17845==by 0xAF5F804: count_reg_usage (cse.c:6625)
==17845==by 0xAF61651: delete_trivially_dead_insns (cse.c:6800)
==17845==by 0xAE3E705: rest_of_handle_jump2 (cfgcleanup.c:2425)
==17845==by 0x8EEB8F3: execute_one_pass (passes.c:1568)
==17845==by 0x8EEBAC7: execute_pass_list (passes.c:1623)
==17845==by 0x8EEBAE3: execute_pass_list (passes.c:1624)
==17845==by 0x97772D8: tree_rest_of_compilation (tree-optimize.c:452)
==17845==by 0xA3362AC: cgraph_expand_function (cgraphunit.c:1469)
==17845==by 0xA336517: cgraph_expand_all_functions (cgraphunit.c:1548)
==17845==  Address 0x4b6fb78 is not stack'd, malloc'd or (recently) free'd
==17845== 
==17845== Invalid read of size 4
==17845==at 0xAF5EFFF: count_reg_usage (cse.c:6583)
==17845==by 0xAF6029A: count_reg_usage (cse.c:6681)
==17845==by 0xAF5FBC4: count_reg_usage (cse.c:6645)
==17845==by 0xAF61651: delete_trivially_dead_insns (cse.c:6800)
==17845==by 0xAE3E705: rest_of_handle_jump2 (cfgcleanup.c:2425)
==17845==by 0x8EEB8F3: execute_one_pass (passes.c:1568)
==17845==by 0x8EEBAC7: execute_pass_list (passes.c:1623)
==17845==by 0x8EEBAE3: execute_pass_list (passes.c:1624)
==17845==by 0x97772D8: tree_rest_of_compilation (tree-optimize.c:452)
==17845==by 0xA3362AC: cgraph_expand_function (cgraphunit.c:1469)
==17845==by 0xA336517: cgraph_expand_all_functions (cgraphunit.c:1548)
==17845==by 0xA336B09: cgraph_optimize (cgraphunit.c:1804)
==17845==  Address 0x4b6fb78 is not stack'd, malloc'd or (recently) free'd
==17845== 
==17845== Invalid write of size 4
==17845==at 0xAF5F004: count_reg_usage (cse.c:6583)
==17845==by 0xAF6029A: count_reg_usage (cse.c:6681)
==17845==by 0xAF5FBC4: count_reg_usage (cse.c:6645)
==17845==by 0xAF61651: delete_trivially_dead_insns (cse.c:6800)
==17845==by 0xAE3E705: rest_of_handle_jump2 (cfgcleanup.c

[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'



--- Comment #7 from salvatore dot filippone at uniroma2 dot it  2010-09-02 
17:31 ---
Subject: Re:  Bootstrap fails on PPC error:
 conflicting types for 'malloc'

Il giorno gio, 02/09/2010 alle 17.15 +, rwild at gcc dot gnu dot org
ha scritto:
> 
> --- Comment #6 from rwild at gcc dot gnu dot org  2010-09-02 17:15 ---
> Please do the following:
> 
> m
Indeed. 
[snfi...@josquin libiberty]$ ./conftest; echo $?
2

> 
> ./conftest; echo $?
> 
> According to the log in comment #4 this outputs 2 in your setup.  It should
> output 0.  Can you find out why?  You might want to replace '-o conftest' with
> -E to see preprocessed output, maybe some bogus header somewhere.
> 
Output attached. I have no more time to look at it now, will get back
tomorrow morning (my time) 
Thanks 

> Thanks.
> 
> 


--- Comment #8 from salvatore dot filippone at uniroma2 dot it  2010-09-02 
17:31 ---
Created an attachment (id=21673)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21673&action=view)


-- 


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

[Bug c++/45501] Compiler does not find template function if member is addressed with "this"

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #1 from paolo dot carlini at oracle dot com  2010-09-02 17:16 
---
Since PrintTextFrom is a template, you can (should) write:

  this->prn.template PrintTextFrom< MetaObj >();

which works with both compilers. Since apparently ICC 11.1 likes in strict mode
also the form without 'template' let's ask Jason if we are right in rejecting
it (while accepting it without this->)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'

2010-09-02 Thread rwild at gcc dot gnu dot org



--- Comment #6 from rwild at gcc dot gnu dot org  2010-09-02 17:15 ---
Please do the following:

make stage2-start
cd libiberty

cat >conftest.c <<\EOF
/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define _FILE_OFFSET_BITS 64
/* end confdefs.h.  */
#include 
#include 
#if ((' ' & 0x0FF) == 0x020)
# define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
# define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
#else
# define ISLOWER(c)(('a' <= (c) && (c) <= 'i')   ||
('j' <= (c) && (c) <= 'r')   || ('s' <= (c) && (c) <= 'z'))
# define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
#endif

#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
int
main ()
{
  int i;
  for (i = 0; i < 256; i++)
if (XOR (islower (i), ISLOWER (i))
|| toupper (i) != TOUPPER (i))
  return 2;
  return 0;
}
EOF

/home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/xgcc
-B/home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/
-B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/bin/
-B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/bin/
-B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/include -isystem
/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/sys-include-o
conftest -g -O2 -gtoggleconftest.c

./conftest; echo $?

According to the log in comment #4 this outputs 2 in your setup.  It should
output 0.  Can you find out why?  You might want to replace '-o conftest' with
-E to see preprocessed output, maybe some bogus header somewhere.

Thanks.


-- 


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

[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi

2010-09-02 Thread grottel at vis dot uni-stuttgart dot de



-- 

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-09-02 17:12:43
   date||


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

[Bug c++/45501] New: Compiler does not find template function if member is addressed with "this"

Command line:
g++ -o File.o File.cpp

Testes with gcc 4.5.0 and 4.3.1

Content of .cpp-file:
#include 

template
class MetaObj {
public:
const char *GetText(void) const {
return T::GetTextStatic();
}
};

class Obj {
public:
static const char *GetTextStatic(void) {
return "Text";
}
};

class Printer {
public:
void PrintText(const char *who, const char *what) {
printf("%s: %s\n", who, what);
}
template void PrintTextFrom(void) {
T *d = new T();
PrintText("Printer-Meta", d->GetText());
delete d;
}
};

template
class MultiInfoPrinter {
public:
MultiInfoPrinter(void) {
for (unsigned int i = 0; i < CNT; i++) {
this->prn.PrintText("MultiInfoPrinter-Static",
Obj::GetTextStatic());   // works
this->prn.PrintText("MultiInfoPrinter-Meta",
MetaObj().GetText()); // works
prn.PrintTextFrom< MetaObj >();   
// works
this->prn.PrintTextFrom< MetaObj >(); 
// WORKS NOT with gcc, but with icc!!! WHY???
}
}
private:
Printer prn;
};

int main(int argc, char *argv[]) {
MultiInfoPrinter<2> p;
}


-- 
   Summary: Compiler does not find template function if member is
addressed with "this"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grottel at vis dot uni-stuttgart dot de


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

[Bug target/45478] ICE: in c_builtin_function_ext_scope, at c-decl.c:2852 with -mno-sse/-march=i386 and attribute((target))



--- Comment #3 from zsojka at seznam dot cz  2010-09-02 16:46 ---
Created an attachment (id=21672)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21672&action=view)
different crash

This causes invalid read in df_ref_record.

Command line:
$ gcc -O pr45478-3.c

Relevant valgrind output:
$ valgrind cc1 -O -quiet pr45478-3.c
...
==17688== Invalid read of size 2
==17688==at 0x868FFFD: df_ref_record (df-scan.c:2881)
==17688==by 0x8696BE4: df_entry_block_defs_collect (df-scan.c:3941)
==17688==by 0x8696C8A: df_record_entry_block_defs (df-scan.c:3959)
==17688==by 0x8688633: df_scan_blocks (df-scan.c:676)
==17688==by 0x8649B4F: rest_of_handle_df_initialize (df-core.c:738)
==17688==by 0x8EEB8F3: execute_one_pass (passes.c:1568)
==17688==by 0x8EEBAC7: execute_pass_list (passes.c:1623)
==17688==by 0x8EEBAE3: execute_pass_list (passes.c:1624)
==17688==by 0x97772D8: tree_rest_of_compilation (tree-optimize.c:452)
==17688==by 0xA3362AC: cgraph_expand_function (cgraphunit.c:1469)
==17688==by 0xA336517: cgraph_expand_all_functions (cgraphunit.c:1548)
==17688==by 0xA336B09: cgraph_optimize (cgraphunit.c:1804)
==17688==  Address 0x2c is not stack'd, malloc'd or (recently) free'd
==17688== 
pr45478-3.c: In function 'search_line_sse42':
pr45478-3.c:11:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi

2010-09-02 Thread dave at hiauly1 dot hia dot nrc dot ca



--- Comment #1 from zsojka at seznam dot cz  2010-09-02 16:32 ---
Note this breaks bootstrap with BOOT_CFLAGS="-march=athlon-4 -O2":

$ make BOOT_CFLAGS="-march=athlon-4 -O2"
...
/root/build-163760-lto-fortran-checking-yes-rtl-df/./prev-gcc/xgcc
-B/root/build-163760-lto-fortran-checking-yes-rtl-df/./prev-gcc/
-B/mnt/svn/gcc-trunk/binary-163760-x86-lto-fortran-checking-yes-rtl-df/i686-pc-linux-gnu/bin/
-B/mnt/svn/gcc-trunk/binary-163760-x86-lto-fortran-checking-yes-rtl-df/i686-pc-linux-gnu/bin/
-B/mnt/svn/gcc-trunk/binary-163760-x86-lto-fortran-checking-yes-rtl-df/i686-pc-linux-gnu/lib/
-isystem
/mnt/svn/gcc-trunk/binary-163760-x86-lto-fortran-checking-yes-rtl-df/i686-pc-linux-gnu/include
-isystem
/mnt/svn/gcc-trunk/binary-163760-x86-lto-fortran-checking-yes-rtl-df/i686-pc-linux-gnu/sys-include
-I/usr/portage/distfiles/svn-src/gcc/trunk/libcpp -I.
-I/usr/portage/distfiles/svn-src/gcc/trunk/libcpp/../include
-I/usr/portage/distfiles/svn-src/gcc/trunk/libcpp/include  -march=athlon-4 -O2
-gtoggle -W -Wall -Wwrite-strings -Wmissing-format-attribute
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat
-pedantic -Wno-long-long -Werror
-I/usr/portage/distfiles/svn-src/gcc/trunk/libcpp -I.
-I/usr/portage/distfiles/svn-src/gcc/trunk/libcpp/../include
-I/usr/portage/distfiles/svn-src/gcc/trunk/libcpp/include  -c -o lex.o -MT
lex.o -MMD -MP -MF .deps/lex.Tpo
/usr/portage/distfiles/svn-src/gcc/trunk/libcpp/lex.c
/usr/portage/distfiles/svn-src/gcc/trunk/libcpp/lex.c:2838:1: internal compiler
error: in rtl_for_decl_init, at dwarf2out.c:16307
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [lex.o] Error 1
make[3]: Leaving directory
`/root/build-163760-lto-fortran-checking-yes-rtl-df/libcpp'
make[2]: *** [all-stage2-libcpp] Error 2
make[2]: Leaving directory `/root/build-163760-lto-fortran-checking-yes-rtl-df'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/root/build-163760-lto-fortran-checking-yes-rtl-df'
make: *** [all] Error 2


-- 


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

[Bug testsuite/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)



--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-02 
16:27 ---
Subject: Re:  [4.6 Regression] FAIL:
gcc.dg/torture/builtin-cproj-1.c  -O1  (test for excess errors)

On Thu, 02 Sep 2010, ghazi at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #3 from ghazi at gcc dot gnu dot org  2010-09-02 15:24 ---
> > Please check whether
> > +/* { dg-add-options c99_runtime } */
> > +/* { dg-require-effective-target c99_runtime } */
> 
> You're right that these foldings should succeed anyway, the c99_runtime should
> not be necessary.  If requiring a c99 effective target eliminates the error,
> it's only because the test doesn't run anymore.
> 
> The subject indicates the test fails at -O1, but I assume not -O0 or -O2.  
> This
> leads me to guess that the failing line(s) are in the #ifdef __OPTIMIZE__
> section.  These bits rely on some generic optimizations to fully fold away the
> relevant code, which may not be happening here at -O1.
> 
> I don't have access to a test infrastructure ATM.  So if David could please
> narrow down which line is failing to fold, it would help.  Each test line here
> calls link_error(__LINE__) so if you add -fdump-tree-* you should be able to
> see which one(s) aren't folding, and hopefully why.
> 
> I suspect it's something more than the c99 complex stuff.

The test also fails at -O1 on hppa-unknown-linux-gnu.  This is a c99
target.  It doesn't fail at -O0 or at -O2.

Attached builtin-cproj-1.c.149t.optimized.


--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-02 
16:27 ---
Created an attachment (id=21671)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21671&action=view)


-- 


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

[Bug c++/36254] [4.3 Regression] wrong "control reaches end of non-void function" warning with IF_STMT

2010-09-02 Thread pluto at agmk dot net



--- Comment #20 from pluto at agmk dot net  2010-09-02 16:22 ---
*** Bug 45497 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/45497] [4.3/4.4/4.5/4.6 Regression] bogus warning at -O0 (control reaches end of non-void function).

2010-09-02 Thread pluto at agmk dot net



--- Comment #3 from pluto at agmk dot net  2010-09-02 16:22 ---
i thins this is really a duplicate of t2.cpp testcase from PR36254.

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


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.4.0 4.5.2 |4.3.6 4.4.0 4.5.2
  Known to work|4.3.5   |
 Resolution||DUPLICATE
Summary|[4.4/4.5/4.6 Regression]|[4.3/4.4/4.5/4.6 Regression]
   |bogus warning at -O0|bogus warning at -O0
   |(control reaches end of non-|(control reaches end of non-
   |void function). |void function).


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

[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c

2010-09-02 Thread dave at hiauly1 dot hia dot nrc dot ca



--- Comment #21 from jakub at gcc dot gnu dot org  2010-09-02 16:16 ---
Created an attachment (id=21670)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21670&action=view)
gcc46-pr45484.patch

The last valgrind error is my fault, we don't need a BARRIER there, any
instruction that flushes the queued ones will do.
So, either we do something like in this patch, or dwarf2out.c would need to
record the size of barrier_args_size and for BARRIERs with higher INSN_UID just
use offset 0 (i.e. args_size before offset -= args_size;).  But the latter
would be more code and uglier.


-- 


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

[Bug c/45493] -Wuninitialized does not warn

2010-09-02 Thread tadhunt at gmail dot com



--- Comment #3 from tadhunt at gmail dot com  2010-09-02 16:08 ---
(In reply to comment #2)

Richard, thanks for the confirmation.

This is a great feature that we've come to rely on over the years for catching
rookie errors.

This might not appear in comments very often, but I appreciate the hard work
you and the rest of the gcc folks put in.


-- 


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

[Bug testsuite/43957] [4.6 Regression] FAIL: gcc.dg/const-uniq-1.c scan-tree-dump-times gimple "LC0" 2



--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-02 
16:08 ---
Subject: Re:  [4.6 Regression] FAIL:
gcc.dg/const-uniq-1.c scan-tree-dump-times gimple "LC0" 2

Revised regexp patch attached.


--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2010-09-02 
16:08 ---
Created an attachment (id=21669)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21669&action=view)


-- 


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

2010-09-02 Thread paolo dot carlini at oracle dot com



--- Comment #49 from paolo dot carlini at oracle dot com  2010-09-02 16:07 
---
Confirmed ~ 2x on my i7.


-- 


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

[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable

2010-09-02 Thread tadhunt at gmail dot com



--- Comment #19 from tadhunt at gmail dot com  2010-09-02 16:01 ---
This flamewar in the comments is hilarious.

To all concerned, here is a much simpler example.  This does appear to be a
regression.  I apologize that I cannot help fix it, as it's a really useful
feature that helps catch bugs.  Hat's off to you folks working hard on gcc.

int
main(void)
{
int len, i;

for(i = 0; i < 5; i++) {
printf("%d\n", len);// no warning!
len = 10;
}

return 0;
}


-- 


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

[Bug middle-end/45496] Static members of templates cause LTO to omit required code

2010-09-02 Thread alexey at feldgendler dot ru



--- Comment #23 from alexey at feldgendler dot ru  2010-09-02 15:55 ---
Yes, the patch fixes the observed bug. Thanks a lot!

However, there's also the issue of missing error reporting for a failure to
read ELF. I don't know if it should be fixed as part of this bug or separately.


-- 


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

[Bug c++/45437] Loses reference during update

2010-09-02 Thread jason at gcc dot gnu dot org



--- Comment #15 from jason at gcc dot gnu dot org  2010-09-02 15:50 ---
Indeed, C++0x 5.17p1 is quite clear.


-- 

jason 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-09-02 15:50:13
   date||


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

[Bug middle-end/45496] Static members of templates cause LTO to omit required code

2010-09-02 Thread rguenth at gcc dot gnu dot org



--- Comment #22 from rguenth at gcc dot gnu dot org  2010-09-02 15:34 
---
Fixed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161935 on trunk.

Needs backporting.  I'll do that.  Can you verify this fixes your problem?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-02 15:00:22 |2010-09-02 15:34:25
   date||


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

[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c

2010-09-02 Thread ebotcazou at gcc dot gnu dot org



--- Comment #20 from ebotcazou at gcc dot gnu dot org  2010-09-02 15:27 
---
> It is very likely that the stack usage change triggers this bug.

Not clear what you mean by this exactly, but I can reproduce the valgrind error
with the revision 163629 compiler.


-- 


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

[Bug testsuite/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

2010-09-02 Thread ghazi at gcc dot gnu dot org



--- Comment #3 from ghazi at gcc dot gnu dot org  2010-09-02 15:24 ---
> Please check whether
> +/* { dg-add-options c99_runtime } */
> +/* { dg-require-effective-target c99_runtime } */

You're right that these foldings should succeed anyway, the c99_runtime should
not be necessary.  If requiring a c99 effective target eliminates the error,
it's only because the test doesn't run anymore.

The subject indicates the test fails at -O1, but I assume not -O0 or -O2.  This
leads me to guess that the failing line(s) are in the #ifdef __OPTIMIZE__
section.  These bits rely on some generic optimizations to fully fold away the
relevant code, which may not be happening here at -O1.

I don't have access to a test infrastructure ATM.  So if David could please
narrow down which line is failing to fold, it would help.  Each test line here
calls link_error(__LINE__) so if you add -fdump-tree-* you should be able to
see which one(s) aren't folding, and hopefully why.

I suspect it's something more than the c99 complex stuff.


-- 


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

[Bug middle-end/45496] Static members of templates cause LTO to omit required code

2010-09-02 Thread rguenth at gcc dot gnu dot org



--- Comment #21 from rguenth at gcc dot gnu dot org  2010-09-02 15:23 
---
Last guess in the wild is that libelf0 (from libelf) doesn't handle the
object file like it should and we somehow silently treat it as an empty one.


-- 


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

[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c

2010-09-02 Thread howarth at nitro dot med dot uc dot edu



--- Comment #19 from howarth at nitro dot med dot uc dot edu  2010-09-02 
15:21 ---
(In reply to comment #17)
> No idea if it is correct:
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index b550d86..decfd65 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -8121,6 +8121,7 @@ output_set_got (rtx dest, rtx label ATTRIBUTE_UNUSED)
>if (dwarf2out_do_frame ())
> {
>   rtx insn;
> + dwarf2out_frame_debug (NULL_RTX, false);
>   start_sequence ();
>   insn = emit_barrier ();
>   end_sequence ();
> 

This change alone applied to r163600 just crashes the compiler.

/Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ -c
./sprintf-chk.c -w -Os -lm -m32
./sprintf-chk.c: In function test1:
./sprintf-chk.c:77:1: internal compiler error: in dwarf2out_frame_debug, at
dwarf2out.c:2714


-- 


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

[Bug debug/45500] New: ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi