[Bug c++/29573] [4.0/4.1/4.2/4.3 regression] ICE after parse error in template argument

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2006-11-06 06:41 ---
Subject: Bug number PR c++/29573

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01746.html


-- 


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

[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.

[bdavis at gcc dot gnu dot org]

--- Comment #5 from bdavis at gcc dot gnu dot org  2006-11-06 04:10 ---
patch here:

http://gcc.gnu.org/ml/fortran/2006-11/msg00148.html


-- 


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

[Bug target/29721] Wrong code when compiling libjava/verify.cc at -O2

[daney at gcc dot gnu dot org]

--- Comment #3 from daney at gcc dot gnu dot org  2006-11-06 01:17 ---
Manually moving the

   lw  $4,%got($L2406)($28)

to be just before the

   addiu   $4,$4,%lo($L2406)

and reassembling fixes the problem.

So I think that my analysis about the problem being splitting them up with
another %got() relocation between is correct.

Now the question is how to fix it.


-- 


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

[Bug testsuite/29737] New: make check fixinclude test FAILURES

[mckelvey at maskull dot com]

Latest CVS, builds fine. Attempt to "make check" yields:

gmake[1]: Entering directory `/usr/home/mckelvey/software/gcc-obj'
gmake[2]: Entering directory `/usr/home/mckelvey/software/gcc-obj/fixincludes'
autogen -T ../../gcc/fixincludes/check.tpl ../../gcc/fixincludes/inclhack.def
/bin/sh ./check.sh ../../gcc/fixincludes/tests/base
Fixed:  testing.h
Fixed:  testing.h
Fixed:  ansi/math.h
...
Fixed:  obstack.h
Fixed:  pixrect/memvar.h
sed: -e expression #1, char 48: Unexpected ','
Fixed:  regex.h
...
Fixed:  Xm/BaseClassI.h
Fixed:  Xm/Traversal.h
Missing header fix:  pthread.h

There were fixinclude test FAILURES
gmake[2]: *** [check] Error 1
gmake[2]: Leaving directory `/usr/home/mckelvey/software/gcc-obj/fixincludes'
gmake[1]: *** [check-fixincludes] Error 2
gmake[1]: Leaving directory `/usr/home/mckelvey/software/gcc-obj'
gmake: *** [do-check] Error 2

Configured:

alpha1:gcc-obj>alias CONFIGURECVS
alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls >clog 2>&1 &'


Built:

alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\''
LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap >log 2>&1 &'

alpha1:gcc-obj>uname -a
Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown


-- 
   Summary: make check fixinclude test FAILURES
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
 GCC build triplet: alphaev56-unknown-linux-gnu
  GCC host triplet: alphaev56-unknown-linux-gnu
GCC target triplet: alphaev56-unknown-linux-gnu


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

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-06 
00:43 ---
Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes

> So this ends up being what i thought.  The variables aren't being
> collapsed, but i can't figure out why (IE it can't prove they are the
> same).  This causes it to give them separate solution bitmaps, and the
> solutions are very large,and involve thousands of variables, so
> thousands * thousands = a lot of memory.

It appears that every one of them has its address taken.  The code
skips such variables:

 /* We can't eliminate things whose address is taken, or which is
the target of a dereference.  */
 if (vi->address_taken || vi->indirect_target)
   continue;

> However, all of these variables should collapse, as they do in the
> earlier functions.

For the record, I believe we die processing this constructor function:

;; Function _GLOBAL__I_0__ZN3gnu3xml8aelfred215XmlParser$InputC1Ev()
(_GLOBAL__I
_0__ZN3gnu3xml8aelfred215XmlParser$InputC1Ev)

The alias1 files has the following:

...
ESCAPED_VARS = &gnu.xml.xpath.AndExpr.class$$.engine

Collapsing static cycles and doing variable substitution:

Solving graph:

Dave


-- 


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

[Bug target/29720] Latest CVS: undefined reference to __tls_get_addr

[mckelvey at maskull dot com]

--- Comment #2 from mckelvey at maskull dot com  2006-11-06 00:35 ---
OK, that fixed the problem. But shouldn't configuration have caught it?


-- 


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

[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered

[chuck at vertica dot com]

--- Comment #49 from chuck at vertica dot com  2006-11-05 23:39 ---
Sorry.

But maybe it is a FAQ because even with "-Wall" or "-Wstrict-aliasing=2" g++
4.0.2 generates invalid code for this without so much as a peep.  I here 4.1 is
better about giving a warning.

I guess it was too much to think "reinterpret_cast means I know what I'm asking
for, so just do what I say".


-- 


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

[Bug c/29736] [4.0/4.1/4.2/4.3 regression] ICE on duplicate vector attribute

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c/29736] New: [4.0/4.1/4.2/4.3 regression] ICE on duplicate vector attribute

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.2:

=
int __attribute__((vector_size(8),vector_size(8))) v;

void foo()
{
v = v + v;
}
=

bug.c: In function 'foo':
bug.c:5: internal compiler error: in same_scalar_type_ignoring_signedness, at
c-common.c:6379
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE on duplicate vector
attribute
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/29735] [4.0/4.1/4.2/4.3 regression] ICE on "main" returning vector

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

--- Comment #33 from vincent at vinc17 dot org  2006-11-05 23:27 ---
(In reply to comment #32)
> (In reply to comment #31)
> > (In reply to comment #30)
> > So, I don't think a mpfr_signgam alone would really be useful. So, I think 
> > that
> > choice 2 would be better.
> 
> Okay, sounds fine.  Would this make it into 2.2.1 or 2.3?

For compatibility reasons (i.e. the 2.2.x versions must have the same
interface), this can only be in 2.3.0.

> And do you have any very rough timeframe for each release so I can plan
> accordingly for gcc?

A pre-release of 2.2.1 should be there soon; there are still bugs being fixed
(they will be ported to the 2.2 branch once this is complete).

I don't know about 2.3.0; probably in a few months, because there currently
aren't many differences from the 2.2 branch.


-- 


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

[Bug c++/29735] New: [4.0/4.1/4.2/4.3 regression] ICE on "main" returning vector

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.0:

=
int __attribute__((vector_size(8))) main()
{
  return 0;
}
=

bug.cc:1: internal compiler error: in start_function, at cp/decl.c:10705
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE on "main" returning
vector
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/29734] [4.0/4.1/4.2/4.3 regression] ICE with vector in switch condition

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29734] New: [4.0/4.1/4.2/4.3 regression] ICE with vector in switch condition

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 3.4.5 / 4.0.2:

=
void foo(int __attribute__((vector_size(8))) i)
{
  switch (i) {}
}
=

bug.cc: In function 'void foo(int __vector__)':
bug.cc:3: internal compiler error: in perform_integral_promotions, at
cp/typeck.c:1588
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE with vector in switch
condition
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/29733] [4.1/4.2/4.3 regression] ICE on initialization of function type

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.2


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

