[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2009-12-08 08:08 ---
Jack, what does this program do on darwin9 and darwin10?
(The correct output is "2 0".)

int main(void)
{
  volatile _Complex double val = (__DBL_MAX__ * 0.5 + __DBL_MAX__ * 0.5i);
  val /= (__DBL_MAX__ * 0.25 + __DBL_MAX__ * 0.25i);
  __builtin_printf ("%g %g\n", __real (val), __imag (val));
  if (val != 2) __builtin_abort();
  return 0;
}


-- 


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

[Bug debug/42186] [4.5 Regression] [graphite] internal compiler error: verify_ssa failed

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-12-08 08:24 ---
Yeah, this isn't VTA related.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|aoliva at gcc dot gnu dot   |
   |org |


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

[Bug fortran/40961] Document set_fpe(int)

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-12-08 08:52 ---
Subject: Bug 40961

Author: burnus
Date: Tue Dec  8 08:52:28 2009
New Revision: 155083

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155083
Log:
2009-12-08  Tobias Burnus  

PR fortran/40961
PR fortran/40377
* gfortran.texi (Non-Fortran Main Program): Add
_gfortran_set_fpe documentation.
(Interoperability with C): Mention array storage order.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi


-- 


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

[Bug fortran/40377] gfortran documentation: Add note to C prog. part + update F200x status

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-12-08 08:52 ---
Subject: Bug 40377

Author: burnus
Date: Tue Dec  8 08:52:28 2009
New Revision: 155083

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155083
Log:
2009-12-08  Tobias Burnus  

PR fortran/40961
PR fortran/40377
* gfortran.texi (Non-Fortran Main Program): Add
_gfortran_set_fpe documentation.
(Interoperability with C): Mention array storage order.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi


-- 


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

[Bug fortran/40961] Document set_fpe(int)

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-12-08 08:53 ---
FIXED.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/40377] gfortran documentation: Add note to C prog. part + update F200x status

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-12-08 08:53 ---
FIXED


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/42317] [4.5 Regression] Issues with comdat virtual dtors

[debian-gcc at lists dot debian dot org]

--- Comment #2 from debian-gcc at lists dot debian dot org  2009-12-08 
08:56 ---
with the proposed patch applied, the build fails now with:

virtual __gnu_cxx::stdio_sync_filebuf::~stdio_sync_filebuf()/243(191)
@0x4093abd0 availability:available 22 time, 11 benefit (
24 after inlining) 4 size, 2 benefit (6 after inlining) reachable body
externally_visible finalized inlinable
  called by: 
  calls: void operator delete(void*)/317 (1.00 per call)
__gnu_cxx::stdio_sync_filebuf::~stdio_sync_filebuf()/113 (inlined) (1
.00 per call) 
../../../../src/libstdc++-v3/src/ios_init.cc:199:1: internal compiler error:
failed to reclaim unneeded function
Please submit a full bug report,
with preprocessed source if appropriate.

the file ios_init.ii builds with -O0, but not with -O1 or higher

  Matthias


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org


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

[Bug c++/42317] [4.5 Regression] Issues with comdat virtual dtors

[debian-gcc at lists dot debian dot org]

--- Comment #3 from debian-gcc at lists dot debian dot org  2009-12-08 
08:58 ---
Created an attachment (id=19256)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19256&action=view)
preprocessed source


-- 


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

[Bug c++/42317] [4.5 Regression] Issues with comdat virtual dtors

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-12-08 09:03 ---
You were testing the patch attached here (i.e. version before
bootstrap/regtest) instead of the one posted to gcc-patches (tested), right?
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00385.html


-- 


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

[Bug c++/42101] Linking failure with static constants and ternary inline function

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-12-08 09:18 
---
*** Bug 42330 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||aijunbai at gmail dot com


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-12-08 09:18 
---
You aren't defining anywhere A::i, just add, after struct A:

  const int A::i;

and things will be fine.

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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'

[olga at gcc dot gnu dot org]

--- Comment #6 from olga at gcc dot gnu dot org  2009-12-08 09:41 ---
Subject: Bug 41843

Author: olga
Date: Tue Dec  8 09:41:13 2009
New Revision: 155084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155084
Log:
2009-12-07  Olga Golovanevsky  

PR middle-end/41843
* ipa-struct-reorg.c (compare_fields): New function.
(find_field_in_struct_1): Use compare_fields function.
(is_equal_types): Likewise.

2009-12-04  Olga Golovanevsky  
Jakub Jelinek 

PR midle-end/41843
* gcc.dg/struct/wo_prof_empty_str.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/struct/wo_prof_empty_str.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-struct-reorg.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[aijunbai at gmail dot com]

