[Bug tree-optimization/42285] ICE in Graphite's scan_tree_for_params for 416.gamess

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2009-12-09 04:56 ---
Fixed in the Graphite branch, I will commit this to trunk once it passes
regtest on the branch.

Sebastian


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42285] ICE in Graphite's scan_tree_for_params for 416.gamess

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-12-09 04:55 ---
Subject: Bug 42285

Author: spop
Date: Wed Dec  9 04:54:54 2009
New Revision: 155100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155100
Log:
Fix PR42285.

2009-12-08  Sebastian Pop  

PR middle-end/42285
* graphite-scop-detection.c (graphite_can_represent_init): Also
handle more complex MULT_EXPRs containing parameters by recursion
on the structure.

* testsuite/gfortran.dg/graphite/pr42285.f90: New.

Added:
branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42285.f90
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-scop-detection.c


-- 


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

[Bug bootstrap/37079] cannot find -lgcc_s

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-12-09 
04:21 ---
(In reply to comment #6)
> I have this problem of MacOSX 10.3
> $ gcc -v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)
> 
> When I do a make on an empty directory it gets all the way into stage3 linking
> libstdc++ until this:
> 
> /usr/bin/ld: can't locate file for: -lgcc_s.10.4
> 
> There are several libgcc_s around:
> 
> MacOSX:~/obj ed$ find . -name libgcc_s\*
> ./gcc/libgcc_s.1.dylib
> ./gcc/libgcc_s_ppc64.1.dylib
> ./gcc/libgcc_s_x86_64.1.dylib
> ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
> ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
> ./prev-gcc/libgcc_s.1.dylib
> ./prev-gcc/libgcc_s_ppc64.1.dylib
> ./prev-gcc/libgcc_s_x86_64.1.dylib
> ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
> ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
> ./stage1-gcc/libgcc_s.1.dylib
> ./stage1-gcc/libgcc_s_ppc64.1.dylib
> ./stage1-gcc/libgcc_s_x86_64.1.dylib
> ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
> ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
> 
> I'm actually surprised by the ppc64 and x86_64 libs - I'm not building a cross
> compiler.
> 

I would be shocked if gcc trunk built on darwin7. Unless I am mistaken, we now
assume
that all darwin targets support dwarf which isn't the default case until Xcode
2.4 (10.4).


-- 


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

[Bug regression/42258] redundant register move around mul instruction

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2009-12-09 02:27 ---
Gcc 4.4 doesn't have this problem. It is a new regression caused by patch
152533.


-- 

carrot at google dot com changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com
  Component|target  |regression


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

[Bug bootstrap/37079] cannot find -lgcc_s

[3dw4rd at verizon dot net]

--- Comment #6 from 3dw4rd at verizon dot net  2009-12-09 02:00 ---
I have this problem of MacOSX 10.3
$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)

When I do a make on an empty directory it gets all the way into stage3 linking
libstdc++ until this:

/usr/bin/ld: can't locate file for: -lgcc_s.10.4

There are several libgcc_s around:

MacOSX:~/obj ed$ find . -name libgcc_s\*
./gcc/libgcc_s.1.dylib
./gcc/libgcc_s_ppc64.1.dylib
./gcc/libgcc_s_x86_64.1.dylib
./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
./prev-gcc/libgcc_s.1.dylib
./prev-gcc/libgcc_s_ppc64.1.dylib
./prev-gcc/libgcc_s_x86_64.1.dylib
./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
./stage1-gcc/libgcc_s.1.dylib
./stage1-gcc/libgcc_s_ppc64.1.dylib
./stage1-gcc/libgcc_s_x86_64.1.dylib
./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib

I'm actually surprised by the ppc64 and x86_64 libs - I'm not building a cross
compiler.


-- 

3dw4rd at verizon dot net changed:

   What|Removed |Added

 CC||3dw4rd at verizon dot net


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #18 from howarth at nitro dot med dot uc dot edu  2009-12-09 
01:11 ---
Actually, I found this file which is quite interesting in the darwin10 libgcc
open source release...