[Bug c++/29732] [4.0/4.1/4.2/4.3 regression] ICE on invalid friend declaration

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29731] [4.0/4.1/4.2/4.3 regression] ICE with statement expression as template parameter

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29730] [4.0/4.1/4.2/4.3 regression] ICE on invalid declaration of template member

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29729] [4.0/4.1/4.2/4.3 regression] ICE with template class in template function

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29728] [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer in template function

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29727] [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer for template member

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.4


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

[Bug c++/29733] New: [4.1/4.2/4.3 regression] ICE on initialization of function type

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.0:

=
template void foo()
{
  T t = 0;
}

void bar()
{
  foo();
}
=

bug.cc: In function 'void foo() [with T = int ()()]':
bug.cc:8:   instantiated from here
bug.cc:3: internal compiler error: in digest_init, at cp/typeck2.c:723
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3 regression] ICE on initialization of
function type
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/29732] New: [4.0/4.1/4.2/4.3 regression] ICE on invalid friend declaration

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.0:

=
struct A
{
  template template friend void foo(T) {}
  void bar() { foo(0); }
};
=

bug.cc: In member function 'void A::bar()':
bug.cc:4: internal compiler error: in retrieve_specialization, at cp/pt.c:847
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE on invalid friend
declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered

[pinskia at gcc dot gnu dot org]

--- Comment #48 from pinskia at gcc dot gnu dot org  2006-11-05 22:26 
---
(In reply to comment #46)
> Folks, can anyone please tell me if this is the same problem as I am seeing
> here using gcc 4.0.2 for x86_64:
> inline long long Vgetbytes(double f) {
>return *reinterpret_cast(&f);
> }

No that is not the same problem, in fact the above is just plainly violating
C++ aliasing rules.


-- 


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

[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered

[drow at gcc dot gnu dot org]

--- Comment #47 from drow at gcc dot gnu dot org  2006-11-05 22:25 ---
Subject: Re:  [4.0/4.1 Regression] alias bug with cast and call clobbered

On Sun, Nov 05, 2006 at 10:17:16PM -, chuck at vertica dot com wrote:
> Folks, can anyone please tell me if this is the same problem as I am seeing
> here using gcc 4.0.2 for x86_64:

No.  Your code is simply invalid; this is a FAQ.

> inline long long Vgetbytes(double f) {
>return *reinterpret_cast(&f);
> }

"f" is an object of type double and may not be accessed through a
pointer to "const long long".


-- 


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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[pault at gcc dot gnu dot org]

--- Comment #21 from pault at gcc dot gnu dot org  2006-11-05 22:18 ---
Fixed on trunk and 4.2 - will soon be fixed on 4.1.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered

[chuck at vertica dot com]

--- Comment #46 from chuck at vertica dot com  2006-11-05 22:17 ---
Folks, can anyone please tell me if this is the same problem as I am seeing
here using gcc 4.0.2 for x86_64:

#include 

inline long long Vgetbytes(double f) {
   return *reinterpret_cast(&f);
}

int main (int argc, char **argv)
{
double dd = 2.0;

printf ("%llx\n", Vgetbytes(dd));
printf ("%llx\n", Vgetbytes(dd));
}

When compiled with -02 I get:
build0:/home/cbear $ g++4 --version
g++4 (GCC) 4.0.2 20051130 (Red Hat 4.0.2-14.EL4)
build0:/home/cbear $ g++4 -O2 ftp.cpp
build0:/home/cbear $ ./a.out
0
4000

When I look at the disassemby I see the problem:
main:
.LFB14:
pushq   %rbx# Save EBX as required
.LCFI0:
movl$.LC1, %edi #, Load format string for printf. edi = arg 0
movabsq $4611686018427387904, %rbx  # rbx gets 2.0.
xorl%eax, %eax  # irrelevant
subq$16, %rsp   # Stack frame for calling printf
.LCFI1:
movq8(%rsp), %rsi   # ERROR second argument to printf call wrong
movq%rbx, 8(%rsp)   # ERROR if this line came before prior we would
be OK
callprintf  # printf gets rdi and rsi as args.  rsi bad.
movq8(%rsp), %rsi   # Better luck this time, rsi set properly
movl$.LC1, %edi # rdi initialized againg
xorl%eax, %eax  # irrelevant
movq%rbx, 8(%rsp)   # extraneous, rbx need not be preserved
callprintf  # This one will work
addq$16, %rsp   # Clean up the printf stack
xorl%eax, %eax  # 
popq%rbx# restore rbx for caller
ret # done

If I compile with -fno-strict-aliasing I do get valid code and right answers.

However I like the assembly code produced by gcc 3.4.4 much better because it
doesn't bother to allocate stack space, and just uses rbx:
build0:/home/cbear $ g++ --version
g++ (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
build0:/home/cbear $ g++ -O2 -S -fverbose-asm ftp.cpp

main:
.LFB14:
pushq   %rbx#
.LCFI0:
movabsq $4611686018427387904, %rbx  #, 
movl$.LC1, %edi #,
movq%rbx, %rsi  # , 
xorl%eax, %eax  #
callprintf  #
movq%rbx, %rsi  # , 
movl$.LC1, %edi #,
xorl%eax, %eax  #
callprintf  #
popq%rbx#
xorl%eax, %eax  # 
ret


-- 


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

[Bug fortran/29634] ICE in variable_decl, for function returning a derived type

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-11-05 22:16 ---
I'd better take it, since I submitted a patch for it!

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-10-29 10:45:13 |2006-11-05 22:16:55
   date||


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

[Bug fortran/29641] [4.1/4.2/4.3 regression] ICE in gfc_get_derived_type

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-11-05 22:15 ---
Fixed on trunk and 4.2 - soon to be fixed on 4.1.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29565] [4.1/4.2/4.3 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2006-11-05 22:14 ---
Fixed on trunk and 4.2 - soo to be fixed on 4.1.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29490] internal compiler error: in fold_binary, at fold-const.c:8239

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2006-11-05 22:11 ---
Fixed on trunk and 4.2 - soon to be fixed on 4.1

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29387] ICE on character array function of variable length

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2006-11-05 22:07 ---
Fixed on trunk and 4.2 - will do 4.1 in the next 48hours.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29699] ICE in trans-decl.c

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2006-11-05 22:03 ---
We can move into different territory by referring to vocab_swap:

PROGRAM vocabulary_word_count
  IMPLICIT NONE
  TYPE VARYING_STRING
CHARACTER,DIMENSION(:),ALLOCATABLE :: chars
  ENDTYPE VARYING_STRING

  INTEGER :: list_size=200
CONTAINS
  SUBROUTINE extend_lists
type(VARYING_STRING),DIMENSION(list_size) :: vocab_swap
allocate (vocab_swap(1)%chars(10))
  ENDSUBROUTINE extend_lists
ENDPROGRAM vocabulary_word_count

bombs out, as follows:

pr29699.f90: In function 'extend_lists':
pr29699.f90:11: internal compiler error: tree check: expected record_type or
uni
on_type or qual_union_type, have pointer_type in find_compatible_field, at
tree.
c:7108
Please submit a full bug report,

So I would say that there are two bugs!

It is interesting to compare the code produced here with taht produced when
list_size is made a parameter.  This appears to be the clue but it is a bit
opaque right now.

Paul


-- 


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

[Bug c++/189] [DR176] parse error in qualified member name lookup

[jens dot maurer at gmx dot net]

--- Comment #10 from jens dot maurer at gmx dot net  2006-11-05 21:54 
---
Here is a shorter test case.

namespace N {
  template struct B { int m; };
  struct C : B { };
}

void g() {
  N::C().B::m;
}


-- 

jens dot maurer at gmx dot net changed:

   What|Removed |Added

 CC||jens dot maurer at gmx dot
   ||net


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

[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2006-11-05 21:48 ---
Created an attachment (id=12550)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12550&action=view)
Patch for reading only

This is a partial patch, for reading only.

I have taken the approach that we should allow any record size < 0
to mean continued records (regardless of whether we have four- or
eight-byte record markers).  This doesn't break anything, simplifies
codepaths and clears the way for records longer than 2**63 bytes :-)


-- 


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

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[dberlin at dberlin dot org]

--- Comment #8 from dberlin at gcc dot gnu dot org  2006-11-05 21:48 ---
Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes

On 5 Nov 2006 21:22:24 -, dave at hiauly1 dot hia dot nrc dot ca
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-05 
> 21:22 ---
> Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
> 708630224 bytes
>
> > Can you bzip2 compress -fdump-tree-alias-vops-details-blocks-stats (it's 
> > going
> > to be very large) and put it somewhere for me?
>
> The files are here: .

Thanks!
So this ends up being what i thought.  The variables aren't being
collapsed, but i can't figure out why (IE it can't prove they are the
same).  This causes it to give them separate solution bitmaps, and the
solutions are very large,and involve thousands of variables, so
thousands * thousands = a lot of memory.


However, all of these variables should collapse, as they do in the
earlier functions.
They also collapse on my machine on this testcase (which admittedly
has different code there).
It is, in fact, *incredibly* strange that not a single variable is
collapsed or unified in this function.

I'm not sure what to do here.
Can you poke around in perform_var_substitution and see if you can
figure out what conditions are causing all the variables to fail out
of the collapsing.  Particularly, roughly every variable that has a
constaint like foo = ESCAPED_VARS in the dump should be getting
collapsed to ESCAPED_VARS.


Can you poke


-- 


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

Re: [Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[Daniel Berlin]

On 5 Nov 2006 21:22:24 -, dave at hiauly1 dot hia dot nrc dot ca
<[EMAIL PROTECTED]> wrote:



--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-05 
21:22 ---
Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes

> Can you bzip2 compress -fdump-tree-alias-vops-details-blocks-stats (it's going
> to be very large) and put it somewhere for me?

The files are here: .


Thanks!
So this ends up being what i thought.  The variables aren't being
collapsed, but i can't figure out why (IE it can't prove they are the
same).  This causes it to give them separate solution bitmaps, and the
solutions are very large,and involve thousands of variables, so
thousands * thousands = a lot of memory.


However, all of these variables should collapse, as they do in the
earlier functions.
They also collapse on my machine on this testcase (which admittedly
has different code there).
It is, in fact, *incredibly* strange that not a single variable is
collapsed or unified in this function.

I'm not sure what to do here.
Can you poke around in perform_var_substitution and see if you can
figure out what conditions are causing all the variables to fail out
of the collapsing.  Particularly, roughly every variable that has a
constaint like foo = ESCAPED_VARS in the dump should be getting
collapsed to ESCAPED_VARS.


Can you poke

[Bug target/29721] Wrong code when compiling libjava/verify.cc at -O2

[daney at gcc dot gnu dot org]

--- Comment #2 from daney at gcc dot gnu dot org  2006-11-05 21:44 ---
It looks like the problem here is that a %lo relocation is getting seperated
from its corresponding %got.  Here is a little of the assembly, note how there
is an intervening %got/%lo between the %got($L2406) and the %lo($L2406):

