[Bug target/28084] [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-06-24 04:19 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[mark at codesourcery dot com]

--- Comment #4 from mark at codesourcery dot com  2006-06-24 04:10 ---
Subject: Re:  C++ (throw() and catch(...) {/*  fall through
 */ } ) and pthread cancellation are incompatible (at least with NPTL)

drow at gcc dot gnu dot org wrote:
> --- Comment #3 from drow at gcc dot gnu dot org  2006-06-24 02:52 ---
> No, that was not the consensus, and I reported this bug specifically because
> the coding practices used in libstdc++ cause problems with cancellation...
> progress was being made, the last time I read c++-pthreads, but trailed off.

I don't think it's necessary (or even useful) to wait for the standards
bodies to solve this problem.  In practice, the c++-pthreads discussion
died off, and the C++ POSIX reflector has had no activity since January.
 So, it's certainly going to be a while before we have standards
documents to rely upon.

However, we know that it should be possible to write cancel-safe C++
libraries (including, in particular, libstdc++); otherwise, it's hard to
use C++ in a multi-threaded application.  And, we know that we can do it
with a very simple hook: we just need a way to ask whether the current
thread is being cancelled.  GLIBC has lots of extensions; if we can have
__thread_cancelled(), we've got enough, without having to solve the
problem of whether or not it should be possible to catch (and not
rethrow) the thread-cancellation exception.  (I'd rather have a name for
the thread exception, as that seems more natural, but this is a
difference only of syntax; the hook function would be a perfectly
satisfactory way to make progress.)


-- 


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

[Bug c++/28148] [4.0/4.1/4.2 Regression] ICE with pointer to member function initializer and cast to a different type

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-06-24 03:55 ---
(In reply to comment #3)
> Subject: Re:  ICE with pointer to member function initializer
>  and cast to a different type
> That should be legal ISO c++. That type of constuct is used actually 
> pretty common in specific types of applications  (OS and embedded apps).

What I mean is that the type of the arguments and return type don't match so if
you use __Virtual__foo__Var1 without a cast back, the code would be undefined.


-- 


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

[Bug c++/28148] [4.0/4.1/4.2 Regression] ICE with pointer to member function initializer and cast to a different type

[donour at cs dot unm dot edu]

--- Comment #3 from donour at cs dot unm dot edu  2006-06-24 03:45 ---
Subject: Re:  ICE with pointer to member function initializer
 and cast to a different type

pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-24 02:03 
> ---
> I cannot figure out if this is undefined code or not but it should not at 
> least
> ICE.
>
>
>   
That should be legal ISO c++. That type of constuct is used actually 
pretty common in specific types of applications  (OS and embedded apps).

thanks

donour


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[drow at gcc dot gnu dot org]

--- Comment #3 from drow at gcc dot gnu dot org  2006-06-24 02:52 ---
No, that was not the consensus, and I reported this bug specifically because
the coding practices used in libstdc++ cause problems with cancellation...
progress was being made, the last time I read c++-pthreads, but trailed off.


-- 


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

[Bug libstdc++/27984] [4.2 Regression] installed libstdc++ testing broken

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-06-24 02:37 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/28148] ICE with pointer to member function initializer and cast to a different type

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-24 02:03 ---
I cannot figure out if this is undefined code or not but it should not at least
ICE.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work|3.3 |3.3 3.4.0
   Last reconfirmed|-00-00 00:00:00 |2006-06-24 02:03:16
   date||
Summary|Internal error in varasm.c  |ICE with pointer to member
   ||function initializer and
   ||cast to a different type
   Target Milestone|--- |4.0.4


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

[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-06-24 01:53 ---
Confirmed, fixed at least on the mainline.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-06-24 01:53:09
   date||
Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE
   |with struct definition in   |with struct definition in
   |argument of template|argument of template
   |function|function


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

[Bug c++/27019] [4.1 regression] ICE with designated initializers

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-24 01:52 ---
Fixed at least on the mainline.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2 regression] ICE|[4.1 regression] ICE with
   |with designated initializers|designated initializers


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

[Bug target/28138] [4.2 Regression] ext/pb_ds/example/basic_map.cc, etc fail: unaligned accesses at compile time

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-24 01:49 ---
Lets close it as fixed then.  Thanks.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug debug/28099] loses type in debug info

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2006-06-24 01:48 ---
Subject: Re:  loses type in debug info


On Jun 23, 2006, at 12:57 PM, Ilya N. Golubev wrote:

>
>> Next time please don't paste the preprocessed source in gccbug or  
>> in the
>> comments section in bugzilla.
>
> Please reverse the request to do so in 
> and update it and its copies included in releases.  In that update
> please also suggest another way to be specific in report.  AFAIK,
> unless was able to perform (generally, very tedious) experimentation
> and figure a short test program, it is the only way to be specific.

You should upload them via the attachment form.


-- Pinski


-- 


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