--- Comment #2 from aijunbai at gmail dot com  2009-12-08 09:46 ---
(In reply to comment #1)
> You aren't defining anywhere A::i, just add, after struct A:
> 
>   const int A::i;
> 
> and things will be fine.
> 
> *** This bug has been marked as a duplicate of 42101 ***
> 

thanks for your reply.

i found that no errors will be reported if i delete the line `bar(A::i)', so is
that a bug?

in fact the original code is like:
template 
class A
{
static const int i = -1;
}

template <>
class A<0>
{
static const int i = 0;
}

//and some other specializations...

and i don't want to write lots of "const int A::i"...


-- 

aijunbai at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2009-12-08 09:48 ---
(In reply to comment #2)
> and i don't want to write lots of "const int A::i"...

You have to, your code is not valid if you use A::i in the program but it has
no definition.  This is not a compiler bug.




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


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42101] Linking failure with static constants and ternary inline function

[redi at gcc dot gnu dot org]

--- Comment #11 from redi at gcc dot gnu dot org  2009-12-08 09:48 ---
*** Bug 42330 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[redi at gcc dot gnu dot org]

--- Comment #4 from redi at gcc dot gnu dot org  2009-12-08 09:50 ---
(In reply to comment #3)
> (In reply to comment #2)
> > and i don't want to write lots of "const int A::i"...
> 
> You have to, your code is not valid if you use A::i in the program but it has
> no definition.  This is not a compiler bug.

Actually you don't have to write lots, just one:

template const A::i;


-- 


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

[Bug c++/38600] Trouble mangling template_id_expr

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2009-12-08 09:53 
---
This is yet another, C++0x, in this case, testcase, as provided by Jon. I
believe it's the same obnoxious mangling issue, but an additional testcase
cannot hurt ;)

#include 

unsigned value = 0;

struct Inc {
  void operator()() const {
++value;
  }
};

template
decltype( std::declval()() ) f()
{
  return T()();
}

void g()
{
  return f();
}


-- 


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

[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2009-12-08 09:56 ---
I had a look at the problem and found that it is due to the -lm flag used in
the test suite. The test in comment #9 gives for x86_64-apple-darwin10:

[macbook] f90/bug% a.out 
2 0
[macbook] f90/bug% gcc45 pr42074.c -lm
[macbook] f90/bug% a.out
inf 0
Abort

and tgcc.dg/torture/builtin-math-7.c passes when it is compiled manually
without -lm.

Note that gcc version 4.4.2 (GCC) gives the same results, but not gcc version
4.2.1 (Apple Inc. build 5646) (dot 1) Target: i686-apple-darwin10:

[macbook] f90/bug% gcc pr42074.c -lm
[macbook] f90/bug% a.out
2 0

These tests pass on powerpc-apple-darwin9 with gcc4.5 rev.155054.

I don't have access right now to *86*-apple-darwin9 and older versions of gcc,
but I'll check on it tonight.


-- 


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

[Bug c++/42328] rejects valid friend

[redi at gcc dot gnu dot org]

--- Comment #4 from redi at gcc dot gnu dot org  2009-12-08 09:57 ---

What's wrong with

class   baz : protected freeList {
voidfrob() {}
friend class freeList;
};

or

class   baz : protected freeList {
voidfrob() {}
template friend void freeList::foo();
};


-- 


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

[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2009-12-08 10:06 ---
I have bootstrapped gcc revision 155054 with the mpc version for which the
tests passed (revision 154405) and the tests are still failing.

The minimal set of options to make the test in comment #6 abort is "-O1
-funroll-loops -m64 -fomit-frame-pointer". The test pass if I omit
-fomit-frame-pointer.


-- 


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

[Bug c/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'

[olga at il dot ibm dot com]

--- Comment #7 from olga at il dot ibm dot com  2009-12-08 10:19 ---
With this patch running shape.i produces the following output:

Using built-in specs.
COLLECT_GCC=/home/olga/mainline_after_LTO_merge-bin/bin/gcc
COLLECT_LTO_WRAPPER=/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap --enable-languages=c
--prefix=/home/olga/mainline_after_LTO_merge-bin : (reconfigured)
../gcc/configure --disable-bootstrap
--prefix=/home/olga/mainline_after_LTO_merge-bin --enable-languages=c
--no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20091120 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B.' '-r' '-nostdlib' '-v' '-Wall' '-Wextra' '-Os'
'-fipa-struct-reorg' '-fwhole-program' '-combine'

/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/cc1
-fpreprocessed shape.i -quiet -dumpbase shape.i -auxbase shape -Os -Wall
-Wextra -version -fipa-struct-reorg -fwhole-program -o /tmp/ccW8PCV1.s
GNU C (GCC) version 4.5.0 20091120 (experimental) (powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 4.2.3, MPFR version 2.3.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20091120 (experimental) (powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 4.2.3, MPFR version 2.3.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3a5e7bac9c838b9058c82d1ba65f332a
shape.c: In function 'ShapeResetProc':
shape.c:168:17: warning: unused parameter 'extEntry'
shape.c: In function 'ShapeFreeClient':
shape.c:775:9: warning: unused parameter 'id'
shape.c: In function 'ShapeFreeEvents':
shape.c:804:9: warning: unused parameter 'id'
COLLECT_GCC_OPTIONS='-B.' '-r' '-nostdlib' '-v' '-Wall' '-Wextra' '-Os'
'-fipa-struct-reorg' '-fwhole-program' '-combine'
 as -a64 -mppc64 -many -V -Qy -o /tmp/cc9EuLXR.o /tmp/ccW8PCV1.s
GNU assembler version 2.19 (powerpc64-suse-linux) using BFD version (GNU
Binutils; SUSE Linux Enterprise 11) 2.19
COMPILER_PATH=./:/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/:/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/:/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/powerpc64-unknown-linux-gnu/:/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0/:/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/
LIBRARY_PATH=./:/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0/:/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B.' '-r' '-nostdlib' '-v' '-Wall' '-Wextra' '-Os'
'-fipa-struct-reorg' '-fwhole-program' '-combine'

/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/collect2
--eh-frame-hdr -V -Qy -m elf64ppc -dynamic-linker /lib64/ld64.so.1 -r -L.
-L/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0
-L/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/olga/mainline_after_LTO_merge-bin/lib/gcc/powerpc64-unknown-linux-gnu/4.5.0/../../..
/tmp/cc9EuLXR.o
GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.19
  Supported emulations:
   elf64ppc
   elf32ppclinux
   elf32ppc
   elf32ppcsim


-- 

olga at il dot ibm dot com changed:

   What|Removed |Added

 CC||olga at il dot ibm dot com


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

[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files

[viriketo at gmail dot com]

--- Comment #2 from viriketo at gmail dot com  2009-12-08 10:26 ---
Sorry, I noticed that the libtsdc++ build does not help in this case, because
it is build with -nostdlib, and the startfile objects are determined by the
configure script. It is a special case of linking, not to be compared with that
of libmudflap. We want libmudflap built without '-nostdlib', I understand.

So, I vote somehow to get the target libraries libtool scripts to pass -Bxxx
compile/link flags. That may be related to a bug in libtool, but I did some
simple tests with a self-built libtool script (out of the gcc tree), and there
-Bxxx were passed. I don't know the internals enough to understand the
different behaviours of the gcc target libraries libtool and my copy.


-- 


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

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

[redi at gcc dot gnu dot org]

--- Comment #13 from redi at gcc dot gnu dot org  2009-12-08 10:48 ---
(In reply to comment #12)
> > The situation will be different with the upcoming C++1x standard where there
> > is null_ptr.
> 
> Yes, very different.  Per the accepted language defect and paper I cited here
> yesterday, in the upcoming standard, the compiler seems required to reject
> implicit conversion from NULL to int.  This PR then becomes a rejects-valid 
> and
> an accepts-invalid bug, rather than an enhancement request for a warning.

I don't think that's true, implicit conversion from nullptr_t to int is
forbidden, but 0 is still a valid definition of NULL so conversion from NULL to
int is OK. And __null does not have type nullptr_t, changing it to have that
type would break a lot of code




> void test() {
>   if (__null); // Explicitly allowed in upcoming Standard (shouldn't warn, PR
> 24745)
>   int a = __null; // Disallowed(?) by upcoming Standard (should error, PR 
> 35699
> (this PR))
>   int b = (int)__null; // Explicitly allowed in upcoming Standard (shouldn't
> warn, PR 5310)
> }
> 
> (In reply to comment #11)
> >  What would be the point of __null otherwise...?
> 
> Good question.
> 


-- 


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

[Bug c++/42331] New: [4.4/4.5 regression] ICE in error recovery

[doko at ubuntu dot com]

seen with trunk 20091208 and 4.4 branch 20091130, not with 4.3.4:

$ g++ -g Mesh.ii
In file included from /usr/include/c++/4.4/ext/new_allocator.h:34,
 from
/usr/include/c++/4.4/x86_64-linux-gnu/bits/c++allocator.h:35,
 from /usr/include/c++/4.4/bits/allocator.h:49,
 from /usr/include/c++/4.4/string:44,
 from /usr/include/c++/4.4/bits/locale_classes.h:43,
 from /usr/include/c++/4.4/bits/ios_base.h:44,
 from /usr/include/c++/4.4/ios:44,
 from /usr/include/c++/4.4/ostream:41,
 from /usr/include/c++/4.4/iostream:41,
 from
/home/cesare/Programmi/changemesh/project/source/Mesh.cpp:4:
/usr/include/c++/4.4/new:91: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.4/new:92: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.4/new:95: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.4/new:96: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.4/new:101: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.4/new:102: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/home/cesare/Programmi/changemesh/project/source/Mesh.cpp: In constructor
'Mesh::Mesh(const char*)':
/home/cesare/Programmi/changemesh/project/source/Mesh.cpp:20: warning: extended
initializer lists only available with -std=c++0x or -std=gnu++0x
/home/cesare/Programmi/changemesh/project/source/Mesh.cpp:20: error: array must
be initialized with a brace-enclosed initializer
/home/cesare/Programmi/changemesh/project/source/Mesh.cpp:20: confused by
earlier errors, bailing out
Preprocessed source stored into /tmp/ccHoqRKs.out file, please attach this to
your bugreport.


-- 
   Summary: [4.4/4.5 regression] ICE in error recovery
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-12-08 11:01 
---
We are still missing Mesh.ii. And, please, do your best to reduce it before
attaching it, thanks in advance...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2009-12-08 11:04 ---
Created an attachment (id=19257)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19257&action=view)
preprocessed source


-- 


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-12-08 11:06 
---
Thanks ;)


-- 


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-08 11:06:40
   date||


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5
   Target Milestone|--- |4.4.3


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[doko at ubuntu dot com]

--- Comment #4 from doko at ubuntu dot com  2009-12-08 11:08 ---
sorry, didn't see the comment before attaching the file


-- 


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-12-08 11:14 
---
No problem. Please, try to figure out something small, shouldn't be that
difficult, I think it should involve only 'int typele[7][2]' vs 'typele={0}'


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-12-08 11:19 
---
This is enough:

class Mesh
{
public:
  Mesh(const char*)
  { typele={0}; }

private:
  int typele[7][2];
};

Mesh m(0);


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Last reconfirmed|2009-12-08 11:06:40 |2009-12-08 11:19:20
   date||


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2009-12-08 11:19:20 |2009-12-08 11:19:32
   date||


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

[Bug c++/29577] overload/SFINAE problem

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2009-12-08 11:21 ---
'typename X::T*' is a non-deduced context, so should not be involved in
argument deduction, and 0 is a valid null pointer constant


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


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/23055] overload resolution does not find templated function (zero -> pointer)

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2009-12-08 11:21 ---
*** Bug 29577 has been marked as a duplicate of this bug. ***


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||m_albert137 at yahoo dot com


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

[Bug c++/42331] [4.4/4.5 regression] ICE in error recovery

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-12-08 11:21 
---
Let's CC Jason, maybe it's just matter of robustifying a tad the initializer
list code.


-- 

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

[Bug fortran/41177] Wrong base-object checks for type-bound procedures

[domob at gcc dot gnu dot org]

--- Comment #5 from domob at gcc dot gnu dot org  2009-12-08 11:39 ---
Subject: Bug 41177

Author: domob
Date: Tue Dec  8 11:39:20 2009
New Revision: 155086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155086
Log:
2008-12-08  Daniel Kraft  

PR fortran/41177
* gfortran.dg/typebound_proc_4.f03: Remove check for wrong error.
* gfortran.dg/typebound_proc_13.f03: New test.

2008-12-08  Daniel Kraft  

PR fortran/41177
* gfortran.h (struct symbol_attribute): New flag `class_pointer'.
* symbol.c (gfc_build_class_symbol): Set the new flag.
* resolve.c (update_compcall_arglist): Remove wrong check for
non-scalar base-object.
(check_typebound_baseobject): Add the correct version here as well
as some 'not implemented' message check in the old case.
(resolve_typebound_procedure): Check that the passed-object dummy
argument is scalar, non-pointer and non-allocatable as it should be.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_proc_13.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_call_4.f03


-- 


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

[Bug objc/42293] Can't build ObjC runtime library with GC for W32 target

[ktietz at gcc dot gnu dot org]

--- Comment #4 from ktietz at gcc dot gnu dot org  2009-12-08 11:41 ---
(In reply to comment #3)
> Created an attachment (id=19235)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19235&action=view) [edit]
> Diff file
> 
> This allows me to compile it, but quoting from windef.h: /* FIXME: Is there a
> good solution to this? */
> 

Well, this issue is known to me. Changing the order here can work-a-round it,
but possibly leads to other issues, as windef.h will redefine it.
In mingw-w64 platform headers we worked-a-round this by checking for __OBJC__
to check, if we shouldn't define BOOL. But of course this also just a hack.
The real issue for w32/w64 targets is, that type BOOL is part of the platform
header API definition, which conflicts here.

Kai


-- 


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

[Bug fortran/38849] ICE in fold_convert with C_F_POINTER and C binding

[domob at gcc dot gnu dot org]

-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/41177] Wrong base-object checks for type-bound procedures

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2009-12-08 11:45 ---
This fixes most of the issues mentioned, except that it does not yet allow
calling an ELEMENTAL type-bound procedure on a non-scalar base object; this
leads to an ICE and thus I disabled it for now.  I'll keep on working on this
(maybe for next stage 1, though).