.loc 1 1634 0
addiu   $3,$3,-4
$LVL1875:
sltu$2,$3,8
.setnoreorder
.setnomacro
bne $2,$0,$L3018
lw  $4,%got($L2406)($28)
.setmacro
.setreorder

.loc 1 1671 0
lw  $5,%got($LC29)($28)
move$4,$22
addiu   $5,$5,%lo($LC29)
lw  $25,%call16(_ZN20_Jv_BytecodeVerifier11verify_failEPKci)($28)
$LEHB200:
.setnoreorder
.setnomacro
jalr$25
li  $6,-1   # 0x
.setmacro
.setreorder

$LVL1876:
$L2392:
$LBE9309:
$LBE9307:
$LBE9305:
$LBB9318:
$LBB9304:
.loc 1 693 0
li  $3,10   # 0xa
$LVL1877:
.setnoreorder
.setnomacro
b   $L2396
move$16,$0
.setmacro
.setreorder

$LVL1878:
$L3018:
$LBE9304:
$LBE9318:
$LBB9319:
$LBB9306:
$LBB9308:
.loc 1 1634 0
sll $2,$3,2
addiu   $4,$4,%lo($L2406)
addu$2,$2,$4
lw  $3,0($2)
addu$3,$3,$28
j   $3
.section   
.rodata._ZN20_Jv_BytecodeVerifier21verify_instructions_\
0Ev,"aG",@progbits,_ZN20_Jv_BytecodeVerifier21verify_instructions_0Ev,comdat
.align  2
.align  2
$L2406:
.gpword $L2398
.gpword $L2399
.gpword $L2400
.gpword $L2401
.gpword $L2402
.gpword $L2403
.gpword $L2404
.gpword $L2405


-- 


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

[Bug fortran/29539] ICE in variable_decl

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2006-11-05 21:40 ---
Subject: Bug number PR29539

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00271.html


-- 


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[ebotcazou at gcc dot gnu dot org]

--- Comment #27 from ebotcazou at gcc dot gnu dot org  2006-11-05 21:32 
---
> [EMAIL PROTECTED]:~/gnu/gcc-4.3/objdir/gcc/testsuite/g++$ ld --version
> GNU ld version 2.17.50 20061031

OK, thanks.  I'll try harder to reproduce on x86/Linux.


-- 


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

[Bug fortran/29689] gfortran should use g77-compatible format for error message

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2006-11-05 21:31 ---
I don't know why I assigned this to myself.  Brooks has
already fixed this.

Unassigning myself.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2006-11-05 21:27 
---
Fixed on 4.2 and 4.3


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


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

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-05 
21:22 ---
Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes

> Can you bzip2 compress -fdump-tree-alias-vops-details-blocks-stats (it's going
> to be very large) and put it somewhere for me?

The files are here: .

Dave


-- 


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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2006-11-05 20:55 ---
Subject: Bug number PR29719

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00269.html


-- 


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

[Bug c++/29475] [4.0/4.1/4.2/4.3 Regression] incomplete template diagnostics.

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2006-11-05 20:40 ---
Subject: Bug number PR c++/29475

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00266.html


-- 


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

[Bug middle-end/26306] [4.0/4.1/4.2/4.3 regression] ICE on volatile array with non-constant bounds

[patchapp at dberlin dot org]

--- Comment #9 from patchapp at dberlin dot org  2006-11-05 20:40 ---
Subject: Bug number PR middle-end/26306

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00251.html


-- 


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2006-11-05 20:39 ---
Subject: Bug number PR25545

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00236.html


--- Comment #7 from patchapp at dberlin dot org  2006-11-05 20:39 ---
Subject: Bug number PR25545

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00236.html


-- 


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2006-11-05 20:39 ---
Subject: Bug number PR25545

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00236.html


-- 


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

[Bug c++/29731] New: [4.0/4.1/4.2/4.3 regression] ICE with statement expression as template parameter

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.0:

=
template struct A {};

A<({})> a;
=

bug.cc:3: error: statement-expressions are allowed only inside functions
bug.cc:3: internal compiler error: in uses_template_parms, at cp/pt.c:5169
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE with statement
expression as template parameter
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/25620] Missed optimization with power

[patchapp at dberlin dot org]

--- Comment #12 from patchapp at dberlin dot org  2006-11-05 20:39 ---
Subject: Bug number PR25620

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00216.html


-- 


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

[Bug target/27405] [4.2/4.3 Regression] gcc.c-torture/execute/960209-1.c ICEs on sh64-* with -O3

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2006-11-05 20:36 ---
Subject: Bug number PR target/27405

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00053.html


-- 


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

[Bug fortran/29565] [4.1/4.2/4.3 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c

[patchapp at dberlin dot org]

--- Comment #9 from patchapp at dberlin dot org  2006-11-05 20:36 ---
Subject: Bug number PR29565

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00038.html


-- 


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

[Bug c++/29730] New: [4.0/4.1/4.2/4.3 regression] ICE on invalid declaration of template member

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.0:

=
struct A
{
  template void foo()(0);
};
=

bug.cc:3: internal compiler error: in grokfield, at cp/decl2.c:846
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE on invalid declaration
of template member
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/29610] [4.1 Regression] ICE when compiling c++ code with -O2 -funswitch-loops

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2006-11-05 20:35 ---
Subject: Bug number PR29610

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00015.html


-- 


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

[Bug c++/29729] New: [4.0/4.1/4.2/4.3 regression] ICE with template class in template function

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 3.0:

=
template void foo(T)
{
  struct A
  {
template struct B
{
  typedef B<0> C;
};
  };
}
=

bug.cc: In function 'void foo(T)':
bug.cc:1: internal compiler error: in tsubst, at cp/pt.c:7337
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE with template class in
template function
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/29728] New: [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer in template function

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 3.4.0:

=
template void foo()
{
  int a[] = { X: 0 };
}
=

bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer
in template function
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/29727] New: [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer for template member

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 3.3:

=
template struct A
{
  static int a[1];
};

template int A::a[1] = { X: 0 };

void foo()
{
  A<0>::a;
}
=

bug.cc: In instantiation of 'int A<0>::a [1]':
bug.cc:10:   instantiated from here
bug.cc:6: error: 'X' was not declared in this scope
bug.cc:6: internal compiler error: in reshape_init_array_1, at cp/decl.c:4350
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2/4.3 regression] ICE on invalid initializer
for template member
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-05 
20:15 ---
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc
execution test