http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c


-- 


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

[Bug rtl-optimization/42269] [4.4/4.5 Regression] Extra sign extension instructions generated

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2009-12-09 00:36 ---
I see the same fails as HJL on hppa-unknown-linux-gnu.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

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

[ghazi at gcc dot gnu dot org]

--- Comment #17 from ghazi at gcc dot gnu dot org  2009-12-09 00:34 ---
(In reply to comment #15)
> (In reply to comment #13)
> > You can try filing a bug report at Apple, but I think a better route would 
> > be
> > to see if we can avoid linking in the system ___divdc3  from FSF GCC.
> > 
> This may be impossible without having FSF gcc access its own ___divdc3 under
> a different symbol name. The functionality of libgcc has been subsumed into
> libSystem in darwin10 and the symbols from libgcc itself are supposed to be 
> ignored in favor of those from libSystem...
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

I don't think we should get into a cat-and-mouse game of renaming functions
that *are already FSF functions* just to avoid Apple's rewritten versions. 
Who's to say they won't override the new name(s) in a future release with the
same broken copy(ies)?  The sad thing is they changed ___divdc3 and they don't
even emit it from their compiler. :-/

If you want to file a bug report at Apple using the FSF generated assembly (and
C testcase for reference), please proceed.  I hope they fix their ___divdc3
routine.  Note there may be other complex math things they've rewritten. 
Someone would need to audit Apple's compiler to see what else they've changed.

On what to do about builtin-math-7.c testcase, my inclination is we should just
XFAIL it for darwin10 since fixing darwin's ___divdc3 won't help with
distributions out in the field.


-- 


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

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

[w6ws at earthlink dot net]

--- Comment #5 from w6ws at earthlink dot net  2009-12-09 00:27 ---
(In reply to comment #4)
> ... it dawns on me that the crucial point is, that variables with
> initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE
> components. Correct?

I am not sure why they put the restriction in.  But note that one *can* use
null() in a structure constructor for the allocatable component.  So the
following is legal:

  type xyzzy
integer, allocatable :: x(:)
real :: y
  end type

  type(xyzzy) :: plugh = xyzzy (null (), 123.456)

See 7.1.7(3) in F2003 (and 7.1.12(3) in the F2008 draft.)


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #16 from howarth at nitro dot med dot uc dot edu  2009-12-09 
00:19 ---
I can confirm that the gcc.dg/torture/builtin-math-7.c testcases still fail
under darwin10 if the libgcc_ext changes are regressed out.


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2009-12-09 
00:12 ---
(In reply to comment #13)
> You can try filing a bug report at Apple, but I think a better route would be
> to see if we can avoid linking in the system ___divdc3  from FSF GCC.
> 

This may be impossible without having FSF gcc access its own ___divdc3 under
a different symbol name. The functionality of libgcc has been subsumed into
libSystem in darwin10 and the symbols from libgcc itself are supposed to be 
ignored in favor of those from libSystem...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html


-- 


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

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

[ghazi at gcc dot gnu dot org]

--- Comment #14 from ghazi at gcc dot gnu dot org  2009-12-09 00:06 ---
(In reply to comment #11)
> I think I understand why apple gcc42 does not show the problem: it does not
> call ___divdc3:

It is possible that some versions of GCC (Apple's and/or FSF's) inline the
assembly code to do the divide.  That would explain why they don't call
___divdc3.  Then what happens only depends on what version of the algorithm
they inline, not what they link against.


> ...
> This also explain why the test compiled with -c and 4.5, but linked with 4.2
> fails. So my guess about the lazy complex division seems right in libm. Could
> someone write a C code forcing the use of ___divdc3?

I don't think it makes sense to consider user code calling ___divdc3 directly. 
According to the C standard, functions that begin with double underscore are
reserved for the compiler and/or system libraries.  That is exactly how they
are being used here.  The call should only be generated by the compiler itself
as a service function to perform something like a complex divide.


-- 


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

[Bug tree-optimization/41035] AIX cexp builtin underflow

[dje at gcc dot gnu dot org]

--- Comment #2 from dje at gcc dot gnu dot org  2009-12-09 00:03 ---
libmpfr must be a shared object because libmpc relies on hidden, global state
in libmpfr.  If libmpfr is linked statically with libmpc and with GCC, each
receives different instances of the global variables.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

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

[ghazi at gcc dot gnu dot org]

--- Comment #13 from ghazi at gcc dot gnu dot org  2009-12-08 23:58 ---
(In reply to comment #12)
> .. seems likely that there are two things here: 1. we seem to be generating
> (probably) less efficient code than older versions of the compiler ... and 2.
> possibly the ___divdc3 in /usr/lib/libSystem is faulty?

There are more than one way of generating a complex divide.  One way is faster,
but it's naive (lazy) and leads to errors and overflow.  A second way is
correct in more cases, but a little slower.

FSF GCC defaults to choosing correctness over speed, unless the user asks for
extra speed with a special flag.  There are flags in FSF GCC for example that
allow one to use the "lazy" complex divide algorithms, but the default is
correctness.

It appears that the Apple GCC has chosen to have their ___divdc3 routine follow
the lazy algoritm in the name of speed.  This must have been a concious choice
on their part.  Therefore filing a bug report against it is likely to get a
response of "works as intended."

You can try filing a bug report at Apple, but I think a better route would be
to see if we can avoid linking in the system ___divdc3 from FSF GCC.


-- 


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

[Bug c++/32505] Partial specialization halfway accepted after instantiation

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2009-12-08 23:54 ---
[temp.class.spec]/1
"A partial specialization shall be declared before the first use of a
class template specialization that would make use of the partial specialization
as the result of an implicit or explicit instantiation in every translation
unit in which such a use occurs; no diagnostic is required."

So this is definitely not a bug, but a warning here might be a nice
improvement.


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

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

[developer at sandoe-acoustics dot co dot uk]

--- Comment #12 from developer at sandoe-acoustics dot co dot uk  
2009-12-08 23:40 ---
(In reply to comment #11)
> I think I understand why apple gcc42 does not show the problem: it does not
> call ___divdc3:
> 
> [macbook] f90/bug% diff -up pr42333_42.s pr42333_45.s
> --- pr42333_42.s2009-12-08 23:00:29.0 +0100
> +++ pr42333_45.s2009-12-08 23:00:07.0 +0100
> ...
> @@ -15,68 +15,61 @@ LCFI2:
> movq%rax, -16(%rbp)
> movabsq $9214364837600034815, %rax
> movq%rax, -8(%rbp)
> -   movq-16(%rbp), %rax
> -   movq-8(%rbp), %rdx
> -   movq%rax, -24(%rbp)
> -   movsd   -24(%rbp), %xmm1
> +   movq-16(%rbp), %rdx
> +   movq-8(%rbp), %rax
> movq%rdx, -24(%rbp)
> movsd   -24(%rbp), %xmm0
> -   movapd  %xmm0, %xmm2
> -   addsd   %xmm1, %xmm2
> -   movapd  %xmm0, %xmm3
> -   subsd   %xmm1, %xmm3
> -   movsd   LC1(%rip), %xmm0
> -   movapd  %xmm2, %xmm1
> -   divsd   %xmm0, %xmm1
> -   movsd   LC1(%rip), %xmm0
> -   movapd  %xmm3, %xmm2
> -   divsd   %xmm0, %xmm2
> -   movapd  %xmm2, %xmm0
> -   movsd   %xmm1, -24(%rbp)
> -   movq-24(%rbp), %rax
> +   movq%rax, -24(%rbp)
> +   movsd   -24(%rbp), %xmm1
> +   movsd   LC2(%rip), %xmm3
> +   movsd   LC2(%rip), %xmm2
> +   call___divdc3
> movsd   %xmm0, -24(%rbp)
> movq-24(%rbp), %rdx
> ...
> 
> This also explain why the test compiled with -c and 4.5, but linked with 4.2
> fails. So my guess about the lazy complex division seems right in libm. Could
> someone write a C code forcing the use of ___divdc3?

hmm.. indeed and, in fact, Apple's gcc-4.0 does not call ___divdc3 either (in
fact, in a quick go at manipulation of options I couldn't find a case forcing
either to call it).

As far as generation of a test case is concerned - why not just use the asm
generated by 4.5?

I'll crank up a mini with D10 tomorrow (if possible).. if the asm gives a fault
on D10 with 4.2 then that should be a file-able radar.

.. seems likely that there are two things here: 1. we seem to be generating
(probably) less efficient code than older versions of the compiler ... and 2.
possibly the ___divdc3 in /usr/lib/libSystem is faulty?

has anyone tried this on PPC?


-- 


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

[Bug c++/42338] New: [c++0x] ICE on decltype usage with templates

[onay at ee dot bilkent dot edu dot tr]

The following code causes an ICE with segmentation fault:
--
#include 
#include 

template< typename T1 >
void vadd(const std::vector< T1 > &a, decltype(a[0]) t) {
std::cout << "-> ICE \n";
}
void vadd(const std::vector< int > &a, decltype(a[0]) t) {
std::cout << " compiles \n";
}


int main() {
std::vector< int > a;
std::vector< float > b;
int c;
vadd(b,c); // leads to ICE
// vadd(a,c); // compiles
}
--
Output of 
"g++ -v -save-temps   gcc-error-src.cpp -o gcc-error -std=c++0x"
yields:

Using built-in specs.   
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu  
Thread model: posix 
gcc version 4.4.2 (Debian 4.4.2-3)  
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcc-error' '-std=c++0x'
'-shared-libgcc' '-mtune=generic'   
 /usr/lib/gcc/x86_64-linux-gnu/4.4.2/cc1plus -E -quiet -v -D_GNU_SOURCE
gcc-error-src.cpp -mtune=generic -std=c++0x -fpch-preprocess -o
gcc-error-src.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.4.2/../../../../x86_64-linux-gnu/include"  
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"  
#include "..." search starts here:  
#include <...> search starts here:  
 /usr/include/c++/4.4   
 /usr/include/c++/4.4/x86_64-linux-gnu  
 /usr/include/c++/4.4/backward  
 /usr/local/include 
 /usr/lib/gcc/x86_64-linux-gnu/4.4.2/include
 /usr/lib/gcc/x86_64-linux-gnu/4.4.2/include-fixed  
 /usr/include   
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcc-error' '-std=c++0x'
'-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.4.2/cc1plus -fpreprocessed gcc-error-src.ii
-quiet -dumpbase gcc-error-src.cpp -mtune=generic -auxbase gcc-error-src
-std=c++0x -version -o gcc-error-src.s
GNU C++ (Debian 4.4.2-3) version 4.4.2 (x86_64-linux-gnu)
compiled by GNU C version 4.4.2, GMP version 4.3.1, MPFR version
2.4.1-p2.
warning: MPFR header version 2.4.1-p2 differs from library version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 76c61736f716d7c937923f7eb86174cd
gcc-error-src.cpp:19: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [c++0x] ICE on decltype usage with templates
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: onay at ee dot bilkent dot edu dot tr


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

[Bug c++/31755] Clarify NULL pointer conversion to other types in initialiser

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-12-08 23:29 ---
(In reply to comment #0)
> Could the warning message below be revised to include a warning that NULL will
> evaluate to false or zero?

What else would it evaluate to?

N.B. with recent versions of GCC -Wconversion is needed and the conversion to
bool no longer warns


-- 


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

[Bug c++/32204] friend from global namespace in template class ignored

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-12-08 23:11 ---
Confirmed, the friend declaration appears to be declaring f in namespace A,
despite the :: qualifier


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2009-12-08 23:11:05
   date||


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

[Bug tree-optimization/42337] GCC ICE in compute_antic, at tree-ssa-pre.c:2534

[xinliangli at gmail dot com]

--- Comment #1 from xinliangli at gmail dot com  2009-12-08 23:10 ---
Created an attachment (id=19263)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19263&action=view)
bug test case


-- 


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

[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h

[viriketo at gmail dot com]

--- Comment #3 from viriketo at gmail dot com  2009-12-08 23:07 ---
I already sent the patch to the mailing list mentioned.

I noticed this problem also affects gcc 4.4.2. The same patch can be applied.


-- 


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

[Bug tree-optimization/42337] New: GCC ICE in compute_antic, at tree-ssa-pre.c:2534

[xinliangli at gmail dot com]

Compiling the attached test case, trunk gcc ICEs (or run out of memory without
the checking). The symptom is similar to the one before PR/41101

The root cause of the problem is the result of an expr's phi_translate depends
on the context it is done -- it may return NULL if it is translated as a
sub-expression due to a bug in the cycle detection.  In this case, after
inlining, there is a loop with swapping code. In computing the ANTIC_IN for the
latch block, the resulting set is ping-ponging -- with two expressions
translated to each other back and forth. The reason that only one of the
expression is in the initial set is due to the translation bug mentioned above.


David


-- 
   Summary: GCC ICE  in compute_antic, at tree-ssa-pre.c:2534
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug tree-optimization/42231] [4.4 Regression] Wrong generated code when using a callback function (possible callback function inlining bug ?)

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2009-12-08 22:56 ---
Patch submitted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00458.html


-- 


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

[Bug c++/42336] New: [c++0x] ICE with pointer-to-member-function decltype argument in template function

[aaz at althenia dot net]

The following reduced program produces an ICE when compiled with
-std=c++0x -O2 -g.

=
struct X {
  void func() {}
};

template
void b(T) {}

int main() {
  b(X()); /* line 9 */
  X().func();

  return 0;
}
=

1.cc: In function 'void b(T) [with T = X, U = void (X::*)()]':
1.cc:9:9: internal compiler error: in build_ptrmem_type, at cp/decl.c:7202


And the following variation produces a different ICE.

===
struct X {
  void func() {}
};

template
struct A {};

template
void b(T) {}

int main() {
  b(A());
  X().func();

  return 0;
}
===

Internal compiler error: Error reporting routines re-entered.


-- 
   Summary: [c++0x] ICE with pointer-to-member-function decltype
argument in template function
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaz at althenia dot net
 GCC build triplet: x86_64-portbld-freebsd8.0
  GCC host triplet: x86_64-portbld-freebsd8.0
GCC target triplet: x86_64-portbld-freebsd8.0


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

[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi

[laurent at guerby dot net]

--- Comment #6 from laurent at guerby dot net  2009-12-08 22:41 ---
Note: armv7l 4.4.2 also fails:

http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00749.html

Discussions on the topic.

http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01495.html

Doug?


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net,
   ||dougkwan at google dot com


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

[Bug c++/34075] [DR 587] temporary used in ?: expression tho second and third expr. lvalues

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2009-12-08 22:28 ---
C::dflt has type const int by pd->d[i] has type int, so they do not have the
same type and the warning is correct.  This is DR 587 which was just changed in
the latest draft
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#587


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-08 22:28:20
   date||
Summary|temporary used in ?:|[DR 587] temporary used in
   |expression tho second and   |?: expression tho second and
   |third expr. lvalues |third expr. lvalues


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

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

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2009-12-08 22:13 ---
I think I understand why apple gcc42 does not show the problem: it does not
call ___divdc3:

[macbook] f90/bug% diff -up pr42333_42.s pr42333_45.s
--- pr42333_42.s2009-12-08 23:00:29.0 +0100
+++ pr42333_45.s2009-12-08 23:00:07.0 +0100
...
@@ -15,68 +15,61 @@ LCFI2:
movq%rax, -16(%rbp)
movabsq $9214364837600034815, %rax
movq%rax, -8(%rbp)
-   movq-16(%rbp), %rax
-   movq-8(%rbp), %rdx
-   movq%rax, -24(%rbp)
-   movsd   -24(%rbp), %xmm1
+   movq-16(%rbp), %rdx
+   movq-8(%rbp), %rax
movq%rdx, -24(%rbp)
movsd   -24(%rbp), %xmm0
-   movapd  %xmm0, %xmm2
-   addsd   %xmm1, %xmm2
-   movapd  %xmm0, %xmm3
-   subsd   %xmm1, %xmm3
-   movsd   LC1(%rip), %xmm0
-   movapd  %xmm2, %xmm1
-   divsd   %xmm0, %xmm1
-   movsd   LC1(%rip), %xmm0
-   movapd  %xmm3, %xmm2
-   divsd   %xmm0, %xmm2
-   movapd  %xmm2, %xmm0
-   movsd   %xmm1, -24(%rbp)
-   movq-24(%rbp), %rax
+   movq%rax, -24(%rbp)
+   movsd   -24(%rbp), %xmm1
+   movsd   LC2(%rip), %xmm3
+   movsd   LC2(%rip), %xmm2
+   call___divdc3
movsd   %xmm0, -24(%rbp)
movq-24(%rbp), %rdx
...

This also explain why the test compiled with -c and 4.5, but linked with 4.2
fails. So my guess about the lazy complex division seems right in libm. Could
someone write a C code forcing the use of ___divdc3?


-- 


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

[Bug c++/34886] Strangeness of name lookup in template function

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-12-08 22:02 ---
> void* is a pointer to fundamental type so has no associated namespaces

Well there is a still open defect report that says this might not be true :).

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/29131] [DR 225] Bad name lookup for templates

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-12-08 22:02 ---
*** Bug 34886 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rvovsd at mail dot ru


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

[Bug c++/34886] Strangeness of name lookup in template function

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-12-08 22:01 ---
Actually 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/34886] Strangeness of name lookup in template function

[redi at gcc dot gnu dot org]

--- Comment #4 from redi at gcc dot gnu dot org  2009-12-08 21:58 ---
In resolving dependent names, names from the following sources are considered:
— Declarations that are visible at the point of definition of the
template.
— Declarations from namespaces associated with the types of the function
arguments both from the instantiation context (14.7.4.1) and from the
definition context.

— If T is a fundamental type, its associated sets of namespaces and classes are
both empty.
— If T is a pointer to U or an array of U, its associated namespaces and
classes are those associated with U.

void* is a pointer to fundamental type so has no associated namespaces, so only
the first source is considered, and only f(T*) is visible at the point of
definition. This is invalid.


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/42335] New: [OOP] ICE on CLASS IS (bad_identifier)

[anlauf at gmx dot de]

Hi,

the following (invalid) code gives an ICE:

module gfcbug95
  implicit none
  type, abstract :: vector_class
  end type vector_class

  type, extends(vector_class) :: trivial_vector_type
real :: elements(100)
  end type trivial_vector_type
contains
  subroutine bar (this,v)
class(trivial_vector_type), intent(inout) :: this
class(vector_class),intent(in):: v

select type (v)
!   class is (trivial_vector_type) ! OK
class is (bad_id)  ! ICE
   this%elements(:) = v%elements(:)
end select
  end subroutine bar
end module gfcbug95

% gfc45 gfcbug95.f90
gfcbug95.f90:16.20:

class is (bad_id)  ! ICE
1
Error: 'bad_id' at (1) is not an accessible derived type
f951: internal compiler error: Segmentation fault

Cheers,
-ha


-- 
   Summary: [OOP] ICE on CLASS IS (bad_identifier)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anlauf at gmx dot de


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

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

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2009-12-08 21:41 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in 
> > the
> > example (figure 12.3, p243) for allocatable components... So, where's the 
> > actual problem?
> 
> The example on p243 correctly shows the use of a structure constructor in an
> assignment statement.  This bug report is different in that it concerns a
> structure constructor in the initializer portion of a TYPE statement (where 
> the derived type contains an ALLOCATABLE.)

And while writing the above, I didn't take this as significant difference.
However, it dawns on me that the crucial point is, that variables with
initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE
components. Correct?


-- 


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

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

[w6ws at earthlink dot net]

--- Comment #3 from w6ws at earthlink dot net  2009-12-08 21:34 ---
(In reply to comment #2)
> I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
> example (figure 12.3, p243) for allocatable components... So, where's the 
> actual problem?

The example on p243 correctly shows the use of a structure constructor in an
assignment statement.  This bug report is different in that it concerns a
structure constructor in the initializer portion of a TYPE statement (where the
derived type contains an ALLOCATABLE.)


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug c++/30357] Enum typecast warning

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2009-12-08 21:30 ---
(In reply to comment #2)
> I am not sure this is such a good idea. A casting typically means "I want to
> really do this". GCC normally suppress warnings when casting is added. A
> warning when you assign when enum type to another and the first enum is not a
> subset of the second could still be useful, but the casting should prevent the
> warning.

That won't even compile without a cast, in C++ there is no implicit conversion
to enumeration types.

> I am not sure what happens for such assignment, is it undefined behaviour?

If the source value is within the range of the target enum it's well-defined. 
It might be reasonable to warn as part of -Wconversion except that usually
applies to implicit conversions, and for enums the implicit conversion isn't
allowed.


-- 


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

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

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2009-12-08 21:29 ---
> For Darwin 9 there is no "system provided ___divdc3" (AFAICT) .. it is 
> supplied
> from libgcc_s.1.dylib.

I see:

[ibook-dhum] f90/bug% nm /usr/lib/libm.dylib | grep divdc3
00131270 t ___divdc3

> 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.

It does not: see first item (3) of comment #5!-(I have forgotten to update the
numbers when I have inserted it).


-- 


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

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

[viriketo at gmail dot com]

--- Comment #3 from viriketo at gmail dot com  2009-12-08 21:28 ---
I found the (proper?) way of getting -Bxxx flags to the target libraries, even
if they use libtool: make FLAGS_FOR_TARGET
Any -Bxxx in CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET gets ignored, but those in
FLAGS_FOR_TARGET pass.

Unless the gcc developers want CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET to
handle -Bxxx passing it to the target linking commands, I imagine this can be
closed as resolved.


-- 


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

[Bug fortran/35918] Accepts invalid: INTERFACE and REAL

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-12-08 21:17 ---
All three cases are flagged by current 4.5.0 20091208.

The first one gives
$> gfortran-svn  pr35918.f90
pr35918.f90:2.8:

real foo
1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'foo' at (1)

which is a little wierd, but "REAL foo" could either refer to a function or a
variable. Thus I'd call this fixed.

Tobias, please close if you agree.


-- 

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

[Bug c++/28330] finds wrong template overload; peculiar diagnostic

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2009-12-08 21:06 ---
Assuming that's an accurate reduction of the original code, comment 4 is
correct.  I didn't look at the preprocessed source, it includes Boost code that
will be very specific to the GCC 4.0.2 version it was compiled with and so
useless with any other version of GCC


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/37398] Statement functions mask missing PURE procedures.

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-12-08 21:04 ---
*** Bug 38733 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jv244 at cam dot ac dot uk


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

[Bug fortran/38733] non pure function in forall when using function aliases

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-12-08 21:04 ---


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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/37412] No error on repeated declaration

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2009-12-08 21:01 ---
(In reply to comment #4)
> Maybe I could change this warning into an error even for non-standard 
> conforming mode in case the length or a kind parameter differs.  What
> do you think?

I assume, this happened at some point. Current 4.5.0 20091208 gives:

$> gfortran-svn pr37412.f90
pr37412.f90:3.17:

  character(1) st
 1
Error: Symbol 'st' at (1) already has basic type of CHARACTER

I believe this is correct. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug fortran/34527] Declaring a variable twice with different characteristics

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-12-08 20:58 ---
Marking as dupe, discussion happened in PR37412.

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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/37412] No error on repeated declaration

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2009-12-08 20:58 ---
*** Bug 34527 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[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

[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 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 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 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 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 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 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 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++/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 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 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

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

[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 #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++/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++/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++/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 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 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 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 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 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 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 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++/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

[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]

--- 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] 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 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++/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 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

[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++/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 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

[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 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++/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