[Bug libstdc++/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-24 01:43 ---
Actually I think the consensus was talk to the C++ and POSIX standards comittee
about this case. 

 It is not just libstdc++ that could cause problems but any program that uses
throw() or catch(...) {/* fall through */ }.

In fact I can come up with a simple C++ case which fails without using
libstdc++.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
Summary|libstdc++ and pthread   |C++ (throw() and catch(...)
   |cancellation are|{/*  fall through */ } ) and
   |incompatible (at least with |pthread cancellation are
   |NPTL)   |incompatible (at least with
   ||NPTL)


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

[Bug libstdc++/27984] [4.2 Regression] installed libstdc++ testing broken

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2006-06-24 00:13 ---
Subject: Bug 27984

Author: bkoz
Date: Sat Jun 24 00:13:08 2006
New Revision: 114955

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114955
Log:
2006-06-23  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/27984
* testsuite/lib/libstdc++.exp (libstdc++_init): Adjust
testing includes.
* docs/html/test.html: Adjust for testsuite changes.



Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/docs/html/test.html
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp


-- 


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

[Bug target/28138] [4.2 Regression] ext/pb_ds/example/basic_map.cc, etc fail: unaligned accesses at compile time

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2006-06-23 23:59 ---
Just tested and seems fixed indeed. Thanks a lot!


-- 


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

[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0

[seongbae dot park at gmail dot com]

--- Comment #5 from seongbae dot park at gmail dot com  2006-06-23 23:55 
---
Looks like this indeed is a duplicate of 27657.

In toplev.c:
   1013   cgraph_varpool_assemble_pending_decls ();
...
   1040   (*debug_hooks->finish) (main_input_filename);

dwarf2 finish ends up calling final.c:output_address w/ SYMREF to hacky_auxmap,
which calls mark_decl_referenced() for hacky_auxmap declaration
and is added to the pending list of varpool decls to be emitted.
However, there's no call to cgraph_varpool_assemble_pending_decls() 
so even though hacky_auxmap is marked as needed, it won't get output.

Calling 
cgraph_varpool_assemble_pending_decls() 
after debug hook finish can alleviate the linking problem
by forcing the emission of hacky_auxmap (which seems 
unused except for debug information purpose,
after uncalled static function elimination).

However, the real cause is having const value marking for an unused 
(and hence removed) static variable - gcc seems to determine
that auxmap is not used, after some removal of unused static functions
and the analysis looks correct (though I didn't try hard to verify that).


-- 


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

[Bug debug/28063] [4.2 regression] Dwarf no longer uses merged strings for DW_AT_comp_dir

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-06-23 23:48:51
   date||


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

[Bug libstdc++/27984] [4.2 Regression] installed libstdc++ testing broken

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2006-06-23 23:43 ---
Created an attachment (id=11737)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11737&action=view)
fix


-- 


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

[Bug c++/28148] Internal error in varasm.c

[donour at cs dot unm dot edu]

--- Comment #1 from donour at cs dot unm dot edu  2006-06-23 23:14 ---
Created an attachment (id=11736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11736&action=view)
demo of reported behavior


-- 


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

[Bug c++/28148] New: Internal error in varasm.c

[donour at cs dot unm dot edu]

I have a very simple piece of code that will produce the following error:

--
test.C:5: internal compiler error: in output_constant, at varasm.c:4031
--

A simple code fragment to reproduce this bug is:

--
struct foo {
public:
  virtual int bar(int);
};

void (foo::*__Virtual__foo__Var1)() = (void (foo::*)())(&foo::bar);
--

I've observed this bug on both ppc and x86 platforms with various builds of the
4.1.x and 4.0.x trees. Note that 3.x _will_ compile this correctly.

thanks

Donour Sizemore


-- 
   Summary: Internal error in varasm.c
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: donour at cs dot unm dot edu
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


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

[Bug c++/28114] [4.0/4.1/4.2 regression] ICE with struct definition in argument of template function

[sje at gcc dot gnu dot org]

--- Comment #2 from sje at gcc dot gnu dot org  2006-06-23 21:58 ---
Subject: Bug 28114

Author: sje
Date: Fri Jun 23 21:58:25 2006
New Revision: 114953

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114953
Log:
PR c++/28114
* name-lookup.c (pushtag): Return if we have error_mark_node.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c


-- 


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

[Bug c++/27019] [4.1/4.2 regression] ICE with designated initializers

[sje at gcc dot gnu dot org]

--- Comment #4 from sje at gcc dot gnu dot org  2006-06-23 21:53 ---
Subject: Bug 27019

Author: sje
Date: Fri Jun 23 21:53:36 2006
New Revision: 114952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114952
Log:
PR c++/27019
* typeck2.c (process_init_constructor_array): Set ce->value on errors.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c


-- 


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

[Bug target/28138] [4.2 Regression] ext/pb_ds/example/basic_map.cc, etc fail: unaligned accesses at compile time

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2006-06-23 21:31 ---
It should be.  Let's wait for new testresults.


-- 


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

[Bug target/28138] [4.2 Regression] ext/pb_ds/example/basic_map.cc, etc fail: unaligned accesses at compile time

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-23 21:29 ---
Is this fixed now after Richard G.'s newest patch?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING
Summary|ext/pb_ds/example/basic_map.|[4.2 Regression]
   |cc, etc fail: unaligned |ext/pb_ds/example/basic_map.
   |accesses at compile time|cc, etc fail: unaligned
   ||accesses at compile time
   Target Milestone|--- |4.2.0


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

[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2006-06-23 21:15 ---
trying to reduce it.


-- 


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

[Bug fortran/27981] Strange error message for illegal integer constant

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2006-06-23 21:12 ---
Applied to trunk.  I'll apply this to 4.1 in a few days.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/27981] Strange error message for illegal integer constant

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2006-06-23 21:05 ---
Subject: Bug 27981

Author: kargl
Date: Fri Jun 23 21:05:04 2006
New Revision: 114950

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114950
Log:
2006-06-23  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/27981
* match.c (gfc_match_if):  Handle errors in assignment in simple if.

2006-06-23  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/27981
* gfortran.dg/simpleif_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/simpleif_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2006-06-23 21:03 ---
Ok, looks like it is s390 specific because I can reproduce it with
gcc version 4.1.2 20060531 (prerelease)
/usr/lib/gcc/s390-suse-linux/4.1.2/cc1 -fpreprocessed t.i -quiet -dumpbase t.i
-march=z900 -mtune=z9-109 -m31 -mesa -auxbase t -O2 -version -o /tmp/ccuMU6kl.s

ppc, ppc64, i686 and x86_64 are fine with the same version.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608

[list+gcc-bugzilla at meyering dot net]

--- Comment #4 from list+gcc-bugzilla at meyering dot net  2006-06-23 20:26 
---
Created an attachment (id=11735)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11735&action=view)
Here's the output of running gcc -I.. -I. -g -O2 ~/j.c -v

Here's the output of running gcc -I.. -I. -g -O2 ~/j.c -v


-- 


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

[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2006-06-23 20:12 ---
It produces
38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b
for me with -O and -O2.  Can you post the output of

gcc -I.. -I. -g -O2 ~/j.c -v

?


-- 


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

[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608

[list+gcc-bugzilla at meyering dot net]

--- Comment #2 from list+gcc-bugzilla at meyering dot net  2006-06-23 19:58 
---
Created an attachment (id=11734)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11734&action=view)
preprocessed input

Here's the same j.i file, as an attachment.


-- 


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

[Bug debug/28099] loses type in debug info

[gin at mo dot msk dot ru]

--- Comment #2 from gin at mo dot msk dot ru  2006-06-23 19:57 ---
Subject: Re:  loses type in debug info

As for marking the bug as already reported, this seems plausible to
me.  Confirming that `.i' sent in my bug report uses "lost" type in
exactly the same way as test code in PR 21391; moreover, the entire
program including that `.i' appears to use it exactly the same way.
Unfortunately, checking for that would mean vgrep in bug database,
which could not possibly do.  So did violate
 wrt duplicate bug reports, and most
likely will do that again.  After all, nobody makes slightest fuss
about that, and before doing it, he should ensure that bug database is
easily vgrep'able, that is, fairly small :-/.


"pinskia at gcc dot gnu dot org" writes:

> Next time please don't paste the preprocessed source in gccbug or in the
> comments section in bugzilla.

Please reverse the request to do so in 
and update it and its copies included in releases.  In that update
please also suggest another way to be specific in report.  AFAIK,
unless was able to perform (generally, very tedious) experimentation
and figure a short test program, it is the only way to be specific.

> One more note, 2.96 was never an official release.

Perhaps should state that explicitly in future reports.  Anyway, did
include full name of the system binary package, so that anybody can
identify the snapshot it is based on (and if no, avoid using systems
from that vendor).

As for binary packages based on official releases, neither observed it
in `gcc-3.3.2-6mdk'.


-- 


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

[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-06-23 19:50 ---
Can you please attach the preprocessed source rather than pasting it in?  (I
know there was no way to do so on the new bug page)

Thanks!


-- 


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

[Bug bootstrap/28082] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-23 19:03 ---
(In reply to comment #4)
> It works now.
> First i installed gcc 3.4.6 and used that compiler (before that i used 3.2.1).
No more likely 3.2.1 was miscompiling part of 4.1.1.
If you did not use "make bootstrap", that is the most likely. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0

[seongbae dot park at gmail dot com]

--- Comment #4 from seongbae dot park at gmail dot com  2006-06-23 18:43 
---
The problem is causedby the extra DW_AT_const_value.
4.1.0 generates the following dwarf entry for auxmap:

 <1>: Abbrev Number: 31 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x35e): auxmap
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 362
 DW_AT_type: 
 <1>: Abbrev Number: 26 (DW_TAG_const_type)

whereas 4.2.0 generates:
 <1><9c6e>: Abbrev Number: 70 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x16dd): auxmap_used
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 361
 DW_AT_type: <9c69>
 DW_AT_const_value : 0

and the bad relocation is the value of DW_AT_const_value.
In the asembly:
.uleb128 0x48
.long   .LASF367
.byte   0x1
.value  0x16a
.long   0x9c8b
.long   hacky_auxmaps
.uleb128 0x1b

Looks like the new feature to note the constant value of a symbol 
(auxmap is initialized to &hacky_auxmaps[0] as shown above)
causes the relocation to be left against a static symbol.


-- 

seongbae dot park at gmail dot com changed:

   What|Removed |Added

 CC||seongbae dot park at gmail
   ||dot com


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

[Bug bootstrap/28082] internal compiler error: Segmentation fault

[info at pion dot xs4all dot nl]

--- Comment #4 from info at pion dot xs4all dot nl  2006-06-23 18:31 ---
It works now.

First i installed gcc 3.4.6 and used that compiler (before that i used 3.2.1).

Then i used the following configuration:
Target: hppa2.0w-hp-hpux11.00
Configured with: /*/gcc-4.1.1/configure
--with-as=/opt/OpenSource/binutils/bin/as --with-gnu-as
--prefix=/opt/OpenSource/gcc-4.1.1 --without-libffi --enable-threads=posix
Thread model: posix gcc version 4.1.1

Probably the '--without-libffi' was the sollution


-- 


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

[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0

[seongbae dot park at gmail dot com]

--- Comment #3 from seongbae dot park at gmail dot com  2006-06-23 18:26 
---
I'm able to reproduce the problem with 4.2.0 on linux/x86.

valgrind-3.2.0/memcheck/mc_main.c has 

359 static AuxMapEnt  hacky_auxmaps[N_AUXMAPS];
...
362 static AuxMapEnt* auxmap  = &hacky_auxmaps[0];

There's no direct use of hacky_auxmaps except through auxmap.

Anyway, 4.2 leaves the relocation:

# readelf -s ./bad.o | grep aux
   323:  0 NOTYPE  GLOBAL DEFAULT  UND hacky_auxmaps
# readelf -r ./bad.o | grep aux
9c87  00014301 R_386_32     hacky_auxmaps
#

which obviously can not be resolved. 
The bad relocation is in .rel.debug_info section.

I'll try to trace back why the bad relocation is generated.


-- 


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

[Bug libstdc++/28145] libstdc++ and pthread cancellation are incompatible (at least with NPTL)

[mark at codesourcery dot com]

--- Comment #1 from mark at codesourcery dot com  2006-06-23 18:14 ---
Subject: Re:   New: libstdc++ and pthread cancellation
 are incompatible (at least with NPTL)

drow at gcc dot gnu dot org wrote:

> On targets using a recent version of glibc and the NPTL threading package, if
> you cancel a thread using pthread_cancel while it is writing to an ostream,
> you'll get a fatal error and an abort from glibc.

> This problem has been discussed at length on the c++-pthreads list, but I 
> don't
> think a consensus was really reached.

I believe that to solve this particular problem, a possible compromise
might be:

(1) Give the thread-cancellation exception a well-known name.
(2) Permit catching that exception -- but only if it is rethrown.

The point of (2) is that it avoids the controversy about whether or not
you are permitted to catch, and then not rethrow, the exception.

Then, you could write:

  try {
io ();
  } catch (__thread_cancel&) {
throw;
  } catch (...) {
/* Normal catch handling.  */
  }

That would provide a mechanism for making libstdc++ (and other
applications) cancel-safe.  It would still not solve the general
philosophical issues about whether or not you should be allowed to fail
to "eat" the cancellation exception, but I think it would be a step forward.

Another way to do this, instead of having a named exception, would be to
have a "__uncaught_cancellation()" function, similar to
"std::__uncaught_exception()".  Then, you would do:

  try {
io ();
  } catch (...) }
if (__uncaught_cancellation ())
  throw;
/* Normal catch handling.  */
  }


-- 


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

[Bug libstdc++/28145] New: libstdc++ and pthread cancellation are incompatible (at least with NPTL)

[drow at gcc dot gnu dot org]

(This is not a new problem, and everyone involved is familiar with it.  I was
just surprised not to find a record of it in bugzilla.)

On targets using a recent version of glibc and the NPTL threading package, if
you cancel a thread using pthread_cancel while it is writing to an ostream,
you'll get a fatal error and an abort from glibc.  The abort happens because
std::ostream::put uses catch(...), catches the cancellation exception, and does
not rethrow it.  You can write a nasty workaround for this, but I'm obviously
not going to recommend it:

int cancelled = 0;  
try {   
 pthread_cleanup_push(something-to-set-cancelled);  
  write()   
  pthread_cleanup_pop(discard-cleanups);
} catch (...) { 
  if (cancelled) throw; 
  normal-catch-handling;
}   

That would only work if there was nothing marked throw() on the way up, of
course.

This problem has been discussed at length on the c++-pthreads list, but I don't
think a consensus was really reached.


-- 
   Summary: libstdc++ and pthread cancellation are incompatible (at
least with NPTL)
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: *-*-linux*


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

[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java

[amylaar at gcc dot gnu dot org]

--- Comment #1 from amylaar at gcc dot gnu dot org  2006-06-23 17:55 ---
Created an attachment (id=11733)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11733&action=view)
patch

I'm currently testing this patch.


-- 


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

[Bug c++/28112] [4.0/4.1/4.2 regression] ICE with invalid argument in attribute

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2006-06-23 17:11 
---
Fixed on mainline, 4.1 branch, and 4.0 branch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/28112] [4.0/4.1/4.2 regression] ICE with invalid argument in attribute

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2006-06-23 17:10 
---
Subject: Bug 28112

Author: reichelt
Date: Fri Jun 23 17:10:11 2006
New Revision: 114943

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114943
Log:
PR c++/28112
* parser.c (cp_parser_attribute_list): Skip attributes with invalid
arguments.  Fix comment.

* g++.dg/ext/attrib23.C: New test.

Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/attrib23.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/28112] [4.0/4.1/4.2 regression] ICE with invalid argument in attribute

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2006-06-23 17:06 
---
Subject: Bug 28112

Author: reichelt
Date: Fri Jun 23 17:06:13 2006
New Revision: 114942

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114942
Log:
PR c++/28112
* parser.c (cp_parser_attribute_list): Skip attributes with invalid
arguments.  Fix comment.

* g++.dg/ext/attrib23.C: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/attrib23.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/28112] [4.0/4.1/4.2 regression] ICE with invalid argument in attribute

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2006-06-23 17:02 
---
Subject: Bug 28112

Author: reichelt
Date: Fri Jun 23 17:02:38 2006
New Revision: 114941

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114941
Log:
PR c++/28112
* parser.c (cp_parser_attribute_list): Skip attributes with invalid
arguments.  Fix comment.

* g++.dg/ext/attrib23.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/attrib23.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/28080] header dependencies

[chris at bubblescope dot net]

--- Comment #9 from chris at bubblescope dot net  2006-06-23 16:47 ---
I just tried preprocessing vector, as an example. There isn't any obvious
low-hanging fruit. The major problem is that most of the C standard libary ends
up getting dragged in.

I think a better goal would be to make precompiled headers easier to use, and
inform users about them, although obviously cutting down on headers would still
be a good goal.


-- 


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

[Bug c/28141] thread-local ptr initialized to address of thread-local misclassified as non-constant initializer

[gary at intrepid dot com]

--- Comment #2 from gary at intrepid dot com  2006-06-23 16:44 ---
I agree this is definitely an enhancement, but will note the following:

1. On Fedora Core 5, x86_64, I was able to successfully link and run
a null program (written in assembly) that initializes thread local
'ptr' that points to thread local 'data'.  The declarations appear
as follows:
.globl data
.section.tbss,"awT",@nobits
.align 8
.type   data, @object
.size   data, 8
data:
.zero   8
.globl ptr
.align 8
.type   ptr, @object
.size   ptr, 8
ptr:
.quad   data
I didn't run extensive tests to verify this was doing the right thing, but
there were no complaints from the linker.

2. Given that __thread is an extension, we could choose to interpret
"constancy", as "constant from the perspective of the currently executing
thread" without doing much harm to "C" semantics.


-- 


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

[Bug tree-optimization/28144] New: floating point constant -> byte/char/short conversion is wrong for java

[amylaar at gcc dot gnu dot org]

According to:
http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#25363

java conversions of floating point values to integer types smaller than int
should be done by converting to integer first, and then from int to the target
type.  While the former conversion is done with saturation, the latter is
done by discarding the most significant bits.
i.e. 65536.0 converted to char is 0 .

However, fold_convert_const_int_from_real will compute 65535 instead.


-- 
   Summary: floating point constant -> byte/char/short conversion is
wrong for java
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug libstdc++/28080] header dependencies

[gdr at integrable-solutions dot net]

--- Comment #8 from gdr at integrable-solutions dot net  2006-06-23 16:35 
---
Subject: Re:  header dependencies

"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:

| I did implement a version of this myself, basically by writing a
| mapper around each container that did a few static_casts and mapped
| the functions to a void* version of the container. However, having a
| whole new bunch of inline functions causes problems for the
| compiler, without providing (as far as I could measure) 
| significant reductions in the size of the executable.

I'm not surprised.  We should be very cautious about increasing
abstraction penablty for the benefit of marginal reduction on header
dependencies.  Runtime performance of the library should not be
under-emphasized. 

-- Gaby


-- 


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

[Bug target/28084] [4.2 Regression] /usr/include/errno.h:28: error: previous declaration of 'int errno' with 'C++' linkage

[sje at gcc dot gnu dot org]

--- Comment #5 from sje at gcc dot gnu dot org  2006-06-23 16:22 ---
Subject: Bug 28084

Author: sje
Date: Fri Jun 23 16:21:54 2006
New Revision: 114939

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114939
Log:
PR target/28084
* inclhack.def (hpux_extern_errno): New.
* fixincl.x: Regenerate.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def


-- 


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

[Bug c++/11006] [CNI] ICE with use of __java_boolean

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2006-06-23 16:08 
---
The ICE
  internal compiler error: can't find class$
has been fixed on mainline (see PR 11468), but the ICE mentioned in
commment #5 is still present.


-- 


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

[Bug c++/11468] Deriving from CNI class java::lang::Object causing an ICE

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2006-06-23 16:05 
---
Fixed on mainline.

Instead of 
  bug.cc:55: internal compiler error: can't find class$
we now get a regular error with more information:
  bug.cc:55: error: can't find 'class$' in 'MyClass'


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/11468] Deriving from CNI class java::lang::Object causing an ICE

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2006-06-23 16:00 
---
Subject: Bug 11468

Author: reichelt
Date: Fri Jun 23 15:59:51 2006
New Revision: 114937

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114937
Log:
PR c++/11468
* init.c (build_new_1): Handle error_mark_nodes returned by
build_java_class_ref.
(build_java_class_ref): Do not abort compilation, but return
error_mark_node.  Improve error message.  Fix indentation.

* g++.dg/other/java2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/java2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2006-06-23 15:43 ---
Now for the hard work of writing simplify_transfer!

Paul


-- 


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

[Bug fortran/20876] Subroutine call in FORALL block not PURE

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2006-06-23 15:42 ---
Fixed on trunk and 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=20876

[Bug fortran/16206] rejects valid array initialization expression

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2006-06-23 15:41 ---
Fixed on trunk and 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=16206

[Bug fortran/25050] CSHIFT not allowed in initialization expression

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-06-23 15:40 ---
Fixed on trunk and 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=25050

[Bug fortran/25049] TRANSPOSE not allowed in initialisation expression

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-06-23 15:40 ---
Fixed on trunk and 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=25049

[Bug libstdc++/28080] header dependencies

[chris at bubblescope dot net]

--- Comment #7 from chris at bubblescope dot net  2006-06-23 15:33 ---
(In reply to comment #4)
> Subject: Re:  header dependencies
> 
> On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote:
> > --- Comment #1 from pcarlini at suse dot de  2006-06-19 09:29
> > Ok, let's see what we can do...
> 
> Wow, fast reply! I hope you're successful :-) Maybe you could look at 
> STLPort 5.x, AFAIK it's "more" efficient in this case. It also has 
> other nice features like:
> 
> - STL containers vector, deque, list and slist pointer specialization to 
> limit code bloats (see _STLP_USE_PTR_SPECIALIZATIONS on config file); 
> 

I haven't looked at STLPort's implemenetation of this. However, this will make
the problem of too much preprocessed source worse, not better, as it will
involve more code, although the eventual executable might be smaller.

I did implement a version of this myself, basically by writing a mapper around
each container that did a few static_casts and mapped the functions to a void*
version of the container. However, having a whole new bunch of inline functions
causes problems for the compiler, without providing (as far as I could measure)
significant reductions in the size of the executable.


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug tree-optimization/25737] [4.1/4.2 Regression] ACATS c974001 c974013 hang with struct aliasing

[krebbel at gcc dot gnu dot org]

--- Comment #29 from krebbel at gcc dot gnu dot org  2006-06-23 15:16 
---
On s390x c974001, c974013 and cb20001 run into a infinite loop with current
mainline. At least the first two look related - not sure about the third.


-- 

krebbel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org
   Last reconfirmed|2006-03-22 09:53:52 |2006-06-23 15:16:14
   date||


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

[Bug c/28143] New: gcc.c-torture/execute/frame-address.c execution FAIL on sparc64

[christian dot joensson at gmail dot com]

Well, I see gcc.c-torture/execute/frame-address.c execution FAIL on sparc64,
linux and solaris,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00985.html,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00962.html, and
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00907.html.

I still see it on my currently running test run, LAST_UPDATED: Thu Jun
22 17:11:44 UTC 2006 (revision 114896)

the test program aborts, I can't run gdb on the binary so here's a strace64 on
execution (-O0):

strace64 ./frame-address.x0
execve("./frame-address.x0", ["./frame-address.x0"], [/* 22 vars */]) = 0
uname({sys="Linux", node="arnljot", ...}) = 0
brk(0)  = 0x202000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=35520, ...}) = 0
mmap(NULL, 35520, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf801
close(3)= 0
open("/lib64/libm.so.6", O_RDONLY)  = 3
read(3, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0+\0\0\0\1\0\0\0\0"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=1454502, ...}) = 0
mmap(NULL, 1878880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xf801c000
mprotect(0xf801000d2000, 1067872, PROT_NONE) = 0
mmap(0xf801001d, 32768, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc4000) = 0xf801001d
close(3)= 0
open("/lib64/libc.so.6", O_RDONLY)  = 3
read(3, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0+\0\0\0\1\0\0\0\0"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=8575053, ...}) = 0
mmap(NULL, 2421912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xf801001d8000
mprotect(0xf8010031c000, 1094808, PROT_NONE) = 0
mmap(0xf8010041a000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142000) = 0xf8010041a000
mmap(0xf80100424000, 13464, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf80100424000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xf801a000
mprotect(0xf8010041a000, 16384, PROT_READ) = 0
mprotect(0xf801001d, 8192, PROT_READ) = 0
mprotect(0xf801c903a000, 8192, PROT_READ) = 0
munmap(0xf801, 35520)   = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
getpid()= 15465
kill(15465, SIGABRT)= 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++

This specific was on 

Aurora SPARC Linux release 2.1 (Snowshoe FC3)/TI UltraSparc IIi (Sabre) sun4u:

binutils 2.17.50 20060610
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc-c++-3.4.2-6.fc3.sparc
gcc-gnat-3.4.2-6.fc3.sparc
glibc-2.3.6-0.fc3.1.sparc64
glibc-2.3.6-0.fc3.1.sparcv9
glibc-devel-2.3.6-0.fc3.1.sparc64
glibc-devel-2.3.6-0.fc3.1.sparc
glibc-headers-2.3.6-0.fc3.1.sparc
glibc-kernheaders-2.6-20sparc.sparc
gmp-4.1.4-3sparc.sparc
gmp-4.1.4-3sparc.sparc64
gmp-devel-4.1.4-3sparc.sparc
gmp-devel-4.1.4-3sparc.sparc64
kernel-2.6.16-1.2241sp1.sparc64
kernel-devel-2.6.16-1.2241sp1.sparc64
libgcc-3.4.2-6.fc3.sparc
libgcc-3.4.2-6.fc3.sparc64
libgcj-3.4.2-6.fc3.sparc
libgcj-devel-3.4.2-6.fc3.sparc
libstdc++-3.4.2-6.fc3.sparc
libstdc++-3.4.2-6.fc3.sparc64
libstdc++-devel-3.4.2-6.fc3.sparc
libstdc++-devel-3.4.2-6.fc3.sparc64
make-3.80-5.sparc
nptl-devel-2.3.6-0.fc3.1.sparcv9
tcl-8.4.7-2.sparc


-- 
   Summary: gcc.c-torture/execute/frame-address.c execution FAIL  on
sparc64
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot joensson at gmail dot com
 GCC build triplet: sparc64-*
  GCC host triplet: sparc64-*
GCC target triplet: sparc64-*


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

[Bug fortran/27996] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)

[tobias dot burnus at physik dot fu-berlin dot de]

--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de  
2006-06-23 13:01 ---
Additional remarks (which I forget to make):

Both cases are valid Fortran as:

(1) If the length of 'variable' is less than that of 'expr', the value of
'expr' is truncated from the right until it is the same length as the
'variable'.

(2) If the length of 'variable' is greater than that of 'expr', the value of
'expr' is extended on the right with blanks until it is the same length as
the variable.

However, I still think it is useful to give a compile-time warning. This for
example should produce a warning:

program test
  character(20),parameter :: path = 'mypath/'
  character(20),parameter :: file = path // 'myfile.txt'
  print *, trim(file)
end program test

whereas using "trim(path) // 'myfile.txt'" should not.


-- 


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

[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES

[info at yourkit dot com]

--- Comment #3 from info at yourkit dot com  2006-06-23 12:28 ---
I've discovered that if only C language is specified and --disable-libssp is
added (to work around bug #25035) then cross complier can be successfully
built. So the problem somewehere in C++ part.


-- 


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

[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers

[info at yourkit dot com]

--- Comment #9 from info at yourkit dot com  2006-06-23 12:09 ---
I can confirm this bug. 
target=i386-pc-solaris2.10; 
host=i386-pc-linux-gnu;
GCC 4.1.1; 
BinUtils 2.16.1

Checking multilib configuration...
/bin/sh /home/anton/tmp/gcc/gcc-4.1.1/mkinstalldirs i386-pc-solaris2.10/libssp
; \
rm -f i386-pc-solaris2.10/libssp/Makefile || : ; \
cp multilib.out i386-pc-solaris2.10/libssp/multilib.out
mkdir -p -- i386-pc-solaris2.10/libssp
Configuring in i386-pc-solaris2.10/libssp
configure: creating cache ./config.cache
checking build system type... i386-pc-linux-gnu
checking host system type... i386-pc-solaris2.10
checking target system type... i386-pc-solaris2.10
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i386-pc-solaris2.10-strip... i386-pc-solaris2.10-strip
checking for --enable-version-specific-runtime-libs... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking for i386-pc-solaris2.10-gcc... /home/anton/tmp/gcc/objdir/./gcc/xgcc
-B/home/anton/tmp/gcc/objdir/./gcc/
-B/opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/bin/
-B/opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/lib/ -isystem
/opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/include -isystem
/opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/sys-include
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libssp] Error 1
make[1]: Leaving directory `/home/anton/tmp/gcc/objdir'
make: *** [all] Error 2


-- 

info at yourkit dot com changed:

   What|Removed |Added

 CC||info at yourkit dot com


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

[Bug c++/28142] Template friend declaration and dependent names

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-06-23 11:57 ---
Fixed in 3.4.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/28142] New: Template friend declaration and dependent names

[wolfgang dot roehrl at gi-de dot com]

Dear all,

I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.

We use the compiler to generate code for a PowerPC processor.

Used invokation line for the GNU C++ compiler:

ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
  -fmerge-templates -mmultiple -mno-string -mstrict-align -O3
  -fno-exceptions -fno-rtti -fno-builtin-printf
  -I
  -D
  X.CPP -oX.O


// file X.CPP

template 
struct S
{
struct B;
};

class C
{
template 
friend struct S::B; // <--- line 10
};


The compiler gives the following error message:

X.CPP:10: warning: `S::B' is implicitly a typename
X.CPP:10: warning: implicit typename is deprecated, please see the 
   documentation for details
X.CPP:10: error: typename type `S::B' declared `friend'

According to 14.5.3/6 the compiler should accept the code above.


Kind regards
W. Roehrl


-- 
   Summary: Template friend declaration and dependent names
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
 GCC build triplet: sparc-sun-solaris2.5.1
  GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks


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

[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES

[info at yourkit dot com]

--- Comment #2 from info at yourkit dot com  2006-06-23 10:31 ---
I've charged target from "i386-pc-solaris2.10" to "i386-pc-solaris2.9"
and successfully built cross-compiler, but the resulting compiler
cannot produce 64bit binaries (as expected, because Solaris9 on Intel
is a 32bit).

I cannot understand where the problem is. All the libraries and header
files are copied from Solaris10 and I cannot build
"i386-pc-solaris2.10" target, but can build "i386-pc-solaris2.9".

Spent already 2 days digging Google and forums, but without success.
Please help.


-- 


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

[Bug c/28120] The option -f[no-]inline-functions is invalid with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2006-06-23 10:06 ---
Newer gcc always inline _static_ functions that are used _once_ into their only
caller (regardless of being declared inline or not).  You can disable this
behavior with -fno-inline-functions-called-once.

All gcc inline small functions regardless of beind declared inline or not, if
-finline-functions is in effect (which it is automatically at -O3).

But... why do you care?  The "inline" keyword is only a hint to the compiler,
not
something it has to obey to (or obey to the reverse case, where "inline" is not
specified).  So yes, you cannot control what is inlined or what not.  If you
need to for correctness, there's two function attributes,
__attribute__((noinline)) and __attribute__((always_inline)). 


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/28082] internal compiler error: Segmentation fault

[info at pion dot xs4all dot nl]

--- Comment #3 from info at pion dot xs4all dot nl  2006-06-23 09:59 ---
1) I installed the patches which are mentioned in the installation
documentation
2) Installed newer binutils
3) Checked on an other host
4) I have checked 4.1.0 which has the same problem
5) Could you give the details of the rports which tell that this works