> With some exotic version of binutils too? :-)

When I first hit the problem, I was using a build from last June.
I updated when it was suggested that this might be a binutils
problem.  I'm now using:

[EMAIL PROTECTED]:~/gnu/gcc-4.3/objdir/gcc/testsuite/g++$ ld --version
GNU ld version 2.17.50 20061031

It's stock.

Dave


-- 


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[ebotcazou at gcc dot gnu dot org]

--- Comment #25 from ebotcazou at gcc dot gnu dot org  2006-11-05 20:03 
---
> I'm seeing similar problems on hppa-linux.  See PR 29661 for mor details.
> There are some others as well that are probably dups.

With some exotic version of binutils too? :-)


-- 


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

[Bug target/29687] internal compiler error in push_reload, at reload.c:1315 building liboil-0.3.9

[sick_soul at yahoo dot it]

--- Comment #3 from sick_soul at yahoo dot it  2006-11-05 19:40 ---
I was not sure whether to report this or not,
but looking at the bug report form I found the 3.3.x series there,
so I went ahead.

Both gcc-4.1.1 and gcc-3.4.6 do not show this bug.

I will close this, sorry for wasting your time.
Maybe it could help to remove 3.3.x versions of gcc
from the bug reporting form, to avoid time drains like this.

Bye,

Claudio


-- 

sick_soul at yahoo dot it changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[danglin at gcc dot gnu dot org]

--- Comment #24 from danglin at gcc dot gnu dot org  2006-11-05 19:34 
---
I'm seeing similar problems on hppa-linux.  See PR 29661 for mor details.
There are some others as well that are probably dups.


-- 

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

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[dberlin at gcc dot gnu dot org]

--- Comment #6 from dberlin at gcc dot gnu dot org  2006-11-05 19:16 ---
(In reply to comment #5)
> Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
> 708630224 bytes
> 
> > Except that all of these were fixed in the followup patch and a later
> > typo fix, *including* the memory usage (see honza's tester).
> 
> I may have been wrong above as to which java compilation caused the build
> failure because make -j 4 was used.  In any case, the compilation fails
> with the gnu-xml.list.  The backtrace is shown below.  Seems to indicate
> a problem with alias analysis

My guess is that there must be a truly huge number of variables here and the
sets must not be collapsing.

Can you bzip2 compress -fdump-tree-alias-vops-details-blocks-stats (it's going
to be very large) and put it somewhere for me?




-- 


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

[Bug c++/29661] FAIL: g++.dg/compat/eh/unexpected1 cp_compat_x_tst.o-cp_compat_y_tst.o execute

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2006-11-05 
18:49 ---
Subject: Re:  FAIL: g++.dg/compat/eh/unexpected1
cp_compat_x_tst.o-cp_compat_y_tst.o execute

> I think these all are caused by bugs in binutils after the following patch:
> http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00787.html

At the moment, I don't quite see the connection.  Looking at cxa_vec,
the program aborts in base_of_encoded_value:

Breakpoint 1, base_of_encoded_value (encoding=,
context=0xc04f6ea8)
at /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/../gcc/unwind-pe.h:122
122   __gxx_abort ();
(gdb) bt
#0  base_of_encoded_value (encoding=, context=0xc04f6ea8)
at /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/../gcc/unwind-pe.h:122
#1  0x40243e18 in parse_lsda_header (context=0xc04f6ea8,
p=0x40173001 "ELF\001\002\001\003", info=0xc04f749c)
at /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/../gcc/unwind-pe.h:286
#2  0x4024431c in __gxx_personality_v0 (version=,
actions=1, exception_class=, ue_header=0x14090,
context=0xc04f6ea8)
at ../../../../gcc/libstdc++-v3/libsupc++/eh_personality.cc:435
#3  0x4024431c in __gxx_personality_v0 (version=,
actions=1, exception_class=, ue_header=0x14090,
context=0xc04f6ea8)
at ../../../../gcc/libstdc++-v3/libsupc++/eh_personality.cc:435

The encoding passed to base_of_encoded_value is 0x7F.  This value arises
in parsing the lsda header.

  // Find @LPStart, the base to which landing pad offsets are relative.
 lpstart_encoding = *p++;

We have this context:

(gdb) p *context
$17 = {reg = {0x0, 0x0, 0xc04f6c2c, 0xc04f6c40, 0xc04f6c84, 0xc04f6c80,
0xc04f73d4, 0xc04f73d0, 0xc04f73cc, 0xc04f73c8, 0xc04f73c4, 0xc04f73c0,
0xc04f73bc, 0xc04f73b8, 0xc04f73b4, 0xc04f73b0, 0xc04f73ac, 0xc04f73a8,
0xc04f73a4, 0x0, 0xc04f7394, 0xc04f7398, 0xc04f739c, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0xc04f73a0, 0x0 , 0xc04f7430,
0xc04f7434, 0xc04f7428, 0xc04f742c, 0xc04f7420, 0xc04f7424, 0xc04f7418,
0xc04f741c, 0xc04f7410, 0xc04f7414, 0xc04f7408, 0xc04f740c, 0xc04f7400,
0xc04f7404, 0xc04f73f8, 0xc04f73fc, 0xc04f73f0, 0xc04f73f4, 0xc04f73e8,
0xc04f73ec, 0x0 }, cfa = 0xc04f6c40, ra = 0x40246f00,
lsda = 0x40173000, bases = {tbase = 0x0, dbase = 0x0, func = 0x40246e7c},
args_size = 0, signal_frame = 0 '\0', by_value = '\0' }

(gdb) x/20x p
0x40173000: 0x7f454c46  0x01020103  0x  0x
0x40173010: 0x0003000f  0x0001  0x00042a40  0x0034
0x40173020: 0x00496290  0x0210  0x00340020  0x00040028
0x40173030: 0x00260023  0x0001  0x  0x
0x40173040: 0x  0x000f7de4  0x000f7de4  0x0005