-- 


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

[Bug bootstrap/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c

[ramana at gcc dot gnu dot org]

--- Comment #13 from ramana at gcc dot gnu dot org  2009-12-08 11:47 ---
I see this with last night's trunk on a native armv5te linux machine with 512MB
of RAM. 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Priority|P3  |P2
   Last reconfirmed|2009-12-07 17:01:24 |2009-12-08 11:47:37
   date||


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

[Bug fortran/41177] Wrong base-object checks for type-bound procedures

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2009-12-08 11:48 ---
Created an attachment (id=19258)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19258&action=view)
Test case for ELEMENTAL type-bound procedure call

This is a test-case for the still missing part as per the last comment I
already worked out; just attaching it so it is not lost accidentally (and as
reference for what I'm thinking about).


-- 


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[aijunbai at gmail dot com]

--- Comment #5 from aijunbai at gmail dot com  2009-12-08 11:52 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > and i don't want to write lots of "const int A::i"...
> > 
> > You have to, your code is not valid if you use A::i in the program but it 
> > has
> > no definition.  This is not a compiler bug.
> 
> Actually you don't have to write lots, just one:
> 
> template const A::i;
> 

I tried so, but it seems do not work, could you please explain more detailedly?
thx~


-- 


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

[Bug target/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2009-12-08 11:54 
---
It needs 60MB on i?86-linux with -O2 -g -fschedule-insns.  Thus this is a
target specific problem.  Is the arm automaton particularly large?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |target
   Keywords||build


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

[Bug rtl-optimization/42294] [4.5 Regression] ICE in code_motion_path_driver for 416.gamess

[amonakov at gcc dot gnu dot org]

--- Comment #4 from amonakov at gcc dot gnu dot org  2009-12-08 11:55 
---
(In reply to comment #3)
> Also not reproducible on x86_64->ppc64 cross.
> While codegen differences on ppc/ppc64/x86_64 cross are certainly surprising,
> in the end this testcase most likely indicates a bug in sel-sched.

Reprodicible on x86_64->ppc64 cross with -fno-section-anchors appended to
command line.  Native ppc64 compiler seems to not use section anchors on this
testcase.


-- 


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

[Bug c++/42325] internal compiler error: in instantiate_decl (with checking enabled)

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2009-12-08 12:19 ---
Created an attachment (id=19259)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19259&action=view)
reduced testcase

pr42325-reduced.cpp:2:27: error: template parameters not used in partial
specialization:
pr42325-reduced.cpp:2:27: error: ‘’
pr42325-reduced.cpp: In function ‘void to_string()’:
pr42325-reduced.cpp:9:21:   instantiated from ‘static void
char_traits::assign()’
pr42325-reduced.cpp:9:21:   instantiated from here
pr42325-reduced.cpp:9:21: internal compiler error: in instantiate_decl, at
cp/pt.c:16361


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

  Attachment #19251|0   |1
is obsolete||


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[redi at gcc dot gnu dot org]

--- Comment #6 from redi at gcc dot gnu dot org  2009-12-08 12:23 ---
(In reply to comment #5)
> > 
> > template const A::i;
> > 
> 
> I tried so, but it seems do not work, could you please explain more 
> detailedly?
> thx~

I missed the "int" out:

template const int A::i;


-- 


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

[Bug c++/42317] [4.5 Regression] Issues with comdat virtual dtors

[doko at ubuntu dot com]

--- Comment #5 from doko at ubuntu dot com  2009-12-08 12:36 ---
yes, re-testing with the version from the ML. currently passed the libstdc++
build.


-- 


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

[Bug target/42323] bootstrap error in libstdc++ powerpc biarch compiler, building 64bit libstdc++ debug lib

[debian-gcc at lists dot debian dot org]

--- Comment #2 from debian-gcc at lists dot debian dot org  2009-12-08 
12:37 ---


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


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42317] [4.5 Regression] Issues with comdat virtual dtors

[debian-gcc at lists dot debian dot org]

--- Comment #6 from debian-gcc at lists dot debian dot org  2009-12-08 
12:37 ---
*** Bug 42323 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[aijunbai at gmail dot com]

--- Comment #7 from aijunbai at gmail dot com  2009-12-08 13:02 ---
(In reply to comment #6)
> (In reply to comment #5)
> > > 
> > > template const A::i;
> > > 
> > 
> > I tried so, but it seems do not work, could you please explain more 
> > detailedly?
> > thx~
> 
> I missed the "int" out:
> 
> template const int A::i;
> 

thanks for your help, but it still can not be compiled under gcc 4.4.1


-- 


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

[Bug c++/42325] internal compiler error: in instantiate_decl (with checking enabled)

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-12-08 13:11 
---
Likely a duplicate of PR34491.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-08 13:11:32
   date||


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-12-08 13:12 
---
Then show here exactly what you are trying to compile. Note: this is *not*
gcc-help.


-- 


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

[Bug middle-end/38474] [Meta] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[matz at gcc dot gnu dot org]

--- Comment #45 from matz at gcc dot gnu dot org  2009-12-08 13:56 ---
Subject: Bug 38474

Author: matz
Date: Tue Dec  8 13:56:06 2009
New Revision: 155087

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155087
Log:
PR middle-end/38474
* function.c (free_temp_slots): Only walk the temp slot
addresses and combine slots if we actually changes something.
(pop_temp_slots): Ditto.

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


-- 


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

[Bug c++/42332] New: Illegal instruction generated while compiling with optimization

[pbdr at uea dot ac dot uk]

While compiling a simple class containing a std::tr1::unordered_map member as a
library, linking to the library and creating an object generate illegal
hardware instruction. Or at least, running the code raise a SIGILL. The library
file is lib.cc and the main program is test_lib.cc. The commands used to
compile the two are:

g++ -W -Wall --fast-math -msse4 -shared -o libl.so lib.cc -fPIC
g++ -W -Wall --fast-math -msse4 -o test_lib test_lib.cc -L. -ll

The bug appears only if both --fast-math and -msse4 are used. The bug already
existed in g++ 4.4.1 (the one with provided by Fedora 11).

Here are the informations about the version of gcc I use:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/stow/gcc-4.4.2
Thread model: posix
gcc version 4.4.2 (GCC)


-- 
   Summary: Illegal instruction generated while compiling with
optimization
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pbdr at uea dot ac dot uk
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/42332] Illegal instruction generated while compiling with optimization

[pbdr at uea dot ac dot uk]

--- Comment #1 from pbdr at uea dot ac dot uk  2009-12-08 14:00 ---
Created an attachment (id=19260)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19260&action=view)
preprocessed file for the library


-- 


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

[Bug c++/42332] Illegal instruction generated while compiling with optimization

[pbdr at uea dot ac dot uk]

--- Comment #2 from pbdr at uea dot ac dot uk  2009-12-08 14:00 ---
Created an attachment (id=19261)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19261&action=view)
preprocessed file for the main program


-- 


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

[Bug c++/42332] Illegal instruction generated while compiling with optimization

[pbdr at uea dot ac dot uk]

-- 

pbdr at uea dot ac dot uk changed:

   What|Removed |Added

   Severity|normal  |critical


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

[Bug c++/42332] Illegal instruction generated while compiling with optimization

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[aijunbai at gmail dot com]

--- Comment #9 from aijunbai at gmail dot com  2009-12-08 14:06 ---
(In reply to comment #8)
> Then show here exactly what you are trying to compile. Note: this is *not*
> gcc-help.
> 

alright, take the flowing code as an example:

template
struct A {
static const int i = -1;
};

template<>
struct A<0> {
static const int i = 0;
};

template<>
struct A<1> {
static const int i = 1;
};

template  const int A::i;

int foo(int)
{
}

int bar(const int &)
{
}

int main()
{
foo(A<1>::i); //ok here
bar(A<0>::i); //g++ complains undefined reference to `A<0>::i'

return 0;
}


-- 


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

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

--- Comment #24 from burnus at gcc dot gnu dot org  2009-12-08 14:12 ---
Subject: Bug 41711

Author: burnus
Date: Tue Dec  8 14:12:06 2009
New Revision: 155088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155088
Log:
2009-12-08  Tobias Burnus  

PR fortran/41711
* io/read.c (set_integer): Support kind=10 for reading
real/complex BOZ.

2009-12-08  Tobias Burnus  

PR fortran/41711
* gfortran.dg/boz_15.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/boz_15.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/read.c


-- 


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

[Bug testsuite/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-12-08 
14:13 ---
Mike Stump says that the frame can be optimized away on darwin.  However,
Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...

 [MacPro:~/bug] howarth% gcc-4.2 -O2 -fomit-frame-pointer -m32 --save-temps -c
builtin-unreachable.c
 [MacPro:~/bug] howarth% more builtin-unreachable.s
.text
.align 4,0x90
 .globl _h
 _h:
subl$12, %esp
movl16(%esp), %eax
 cmpb$0, (%eax)
je  L2
call___builtin_unreachable
 L2:
movl$1, %eax
addl$12, %esp
ret
.subsections_via_symbols  



-- 


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

[Bug c++/42330] undefined reference to "static const int" in class when passing as "const int &" to a function

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-12-08 14:15 
---
Since you have specializations for A, you also need, in general, the
corresponding definitions:

const int A<0>::i;
const int A<1>::i;


-- 


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

[Bug middle-end/42228] [4.5 Regression] verify_cgraph_node failed:node has wrong clone_of

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2009-12-08 14:16 
---
After removing a couple of lines from the preprocessed code I end up with the
same problem as in PR41290. Apparently this bug hasn't been fixed and still
haunts us.


-- 


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

[Bug libfortran/41711] [F2008] BOZ edit-descr does not support reading large kind reals

[burnus at gcc dot gnu dot org]

--- Comment #25 from burnus at gcc dot gnu dot org  2009-12-08 14:25 ---
STATUS:

* Writing large-kind real/complex numbers works (cf. comment 10)
* Reading large-kind real/complex numbers works on systems which have
  INTEGER(16) (cf. comment 24, which added REAL(10) support)
* For the standard, see also comment 15. (Valid F2008, maybe valid in F2003.)

TODO:

* Support reading a BOZ into a REAL(10) or REAL(16) variable on systems
  without INTEGER(16) [such as i686/x86(-32)]

WORKAROUND:

- Use a system which has INTEGER(16) or do the reverse of comment 8: Read the
BOZ into a integer(8) size-2 array and TRANSFER its value then to your real(10)
or real(16) variable.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[F2008] BOZ format does not |[F2008] BOZ edit-descr does
   |support reading large kind  |not support reading large
   |reals   |kind reals


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

[Bug c++/42332] Illegal instruction generated while compiling with optimization

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-12-08 14:30 ---
Is your CPU SSE4 capable? cat /proc/cpuinfo would reveal this.
Can you post disassembly at the point of SIGILL (run it under gdb,
p/x $pc
disas $pc-64 $pc+64
info reg
when it crashes?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/42332] Illegal instruction generated while compiling with optimization

[pbdr at uea dot ac dot uk]

--- Comment #4 from pbdr at uea dot ac dot uk  2009-12-08 14:35 ---
Mmmhh ... indeed ... I really though my processor for sse4, but it doesn't seem
to be. Sorry about such a bad mistake.


-- 

pbdr at uea dot ac dot uk changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2009-12-08 14:44 ---
A shorter reproducer is:

struct foo
{
static const bool b = false;
};

template
struct S1
{ 
};

template
struct S2
: S1
{ 
};


-- 


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

[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-12-08 14:45 ---
Created an attachment (id=19262)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19262&action=view)
Candidate patch

I am testing this patch currently.


-- 


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

[Bug c++/42328] rejects valid friend

[igodard at pacbell dot net]

--- Comment #5 from igodard at pacbell dot net  2009-12-08 15:20 ---
Both proposals befriend more than the minimum actually needed by program
semantics. The former befriends any member of freeList, not just foo;
the latter any member of any freeList at all. In addition, the former requires
that bar be a resolved type. Bar is resolved in the simplified example I
submitted, but in the original baz is itself a template and bar is a class
argument, and you get a diagnostic on a friend of the form of the first
suggestion. That's why the friend is a template, not just freeList -
the original code was more like:

template
class   baz : protected freeList,
  protected freeList,
  protected freeList,
  < more, where all but U were resolved types >
 {
template
friend
voidfreeList::foo();
< body of baz >
};

but was simplified for the report.


-- 


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

[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression

[dodji at gcc dot gnu dot org]

--- Comment #6 from dodji at gcc dot gnu dot org  2009-12-08 15:52 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00438.html


-- 


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

[Bug middle-end/42110] [4.5 Regression] ICE with inlining

[hubicka at gcc dot gnu dot org]

--- Comment #8 from hubicka at gcc dot gnu dot org  2009-12-08 15:57 ---
So we have new direct call appearing to function that has been previously
eliminated as unreachable (after inlining) as a result of devirtualization? 
In general if function have address taken, we should not remove it since it is
needed, or is that the special vtable handling?


-- 


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

[Bug middle-end/42110] [4.5 Regression] ICE with inlining

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-12-08 16:01 ---
I assumed it is special vtable handling (that likely doesn't cause the
addressable flag to be set?) - I simply stopped debugging at the point
where I noticed the node gets removed even though there are still
indirect calls that possibly can reach it.


-- 


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

[Bug other/42333] New: complex division failure on darwin10 with -lm

[ghazi at gcc dot gnu dot org]

As noted in PR42074, linking with the math library on darwin10 allows overflow
to occur during complex division.  It was originally reported as a failure in
testcase gcc.dg/torture/builtin-math-7.c at all optimization levels.  However
as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074#c10 the error
is related to using -lm on the reduced testcase below.  Without -lm it passes,
with -lm a failure occurs.  As such, it isn't necessarily a bug in GCC, however
this PR will help track if there is a possible workaround.


int main(void)
{
  volatile _Complex double val = (__DBL_MAX__ * 0.5 + __DBL_MAX__ * 0.5i);
  val /= (__DBL_MAX__ * 0.25 + __DBL_MAX__ * 0.25i);
  __builtin_printf ("%g %g\n", __real (val), __imag (val));
  if (val != 2) __builtin_abort();
  return 0;
}


-- 
   Summary: complex division failure on darwin10 with -lm
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: *-*-darwin10


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

[Bug other/42333] complex division failure on darwin10 with -lm

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-12-08 16:33 ---
> As such, it isn't necessarily a bug in GCC, however
> this PR will help track if there is a possible workaround.

As far as I understand the use of the gcc compilers on darwin, I do not see
when I should use -lm.
So the simplest "workaround" could be to not use -lm in the testsuite at least
for intel-darwin10.
If someone tells me how to do that I can do the testing.


-- 


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

[Bug middle-end/42110] [4.5 Regression] ICE with inlining

[hubicka at ucw dot cz]

--- Comment #10 from hubicka at ucw dot cz  2009-12-08 16:35 ---
Subject: Re:  [4.5 Regression] ICE with inlining

> I assumed it is special vtable handling (that likely doesn't cause the
> addressable flag to be set?) - I simply stopped debugging at the point
> where I noticed the node gets removed even though there are still
> indirect calls that possibly can reach it.

The problem is uglier.  When we clone node and we inline it, we must
keep the clone around (since while inlining we can't apply the changes
needed by ipa-cp clonning or other passes in general). But since this
interfere with reachability as toon noticed, we put this node into
"limbo stage" (i.e. it is around, has no call edges).  When we decide to
materialize it, we add the edges as previously indirect creating the
extra call that should not exist.

I've fixed it by simply removing those edges once clonning is finished.

Honza


-- 


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

[Bug lto/42074] gcc.dg/torture/builtin-math-7.c fails with -flto or -fwhopr

[ghazi at gcc dot gnu dot org]

--- Comment #11 from ghazi at gcc dot gnu dot org  2009-12-08 16:35 ---
(In reply to comment #10)
> I had a look at the problem and found that it is due to the -lm flag used in
> the test suite. [...]
> and tgcc.dg/torture/builtin-math-7.c passes when it is compiled manually
> without -lm.

Thanks.  Clearly now these are separate bugs.  I've opened PR42333 for the
darwin10 issue.  Let's continue the discussion about that problem in that PR.

This PR will remain solely for the -flto/-fwhopr failures.  I've modified the
description accordingly.  Someone who understands LTO needs to investigate the
code from comment#8.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gcc.dg/torture/builtin-math-|gcc.dg/torture/builtin-math-
   |7.c failed  |7.c fails with -flto or -
   ||fwhopr


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

[Bug middle-end/42110] [4.5 Regression] ICE with inlining

[hubicka at gcc dot gnu dot org]

--- Comment #11 from hubicka at gcc dot gnu dot org  2009-12-08 16:36 
---
Testing patch.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-03 05:09:49 |2009-12-08 16:36:42
   date||


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

[Bug other/42333] complex division failure on darwin10 with -lm

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2009-12-08 16:46 ---
(In reply to comment #1)
> > As such, it isn't necessarily a bug in GCC, however
> > this PR will help track if there is a possible workaround.
> As far as I understand the use of the gcc compilers on darwin, I do not see
> when I should use -lm.
> So the simplest "workaround" could be to not use -lm in the testsuite at least
> for intel-darwin10.
> If someone tells me how to do that I can do the testing.

I don't think that's the right approach, that would only mask the bug in the
testsuite but leave it in userland.

IMHO, the first thing we need to understand is *why* the math library is the
trigger.  In the assembler output from Jack in PR42074, the only function calls
are to abort and __divdc3 which is a libgcc2 provided function that performs
the complex division.  I don't see why -lm would override either one, let alone
a GCC internal one.  You may be able to check via "nm" if libm defines it.

Oh wait, try running ldd (or the darwin equivalent) on the shared math library.
 See if it (or any of its dependencies) link in a another darwin copy of
libgcc2 from the system compiler.  Maybe there's an old definition of __divdc3
in there that is overriding the one from gcc-4.5 and yields a bogus result.

Also check if linking staticly solves the problem.  Thanks.


-- 


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

[Bug c/448] -related issues (C99 issues)

[jsm28 at gcc dot gnu dot org]

--- Comment #26 from jsm28 at gcc dot gnu dot org  2009-12-08 17:08 ---
List of remaining target OSes without stdint.h type information added
to 4.5 release notes:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00441.html

NetBSD, VxWorks, VMS, SymbianOS, WinCE, LynxOS, Netware, QNX, Interix, IRIX,
TPF.


-- 


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

[Bug testsuite/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[daney at gcc dot gnu dot org]

--- Comment #5 from daney at gcc dot gnu dot org  2009-12-08 17:34 ---
(In reply to comment #4)
> Mike Stump says that the frame can be optimized away on darwin.  However,
> Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...

That compiler doesn't implement __builtin_unreachable(), so is irrelevant to
the discussion of this bug.

Of interest is why, in a leaf function that doesn't use the stack, the stack
pointer is adjusted.

A darwin hacker will probably have to look into it as I only have access to
GNU/Linux targets.


-- 


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

[Bug debug/42288] please emit empty .debug_aranges section

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2009-12-08 17:58 ---
FWIW, I know that this patch will not affect the CVS gdb,
because that gdb never reads the .debug_aranges section.
I'll try this out using my branch today.


-- 


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

[Bug target/42324] [4.3/4.4/4.5 Regression] Gcc doesn't follow x86-64 psABI on _Bool

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-12-08 18:17 ---
Another testcase:

[...@gnu-26 pr42324]$ cat b3.c 
void foo (unsigned long, unsigned int, unsigned long,
  unsigned int, unsigned int, unsigned int, unsigned int,
  unsigned long, unsigned int);

void bar (_Bool v1, _Bool v2, unsigned char v3, unsigned char v4,
  unsigned char v5, unsigned char v6,
  unsigned char v7, _Bool v8)
{
  foo (v1, v2, v3, v4, v5, v6, v7, v8, v8);
}
[...@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -O2 b3.c -S  
[...@gnu-26 pr42324]$ cat b3.s
.file   "b3.c"
.text
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
.LFB2:
subq$24, %rsp
.LCFI0:
movzbl  %cl, %ecx
movzbl  %dl, %edx
movzbl  40(%rsp), %r10d
movzbl  %sil, %esi
movzbl  %dil, %edi
movzbl  %r9b, %r9d
movzbl  %r8b, %r8d
movzbl  %r10b, %eax
movq%r10, 8(%rsp)
movl%eax, 16(%rsp)
movzbl  32(%rsp), %eax
movl%eax, (%rsp)
callfoo
addq$24, %rsp
ret

icc 11.1 generates:

.globl bar
bar:
# parameter 1: %edi
# parameter 2: %esi
# parameter 3: %edx
# parameter 4: %ecx
# parameter 5: %r8d
# parameter 6: %r9d
# parameter 7: 48 + %rsp
# parameter 8: 56 + %rsp
..B1.1: # Preds ..B1.0
..___tag_value_bar.1:   #8.1
subq  $40, %rsp #8.1
..___tag_value_bar.2:   #
movzbl48(%rsp), %eax#9.32
movzbl56(%rsp), %r10d   #9.36
movl  %eax, (%rsp)  #9.32
movzbl%dil, %edi#8.1
movq  %r10, 8(%rsp) #9.36
movl  %r10d, 16(%rsp)   #9.40
movzbl%sil, %esi#9.12
movzbl%dl, %edx #8.1
movzbl%cl, %ecx #9.20
movzbl%r8b, %r8d#9.24
movzbl%r9b, %r9d#9.28
call  foo   #9.3
# LOE rbx rbp r12 r13 r14 r15
..B1.2: # Preds ..B1.1
addq  $40, %rsp #10.1
..___tag_value_bar.3:   #
ret #10.1

So both gcc and icc treat _Bool parameters in register and on stack
as 1 byte. I think we should just drop

---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---

from psABI since it isn't really followed/used at all.


-- 


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

[Bug target/42324] [4.3/4.4/4.5 Regression] Gcc doesn't follow x86-64 psABI on _Bool

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-12-08 18:26 ---
Both icc and gcc generate:

[...@gnu-26 pr42324]$ cat b4.c
extern unsigned int bartmp;

void foo(_Bool bar)
{
 bartmp = bar;
}
[...@gnu-26 pr42324]$ objdump -dw b4.o

b4.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   40 0f b6 ff movzbl %dil,%edi
   4:   89 3d 00 00 00 00   mov%edi,0x0(%rip)# a 
   a:   c3  retq   
[...@gnu-26 pr42324]$ 


-- 


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

[Bug other/42333] complex division failure on darwin10 with -lm

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-12-08 18:31 ---
(In reply to comment #2)
> I don't think that's the right approach, that would only mask the bug in the
> testsuite but leave it in userland. ...

You are right, but from what follows I think the problem comes from the way the
additional libs are passed to collect2.

First, without -lm, gcc45 uses the following collect2:

 /opt/gcc/gcc4.5w/libexec/gcc/x86_64-apple-darwin10/4.5.0/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.6.2 -weak_reference_mismatches non-weak -o
a.out -lcrt1.10.5.o -L/opt/gcc/gcc4.5w/lib/gcc/x86_64-apple-darwin10/4.5.0
-L/opt/gcc/gcc4.5w/lib/gcc/x86_64-apple-darwin10/4.5.0/../../.. pr42074.o
-lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem

and the test succeed.

Second, if I add -lm, I get

 /opt/gcc/gcc4.5w/libexec/gcc/x86_64-apple-darwin10/4.5.0/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.6.2 -weak_reference_mismatches non-weak -o
a.out -lcrt1.10.5.o -L/opt/gcc/gcc4.5w/lib/gcc/x86_64-apple-darwin10/4.5.0
-L/opt/gcc/gcc4.5w/lib/gcc/x86_64-apple-darwin10/4.5.0/../../.. pr42074.o -lm
-lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem

and the text fails. Note that -lm is passed before "-lgcc_s.10.5 -lgcc_ext.10.5
-lgcc -no_compact_unwind -lSystem".

Third, libm.dylib is a symlink to libSystem.dylib
lrwxr-xr-x 1 root wheel 15 Aug 14 22:47 /usr/lib/libm.dylib -> libSystem.dylib*
so -lm seems redundant.

Fourth, I see

[macbook] f90/bug% otool -L /usr/lib/libSystem.dylib
/usr/lib/libSystem.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.0.0)
/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0,
current version 315.0.0)
[macbook] f90/bug% nm /usr/lib/libSystem.B.dylib | grep divdc3
0019fa1e S $ld$hide$os10.4$___divdc3
0019fa1f S $ld$hide$os10.5$___divdc3
001640d0 T ___divdc3

Five, If I don't use -lm, but place -lSystem before "-lgcc_s.10.5
-lgcc_ext.10.5 -lgcc -no_compact_unwind" as in

[macbook] f90/bug%
/opt/gcc/gcc4.5w/libexec/gcc/x86_64-apple-darwin10/4.5.0/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.6.2 -weak_reference_mismatches non-weak -o
a.out -lcrt1.10.5.o -L/opt/gcc/gcc4.5w/lib/gcc/x86_64-apple-darwin10/4.5.0
-L/opt/gcc/gcc4.5w/lib/gcc/x86_64-apple-darwin10/4.5.0/../../.. pr42074.o
-lSystem -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind

the test abort.

My uneducated conclusions are first, that -lm is redundant with -lSystem and
probably should never be used (unless you ask for trouble), second, ___divdc3
uses a lazy complex division (a bug to be reported upstream!-), third, the way
additional libs are passed to collect2 is probably right if one wants to
overwrite functions in the default libs.

I have now access to intel-darwin9 and I'll see what going on for it after
dinner time.


-- 


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

[Bug tree-optimization/42334] New: segfault in graphite-poly.h for 200.sixtrack

[janis at gcc dot gnu dot org]

GCC trunk gets a segmentation fault when building SPEC CPU2000 test
200.sixtrack with "-floop-interchange -ftree-loop-distribution" on
powerpc-linux, as demonstrated by this minimized testcase:

  subroutine blockdis(bl1eg,bl2eg)
  implicit real*8 (a-h,o-z)
  parameter(nblo=300)
  common/str /mblo
  common/str2 /mel(nblo)
  dimension h(nblo,2,6),g(nblo,2,6)
  dimension bl1eg(nblo,2,6),bl2eg(nblo,2,6)
  do k=1,mblo
jm=mel(k)
do l=1,2
  do m=1,6
bl1eg(k,l,m)=h(jm,l,m)
bl2eg(k,l,m)=g(jm,l,m)
  enddo
enddo
  enddo
  return
  end

n function ‘blockdis’:
bug.f:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.See
 for instructions.

The segfault is in VEC_lst_p_base_iterate at graphite-poly.h:623.

sixtrack passed with the now-failing options until r150248.  With the merge
from the Graphite branch at r150301 that test started failing at runtime.  (In
between those two revisions trunk didn't build with Graphite for
powerpc-linux).  sixtrack failed at runtime with r154631, and GCC started
getting the segmentation fault at r154632.


-- 
   Summary: segfault in graphite-poly.h for 200.sixtrack
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-linux


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

[Bug other/42333] complex division failure on darwin10 with -lm

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-12-08 
19:30 ---
Dominique,
It would be interesting to know what happens with a build of gcc trunk
under darwin10 if you regress out the r154282 and r154283 that introduced the
libgcc_ext feature . I suspect this regression may have occurred at this point.
I wasn't building with mpc before the libgcc_ext patch was committed.


-- 


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

[Bug other/42333] complex division failure on darwin10 with -lm

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-12-08 19:34 ---
Additional information:

(1) I don't see the problem on (i686|x86_64)-apple-darwin9.

(2) I also see it gcc version 4.4.2 (GCC).

(3) I don't see it with gcc version 4.2.1 (Apple Inc. build 5646) (dot 1).

(3) If I compile the test with 4.4.2 or 4.5 with -c, and link the object file
with gcc version 4.2.1 (Apple Inc. build 5646) (dot 1), I get the abort
with/without -lm.

(4) If I do the opposite (object with 4.2, link with 4.5), I don't get the
abort even with -lm.

(5) collect2 for 4.2:

 /usr/libexec/gcc/i686-apple-darwin10/4.2.1/collect2 -dynamic -arch x86_64
-macosx_version_min 10.6.2 -weak_reference_mismatches non-weak -o a.out
-lcrt1.10.6.o -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
-L/usr/lib/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. pr42074.o -lSystem -lgcc
-lSystem

So my second conclusion in comment #3 may be wrong.

I think (2) answer the question in comment #4.


-- 


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-12-08 19:51 ---
I think this comes down to an alignment issue. On darwin, the stack has to be
aligned to 16bytes so something inside i386.c is deciding that we to allocate
the stack frame as there was something on the stack and we have to align it
again.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|testsuite   |target
  GCC build triplet|i686-apple-darwin*  |
   GCC host triplet|i686-apple-darwin*  |
 GCC target triplet|i686-apple-darwin*  |i?86-apple-darwin*
   Keywords||missed-optimization


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

[Bug other/42333] complex division failure on darwin10 with -lm

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2009-12-08 
19:59 ---
Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
unclear what that test should do there. Try reverting out the libgcc_ext
changes from gcc trunk on darwin10 instead.


-- 


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

[Bug c++/31956] names declared in a condition may be redeclared

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-12-08 20:21 ---
There's been an XFAIL about this in g++.old-deja/g++.jason/cond.C for ages, but
it doesn't test the switch case.

Self-contained testcase:

void f() {
  if (int foo = 0)
int foo = 1;

  switch (int foo = 0)
  {
  default:
int foo = 1;
  }
}


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
  Known to fail||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2009-12-08 20:21:14
   date||


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

[Bug c++/31956] names declared in a condition may be redeclared

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-12-08 20:24 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/18770] g++ accepts invalid code with scopes on ifs

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-12-08 20:24 ---
*** Bug 31956 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andrew dot stubbs at st dot
   ||com


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

[Bug other/42333] complex division failure on darwin10 with -lm

[ghazi at gcc dot gnu dot org]

--- Comment #7 from ghazi at gcc dot gnu dot org  2009-12-08 20:24 ---
(In reply to comment #6)
> Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
> unclear what that test should do there. 

Jack - Focusing on builtin-math-7.c (which tests multiple things) misses the
point.  The bug on darwin10 is exposed by a trivial runtime complex division. 
See the code from the original description above.  That code should work on 4.4
branch, etc and that is what Dominique is compiling with other gcc versions.

Note I'm not commenting on your suggested patch revert, I don't know enough
about Darwin to predict whether that will be fruitful.  I just want to make
sure we all understand that the reduced testcase I provided should work on all
GCC versions that support complex numbers.


-- 


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

[Bug other/42333] complex division failure on darwin10 with -lm

[developer at sandoe-acoustics dot co dot uk]

--- Comment #8 from developer at sandoe-acoustics dot co dot uk  2009-12-08 
20:27 ---
(In reply to comment #6)

A *Very* quick look following a prompt from Jack...

> Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
> unclear what that test should do there. Try reverting out the libgcc_ext
> changes from gcc trunk on darwin10 instead.

removing the _ext should have no effect since -lgcc, which follows it, but
precedes the -lSystem should cause the math function to be linked statically
from libgcc.a (4.5 version)
[the _ext will cause it to be linked dynamically from libgcc_s (4.5 version)]

it seems on the face of it that there's different behavior from this function
as supplied by the Darwin environment [libmath=>libSystem] and as supplied by
gcc. 

Of course, it's also possible that the code differs between the static and
dynamic builds of libgcc... 


-- 

developer at sandoe-acoustics dot co dot uk changed:

   What|Removed |Added

 CC||developer at sandoe-
   ||acoustics dot co dot uk


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

[Bug c++/28584] Cast to pointer from integer of different size

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-12-08 20:32 ---
reduced:
void f() {
  unsigned short i = 0;
  void* p = (void*)i;
}
this warns in 32-bit or 64-bit mode using the C compiler, and is controlled by
this option that g++ doesn't support:

-Wno-int-to-pointer-cast (C and Objective-C only)
Suppress warnings from casts to pointer type of an integer of a different size.


-- 


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

[Bug fortran/32489] Endless loop when compiling - middle-end?

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-12-08 20:32 
---
This really is not a duplicate of PR20923.  In fact the gfortran frontend makes
it through the fft257.f90 test case in a few seconds.  The memory hogging and
cycling is happening in middle-end.

With a simple variation of the patch in comment #5, I am able to achieve the
2.5 second compilation with only one regression.  I am not sure there is a way
to discern the difference between the fft257.f90 and array_constructor_20.f90. 
The difference being one has the initialization has a parameter and the other
not.  I plan to explore further and report back here.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
   Keywords|ice-on-valid-code   |compile-time-hog
 Resolution|DUPLICATE   |
Summary|Endless loop when compiling |Endless loop when compiling
   ||- middle-end?


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

[Bug fortran/34402] Diagnose illegal initialization of derived type containing allocatable component

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-12-08 20:33 ---
(In reply to comment #0)
> ! The following is illegal!
>   type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )

I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
example (figure 12.3, p243) for allocatable components. I don't have the
standard section, but Metcalf states:
"In a structure constructor, an expression corresponding to an allocatable
component must be an array or a reference to the intrinsic function NULL with
no arguments. [...] If it is an array, but not an allocatable array, the
component is allocated with the same bounds and is assigned the same value."

If compiled with "-std=f95", gfortran complains about allocatable components in
general and accepts it with "-std=f2003". So, where's the actual problem?


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|NEW |WAITING


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

[Bug c++/29427] uncallable constructor template should be warned.

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-12-08 20:45 ---
diagnosing this would be useful and shouldn't require instantiation, it should
be detectable during phase 1

reduced:
struct foo {
  template foo(int);
};


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
  Known to fail||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2009-12-08 20:45:06
   date||


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

[Bug other/42333] complex division failure on darwin10 with -lm

[developer at sandoe-acoustics dot co dot uk]

--- Comment #9 from developer at sandoe-acoustics dot co dot uk  2009-12-08 
20:51 ---

> version 125.0.0)
> /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0,
> current version 315.0.0)
> [macbook] f90/bug% nm /usr/lib/libSystem.B.dylib | grep divdc3
> 0019fa1e S $ld$hide$os10.4$___divdc3
> 0019fa1f S $ld$hide$os10.5$___divdc3
> 001640d0 T ___divdc3

This will cause a difference in behavior:
 for Darwin9
___divdc3 is provided by /usr/lib/libgcc_s.1.dylib

libm.dylib => libSystem.dylib (which does not define ___divdc3) 

So, for darwin 10, -lm will cause the "system ___divdc3" to be used instead of
the gcc one.

For Darwin 9 there is no "system provided ___divdc3" (AFAICT) .. it is supplied
from libgcc_s.1.dylib.

if this is a reproducible effect with a short piece of code - one would expect
if to manifest using Apple's  supplied 4.2 ... and a radar could be filed.

I was under the impression that -lm was not used by default for Darwin
(determined in the build of the gcc driver) - is this flag being manually added
by the test case?


-- 


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