-- 


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

[Bug middle-end/28045] [4.0/4.1 Regression] Bitfield, &&, and optimization => bad code generation

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2006-06-23 09:57 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/28045] [4.0/4.1 Regression] Bitfield, &&, and optimization => bad code generation

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2006-06-23 09:57 
---
Subject: Bug 28045

Author: rguenth
Date: Fri Jun 23 09:57:37 2006
New Revision: 114930

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114930
Log:
2006-06-23  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/28045
* fold-const.c (operand_equal_p): Check if the argument types
have the same precision before stripping NOPs.

* gcc.dg/torture/pr28045.c: New testcase.

Added:
branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/torture/pr28045.c
  - copied unchanged from r114772,
trunk/gcc/testsuite/gcc.dg/torture/pr28045.c
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/fold-const.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/28045] [4.0/4.1 Regression] Bitfield, &&, and optimization => bad code generation

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2006-06-23 09:52 ---
Subject: Bug 28045

Author: rguenth
Date: Fri Jun 23 09:52:40 2006
New Revision: 114929

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114929
Log:
2006-06-23  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/28045
* fold-const.c (operand_equal_p): Check if the argument types
have the same precision before stripping NOPs.

* gcc.dg/torture/pr28045.c: New testcase.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr28045.c
  - copied unchanged from r114772,