Dave


-- 


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2006-11-05 18:47 
---
Subject: Bug 25545

Author: jvdelisle
Date: Sun Nov  5 18:46:59 2006
New Revision: 118510

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118510
Log:
2006-11-05  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25545
* gfortran.dg/dollar_edit_descriptor-2.f: New test.

Added:
   
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/dollar_edit_descriptor-2.f
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2006-11-05 18:44 
---
Subject: Bug 25545

Author: jvdelisle
Date: Sun Nov  5 18:43:51 2006
New Revision: 118509

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118509
Log:
2006-11-05  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25545
* io/transfer.c (write_block): Cleanup code paths between
stream and non-stream I/O.
(write_buf):  Cleanup.
(read_block): Cleanup.
(finalize_transfer): Call next_record for '$' edit descriptor handling
of internal unit. Cleanup code for readability.

Modified:
branches/gcc-4_2-branch/libgfortran/ChangeLog
branches/gcc-4_2-branch/libgfortran/io/transfer.c


-- 


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

[Bug middle-end/29726] [4.2/4.3 regression] invalid folding of ((X >> C1) & C2) != 0 or "M-x is undefined" in emacs

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
   Target Milestone|--- |4.2.0


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

[Bug middle-end/29726] New: [4.2/4.3 regression] invalid folding of ((X >> C1) & C2) != 0 or "M-x is undefined" in emacs

[belyshev at depni dot sinp dot msu dot ru]

fix for bug 21137 causes a regression:

/* { dg-do run } */
void abort (void);

int main (void)
{
  int k = -1;
  if (((unsigned int) k >> 3) & 134217728)
return 0;
  abort ();
}

This bug is also known as miscompilation of emacs' keymap.c at -O0:
http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00276.html


-- 
   Summary: [4.2/4.3 regression] invalid folding of ((X >> C1) & C2)
!= 0 or "M-x is undefined" in emacs
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2006-11-05 17:40 
---
Subject: Bug 25545

Author: jvdelisle
Date: Sun Nov  5 17:40:42 2006
New Revision: 118507

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118507
Log:
2006-11-05  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25545
* gfortran.dg/dollar_edit_descriptor-2.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dollar_edit_descriptor-2.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/25545] internal file and dollar edit descriptor

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2006-11-05 17:35 
---
Subject: Bug 25545

Author: jvdelisle
Date: Sun Nov  5 17:35:30 2006
New Revision: 118506

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118506
Log:
2006-11-04  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25545
* io/transfer.c (write_block): Cleanup code paths between
stream and non-stream I/O.
(write_buf):  Cleanup.
(read_block): Cleanup.
(finalize_transfer): Call next_record for '$' edit descriptor handling
of internal unit. Cleanup code for readability.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c


-- 


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

[Bug fortran/27698] subroutine _foo draws "unclassifiable statement" instead of a useful error.

[aldot at gcc dot gnu dot org]

--- Comment #10 from aldot at gcc dot gnu dot org  2006-11-05 17:16 ---
> IIRC, the use of $ is a Digital extension on VMS.  It's
> been more than 15 years since I used VMS, but I vaguely
> remmeber seeing Fortran with the $ only in the 2nd position.
> 
> But, if Intel (a Digital descented) accepts the leading
> dollar sign, then your suggested modification is probably
> correct.
> 

According to
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlf101l.doc/xlfopg/extnames.htm
the XL fortran accepts
" 
Both the underscore (_) and the dollar sign ($) are valid characters anywhere
in names.
"
While we currently have -fdollar-ok to accept the (invalid !) use of '$' in a
name, we don't provide means to accept (invalid !) names with a leading
underscore. This would of course only serve compatibility to IBM's xlf and,
perhaps, other compilers.

Disallowing a dollar sign as the very first character in a name even if
-fdollar-ok was requested by the user seems to be a simple omission to me.

Whether we want to allow for such invalid code for compatibility is beyond my
judgement, though.


-- 


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

[Bug fortran/27698] subroutine _foo draws "unclassifiable statement" instead of a useful error.

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #9 from sgk at troutmask dot apl dot washington dot edu  
2006-11-05 17:00 ---
Subject: Re:  subroutine _foo draws "unclassifiable statement" instead of a
useful error.

On Sun, Nov 05, 2006 at 04:37:42PM -, aldot at gcc dot gnu dot org wrote:
> 
> > How does Intel's iand other commercial compilers handle
> > a leading dollar?  The standard is quite clear that the
> > first character in a name is an alphabetic character.
> > 
> ifort-9.1.xx accept it without any notice.
> Why would a leading dollar be different to anywhere else in a name?
> 

IIRC, the use of $ is a Digital extension on VMS.  It's
been more than 15 years since I used VMS, but I vaguely
remmeber seeing Fortran with the $ only in the 2nd position.

But, if Intel (a Digital descented) accepts the leading
dollar sign, then your suggested modification is probably
correct.


-- 


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

[Bug c/29725] (signed char) to (signed int) typecast missbehaves

[stian at nixia dot no]

--- Comment #2 from stian at nixia dot no  2006-11-05 16:51 ---
But no releases that fixes this issue has been released in the 4.1.x serie as
far as I can see atleast.


-- 


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

[Bug tree-optimization/29145] unsafe use of restrict qualifier

[djg at cray dot com]