trunk/gcc/testsuite/gcc.dg/torture/pr28045.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=28045

[Bug c/28120] The option -f[no-]inline-functions is invalid with -O2

[tanaka at personal-media dot co dot jp]

--- Comment #6 from tanaka at personal-media dot co dot jp  2006-06-23 
09:52 ---
Please answer my question again.

It can not be distinguished between a function, which specified 
__inline__ and an another function, which is not specified __inline__, 
after gcc-3.4.

This is sample.

/ test.c /
static __inline__ int inl_small( int a)
{
return 2*a;
}

static int small(int a)
{
return 2*a;
}

int main()
{
int i;

i = inl_small(2);
i = small(i);
}
 mk.rc 
#!/bin/sh
set -v

BD3_4_5='/work/te/tool/Linux-i686'
GCC3_4_5="$BD3_4_5/bin/gcc"

BD3_3_2='/work/te/tool/Linux-i686-3.3.2'
GCC3_3_2="$BD3_3_2/bin/gcc"

ODP="$BD3_3_2/bin/objdump -C -S --disassemble-zeroes"

$GCC3_4_5 -O2   -c test.c -o 3_4_5_test_.o
$GCC3_4_5 -O2 -finline-functions-c test.c -o 3_4_5_test_inf.o
$GCC3_4_5 -O2 -fno-inline-functions -c test.c -o 3_4_5_test_noinf.o
$GCC3_4_5 -O2 -fno-inline   -c test.c -o 3_4_5_test_noin.o