--- Comment #7 from djg at cray dot com  2006-11-05 16:50 ---
(In reply to comment #5)

"based on" basically means copied from, and possibly incremented or
decremented, though not necessarily in obvious ways. Your example is
legal; q is based on p.

BTW, I made a mistake in my earlier suggestion; simply checking that both
pointers are restrict-qualified isn't sufficient if expressions may have
moved across the original C scope boundaries. 


-- 


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

[Bug fortran/27698] subroutine _foo draws "unclassifiable statement" instead of a useful error.

[aldot at gcc dot gnu dot org]

--- Comment #8 from aldot at gcc dot gnu dot org  2006-11-05 16:37 ---
> How does Intel's iand other commercial compilers handle
> a leading dollar?  The standard is quite clear that the
> first character in a name is an alphabetic character.
> 
ifort-9.1.xx accept it without any notice.
Why would a leading dollar be different to anywhere else in a name?

$ rm -f invalid.o ; cat invalid.f 
  subroutine $invalid_but_whatever
  end subroutine $invalid_but_whatever
  end
$ ifort -warn all -check all -o invalid.o -c invalid.f && nm invalid.o
 U for_set_reentrancy
 U __intel_new_proc_init
002a T $invalid_but_whatever_
 r LITPACK_0.0.1
 T MAIN__


-- 


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

[Bug fortran/27698] subroutine _foo draws "unclassifiable statement" instead of a useful error.

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #7 from sgk at troutmask dot apl dot washington dot edu  
2006-11-05 16:27 ---
Subject: Re:  subroutine _foo draws "unclassifiable statement" instead of a
useful error.

On Sun, Nov 05, 2006 at 04:19:08PM -, aldot at gcc dot gnu dot org wrote:
> 
> --- Comment #6 from aldot at gcc dot gnu dot org  2006-11-05 16:19 ---
> Updating the testsuite to account for the new error message now.
> 
> Note that i think that we should take -fdollar-ok into account, i.e.:
> 
> if (!ISALPHA (c) && !(gfc_option.flag_dollar_ok && c == '$'))
>   {
> bail;
>   }
> 
> to allow for names (in the sense of 3.2.1) that begin with a dollar.
> 
> Such names are currently rejected (even if -fdollar-ok suggests that they
> should be ok).
> 
> 

How does Intel's iand other commercial compilers handle
a leading dollar?  The standard is quite clear that the
first character in a name is an alphabetic character.


-- 


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

[Bug tree-optimization/29718] [4.2/4.3 Regression] ice in add_virtual_operand with some C++ code

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Target Milestone|4.1.2   |4.2.0


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

[Bug fortran/27698] subroutine _foo draws "unclassifiable statement" instead of a useful error.

[aldot at gcc dot gnu dot org]

--- Comment #6 from aldot at gcc dot gnu dot org  2006-11-05 16:19 ---
Updating the testsuite to account for the new error message now.

Note that i think that we should take -fdollar-ok into account, i.e.:

if (!ISALPHA (c) && !(gfc_option.flag_dollar_ok && c == '$'))
  {
bail;
  }

to allow for names (in the sense of 3.2.1) that begin with a dollar.

Such names are currently rejected (even if -fdollar-ok suggests that they
should be ok).


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org


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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2006-11-05 16:16 ---
The testcase explicitly calls __builtin_lceil which we then cannot expand at
all.
We can open-code lceil like I did for SSE expansion using

xi = (long)op1;
xi -= (double)xi > op1 ? 1 : 0;

which should be always ok as lceil and lfloor are GCC extensions, so we don't
need to worry about IEEE or errno setting.

I'm going to fix this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-05 16:16:22
   date||


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

[Bug c/29725] (signed char) to (signed int) typecast missbehaves

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-11-05 16:11 ---
This is fixed already.


-- 


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

[Bug tree-optimization/29145] unsafe use of restrict qualifier

[dorit at il dot ibm dot com]

--- Comment #6 from dorit at il dot ibm dot com  2006-11-05 15:48 ---
(In reply to comment #5)
> This was something that slipped in, IIRC. I was of Ian's viewpoint, that
> may_alias_p should handle it, and it shouldn't be special to data-references.

yes, it was originally added as a temporary hack until alias analysis did
something with restrict


-- 


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

[Bug fortran/21061] gfortran ignores -Werror

[aldot at gcc dot gnu dot org]

--- Comment #5 from aldot at gcc dot gnu dot org  2006-11-05 14:57 ---
Subject: Bug 21061

Author: aldot
Date: Sun Nov  5 14:57:24 2006
New Revision: 118501

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118501
Log:
2006-11-05  Bernhard Fischer  <[EMAIL PROTECTED]>

PR fortran/21061
* error.c (gfc_warning): If warnings_are_errors then treat
warnings as errors with respect to the exit code.
(gfc_notify_std): Ditto.
(gfc_warning_now): Ditto.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c


-- 


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

[Bug c/29725] New: (signed char) to (signed int) typecast missbehaves

[stian at nixia dot no]

The following code-snippest generate wrong numbers with gcc 4.1.1 using -O, -O1
and -O2.

#include 
int main(int arg, char *argv[])
{
int j;
for (j=0; j<256; j++)
{
signed char j2=(signed char)j;
printf("%d\n", (signed int)j2);
}
return 0;
}


http://bugs.gentoo.org/show_bug.cgi?id=154079


-- 
   Summary: (signed char) to (signed int) typecast missbehaves
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stian at nixia dot no
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2006-11-05 14:52 ---
(In reply to comment #3)

> I had a slightly deeper look.  The ceilf builtin is defined only
> for C99 targets in builtins.def:
> 
> DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILF, "ceilf", BT_FN_FLOAT_FLOAT,
> ATTR_CONST_NOTHROW_LIST)

But please consider this part from convert.c, function convert_to_integer():

  switch (fcode)
{
CASE_FLT_FN (BUILT_IN_CEIL):
  /* Only convert in ISO C99 mode.  */
  if (!TARGET_C99_FUNCTIONS)
break;
  if (outprec < TYPE_PRECISION (long_integer_type_node)
  || (outprec == TYPE_PRECISION (long_integer_type_node)
  && !TYPE_UNSIGNED (type)))
fn = mathfn_built_in (s_intype, BUILT_IN_LCEIL);
  else if (outprec == TYPE_PRECISION (long_long_integer_type_node)
   && !TYPE_UNSIGNED (type))
fn = mathfn_built_in (s_intype, BUILT_IN_LLCEIL);
  break;

TARGET_C99_FUNCTIONS should prevent this transformation, when we can't
fall-back to ceilf().


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug ada/26306] [4.0/4.1/4.2/4.3 regression] ICE volatile array with non-constant bounds

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2006-11-05 13:03 
---
Testing fix.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-15 18:05:34 |2006-11-05 13:03:17
   date||


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

[Bug ada/26306] [4.0/4.1/4.2/4.3 regression] ICE volatile array with non-constant bounds

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-11-05 13:02 
---
"included in the description" is not a target.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|included in description |*-*-*
   GCC host triplet|included in description |*-*-*
 GCC target triplet|included in description |*-*-*
Summary|Use of volatile array with  |[4.0/4.1/4.2/4.3 regression]
   |bounds determined at run|ICE volatile array with non-
   |time.   |constant bounds


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

[Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2006-11-05 12:18 ---
Subject: Bug 29695

Author: jakub
Date: Sun Nov  5 12:18:09 2006
New Revision: 118499

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118499
Log:
PR middle-end/29695
* fold-const.c (fold_ternary): Fix A < 0 ?  : 0
simplification.

* gcc.c-torture/execute/pr29695-1.c: New test.
* gcc.c-torture/execute/pr29695-2.c: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr29695-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr29695-2.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/fold-const.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2006-11-05 12:18 ---
Subject: Bug 29695

Author: jakub
Date: Sun Nov  5 12:18:03 2006
New Revision: 118498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118498
Log:
PR middle-end/29695
* fold-const.c (fold_ternary): Fix A < 0 ?  : 0
simplification.

* gcc.c-torture/execute/pr29695-1.c: New test.
* gcc.c-torture/execute/pr29695-2.c: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr29695-1.c
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr29695-2.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/fold-const.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2006-11-05 12:13 ---
Subject: Bug 29695

Author: jakub
Date: Sun Nov  5 12:13:46 2006
New Revision: 118497

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118497
Log:
PR middle-end/29695
* fold-const.c (fold_ternary): Fix A < 0 ?  : 0
simplification.

* gcc.c-torture/execute/pr29695-1.c: New test.
* gcc.c-torture/execute/pr29695-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr29695-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr29695-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2006-11-05 12:12 ---
Sorry for adding duplicate PRs.

I had a slightly deeper look.  The ceilf builtin is defined only
for C99 targets in builtins.def:

DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILF, "ceilf", BT_FN_FLOAT_FLOAT,
ATTR_CONST_NOTHROW_LIST)

but the lceilf builtin is defined without any condition:

DEF_GCC_BUILTIN(BUILT_IN_LCEILF, "lceilf", BT_FN_LONG_FLOAT,
ATTR_MATHFN_FPROUNDING)

and it seems that expand_builtin_int_roundingfn function requires 
implicit_built_in_decls[BUILT_IN_CEILF], which is null, as a fallback.


-- 


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

[Bug ada/29707] s-osinte.adb:86:13: warning: function "To_Target_Priority" is not referenced

[charlet at gcc dot gnu dot org]

--- Comment #5 from charlet at gcc dot gnu dot org  2006-11-05 11:01 ---
Fixed.


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug ada/29707] s-osinte.adb:86:13: warning: function "To_Target_Priority" is not referenced

[charlet at gcc dot gnu dot org]

--- Comment #4 from charlet at gcc dot gnu dot org  2006-11-05 10:58 ---
Subject: Bug 29707

Author: charlet
Date: Sun Nov  5 10:58:41 2006
New Revision: 118496

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118496
Log:
* s-osinte-linux-alpha.ads, s-osinte-linux-hppa.ads
(To_Target_Priority): New function.
Fix PR ada/29707

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/s-osinte-linux-alpha.ads
trunk/gcc/ada/s-osinte-linux-hppa.ads


-- 


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

[Bug ada/29707] s-osinte.adb:86:13: warning: function "To_Target_Priority" is not referenced

[charlet at adacore dot com]

--- Comment #3 from charlet at adacore dot com  2006-11-05 10:48 ---
Subject: Re:   New: s-osinte.adb:86:13: warning: function "To_Target_Priority"
is not referenced

You need to add a spec for To_Target_Priority in s-osinte-linux-hppa.ads

Better in the medium term would be to merge s-osinte-linux-hppa.ads with
s-osinte-linux.ads as suggested in the past, to avoid this kind of trouble.

We probably have a similar issue with s-osinte-linux-alpha.ads

Arno


-- 


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

[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2006-11-05 10:17 ---
Benjamin, can you have a look? I can reproduce, the issue seems confirmed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[lebedev at zhtw dot org dot ru]

--- Comment #12 from lebedev at zhtw dot org dot ru  2006-11-05 09:56 
---
(In reply to comment #11)
> Forgot: you may also consider reporting the bug to netbsd, or your favorite
> provider of packages, maybe that would help that community.  From our point of
> view, there isn't much more we can do, on the 3.4.x branch, sorry.
> 

Ok. Thank you anyway.


-- 


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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-05 09:39 ---
*** Bug 29723 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/29723] newlib targets ICEs in expand_builtin_int_roundingfn

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-05 09:39 ---


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


-- 

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

[Bug target/29724] newlib targets ICEs in expand_builtin_int_roundingfn

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-05 09:39 ---


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


-- 

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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-05 09:39 ---
*** Bug 29724 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/29724] New: newlib targets ICEs in expand_builtin_int_roundingfn

[kkojima at gcc dot gnu dot org]

On newlib targets, the compiler fails to compile

long testlf (float x)
{
  return __builtin_lceilf (x);
}

with the error

internal compiler error: in expand_builtin_int_roundingfn, at builtins.c:2298


-- 
   Summary: newlib targets ICEs in expand_builtin_int_roundingfn
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: *-unknown-elf


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

[Bug target/29723] New: newlib targets ICEs in expand_builtin_int_roundingfn

[kkojima at gcc dot gnu dot org]

On newlib targets, the compiler fails to compile

long testlf (float x)
{
  return __builtin_lceilf (x);
}

with the error

internal compiler error: in expand_builtin_int_roundingfn, at builtins.c:2298


-- 
   Summary: newlib targets ICEs in expand_builtin_int_roundingfn
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: *-unknown-elf


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