$GCC3_3_2 -O2   -c test.c -o 3_3_2_test_.o
$GCC3_3_2 -O2 -finline-functions-c test.c -o 3_3_2_test_inf.o
$GCC3_3_2 -O2 -fno-inline-functions -c test.c -o 3_3_2_test_noinf.o
$GCC3_3_2 -O2 -fno-inline   -c test.c -o 3_3_2_test_noin.o

$ODP 3_4_5_test_.o  > 3_4_5_test_.o.odp
$ODP 3_4_5_test_inf.o   > 3_4_5_test_inf.o.odp
$ODP 3_4_5_test_noinf.o > 3_4_5_test_noinf.o.odp
$ODP 3_4_5_test_noin.o  > 3_4_5_test_noin.o.odp

$ODP 3_3_2_test_.o  > 3_3_2_test_.o.odp
$ODP 3_3_2_test_inf.o   > 3_3_2_test_inf.o.odp
$ODP 3_3_2_test_noinf.o > 3_3_2_test_noinf.o.odp
$ODP 3_3_2_test_noin.o  > 3_3_2_test_noin.o.odp
##
Result is

gcc-3.3.2 -O2 
inl_small() small()
inlined.not inlined.
-finline-functions  inlined.inlined.
-fno-inline-functions   inlined.not inlined.
-fno-inline not inlined.not inlined.


gcc-3.4.5 -O2 
inl_small   small
inlined.inlined.
-finline-functions  inlined.inlined.
-fno-inline-functions   inlined.inlined.
-fno-inline not inlined.not inlined.


It could be controlled to make a function inlined or not inlined,
according to specified __inline__ or not specified __inline__ 
before gcc-3.4.
But it can't after gcc-3.4.


I hope to confirm a conclusion.
That is to say, simple function is always integrated into their 
callers when it compiled with a option -O2, after gcc-3.4 isn't it?

Best regards.


-- 

tanaka at personal-media dot co dot jp changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/27789] [4.2 Regression] attribute handling fallout from DECL_INITIAL changes

[dannysmith at users dot sourceforge dot net]

--- Comment #5 from dannysmith at users dot sourceforge dot net  2006-06-23 
08:27 ---
Patch committed to trunk.
Danny


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/27789] [4.2 Regression] attribute handling fallout from DECL_INITIAL changes

[dannysmith at gcc dot gnu dot org]

--- Comment #4 from dannysmith at gcc dot gnu dot org  2006-06-23 08:25 
---
Subject: Bug 27789

Author: dannysmith
Date: Fri Jun 23 08:25:33 2006
New Revision: 114927

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114927
Log:
PR target/27789
* config/i386/winnt.c (ix86_handle_selectany_attribute): Move check
for initialization and setting of one_only flag to ...
(i386_pe_encode_section_info): ...here.
(i386_pe_dllimport_p): Check for DECL_DLLIMPORT_P also.
Recheck that the symbol has not been defined.

cp
* decl.c (start_decl): Check that dllimports are not initialized.

testsuite
* g++.dg/ext/dllimport4.C. Add more tests for invalid
initialization.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/winnt.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/dllimport4.C


-- 


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

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

[paul dot richard dot thomas at cea dot fr]

--- Comment #5 from paul dot richard dot thomas at cea dot fr  2006-06-23 
07:04 ---
It should be noted that encasing the two subroutines in a module produces the
correct error

 In file pr22571.f90:15

call a(q)
  1
Error: Type/rank mismatch in argument 'p' at (1)

The problem lies in the absence of global actual/formal argument checking;
where there is an explicit interface, all works correctly.

Paul


-- 


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