[Bug other/28328] Stack smash protection non-verbose

[nigelenki at comcast dot net]

--- Comment #16 from nigelenki at comcast dot net  2006-07-11 07:08 ---
(In reply to comment #15)
> (In reply to comment #14)
> 

...

> > Yes but now he has a limited number of code paths to go wrong on.
> 
> That is not true.  he just knows the last function and nothing more, this is
> where a debugger comes in handy to get the full backtrace.  You seem to think
> getting where the crash is, is a magic bullet at fixing an issue which it is
> not.  It sometimes (less than 5%) can be a magic bullet but then using a debug
> is part of the development cycle.
> 


Actually, here's what I think:

int main() {
  __foo();
}

void __foo() {
  __bar();
  __baz();
}

void __bar() {
  __qux();
}

void __baz() {
  return;
}

void __qux() {
  int a[5];
  strcpy(a, "hello!!");
}

Of main(), __foo(), __bar(), __baz(), and __qux(), the problem can only be in
main(), __foo(), __bar(), or __qux().  The problem can NOT be in __baz().

Yes, maybe if __baz() was called before __bar() and alters data __qux() uses
(i.e. data to be passed, or global data), then we include __baz() in the
equation.  My point is in a large program there will be functions that
effectively don't matter.  There is a large chance that the bug occurred
recently relative to a crash.

> > Um, there are only so many code paths that lead you to f().  There's a LOT 
> > of
> > code you can cut out of your program now...
> 
> What from 100 million down to 90 million, yes you cut the problem down by 1%
> but there still can be a huge amount to go.
> 

Each time you use a piece of data that is in an inconsistent state with what
the program expects, you have a chance of causing damage.  Each time you cause
damage, you have a chance of creating a fatal condition.

Probaibilisticly, the more you use a piece of damaged data, the more likely the
program is to experience a fatal bug.  To make a long story short, it's highly
likely that the bug was recently caused; and highly unlikely that you can go
all the way back to a bug in main() through 90 million lines of called code and
find the problem.

Of course that's just mathematic theory.

> 
> > And you pick up the "Emergency Phone," and the operator says, "open the 
> > panel,
> > there's a number displayed, what does it say?" and you blindly say "37" and
> > they go to an exact panel in an exact room and work backwards from there
> > instead of combing the entire elevator system.
> 
> but that is how you reproduce the bug

Actually that's more like an error code ("Experienced error 107" "Error 404
Object Not Found" etc).  Which is debugging information.

> 
> No you get almost no more information about the problem if you get a bug 
> report
> with just where it crashes, even GCC gets those because people don't read
> instructions.

hey when I've reported gcc bugs, gcc was complaining that it failed to
spill/fill a register or something and gave me the file it was trying to use. 
I passed it a switch to keep the preprocessed output, and attached that to the
bug, and you guys figured out what the problem was.

I would have got as far as saying "Internal compiler error" if it died with
"ICE failure to spill/fill.  Please report."  As it stands it at least was able
to tell me what file it was trying to compile.  :)


-- 


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

[Bug fortran/28122] Undocumented gfortran options

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert 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-07-11 07:57:10
   date||


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

[Bug fortran/25270] testcases fail with a type mismatch

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2006-07-11 07:59 
---
Closing.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

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

[bangerth at dealii dot org]

--- Comment #3 from bangerth at dealii dot org  2006-07-11 08:29 ---
As usual, a reduced (or at least smaller than 51,000 lines) testcase would be
supremely helpful...

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[schwab at suse dot de]

--- Comment #8 from schwab at suse dot de  2006-07-11 08:44 ---
This is now causing bootstrap to fail.


-- 


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker


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

[Bug fortran/28335] New: flush() / write() statement on closed units - error?

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

The Fortran 2003 standard declares:
"Every input/output statement except an OPEN, CLOSE, INQUIRE, or WAIT statement
shall refer to a unit that is connected to a file"

gfortran does not give a run-time error. However, I don't know whether one
should enforce the standard (and thus do this check).

program test
  write(*,*) 'Hello'
  flush(6) ! preconnected unit (stdout)
  flush(99)! preconnected unit
 ! flush()  ! invalid
  close(88) ! close preconnected unit 
  close(88) ! close once more
  ! wait(88) ! not supported by gfortran
  flush(88) ! invalid<
  write(88,*) 'This should also produce an error' !<<
end program test

Expected: Like NAG f95 (or g95)
 Hello
Unit 88 is not connected
Program terminated by fatal I/O error
In TEST, line 9 of flush.f90


-- 
   Summary: flush() / write() statement on closed units - error?
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[fnf at specifix dot com]

--- Comment #9 from fnf at specifix dot com  2006-07-11 09:08 ---
Subject: Re:  [4.2 regression] ICE in tree_int_cst_sgn

On Tuesday 11 July 2006 04:44, schwab at suse dot de wrote:
> This is now causing bootstrap to fail.

I'm currently configuring with --disable-libstdcxx-pch to work around
the problem.


-- 


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

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

[reichelt at igpm dot rwth-aachen dot de]

--- Comment #8 from reichelt at igpm dot rwth-aachen dot de  2006-07-11 
09:15 ---
Subject: Re:  [4.0/4.1 regression] ICE with struct definition in
 argument of template function

On 10 Jul, sje at cup dot hp dot com wrote:
> 
> 
> --- Comment #7 from sje at cup dot hp dot com  2006-07-10 20:46 ---
> I have checked in a patch for ToT and on the 4.1 branch.  My inclination is to
> not fix this on the 4.0 branch because the patch doesn't apply automatically. 
> The same change is probably needed somewhere else for 4.0, but I don't think 
> it
> is worth the trouble to find out where.

Well, with some trivial changes (whitespace, different number of
parameters for pushdecl_with_scope) the patch applies to the 4.0 branch:

===
--- gcc/gcc/cp/name-lookup.c(revision 115324)
+++ gcc/gcc/cp/name-lookup.c(working copy)
@@ -4666,7 +4666,11 @@ pushtag (tree name, tree type, tag_scope
pushdecl_class_level (decl);
}
  else if (b->kind != sk_template_parms)
-   decl = pushdecl_with_scope (decl, b);
+   {
+ decl = pushdecl_with_scope (decl, b);
+ if (decl == error_mark_node)
+   POP_TIMEVAR_AND_RETURN (TV_NAME_LOOKUP, decl);
+   }

  /* FIXME what if it gets a name from typedef?  */
  if (ANON_AGGRNAME_P (name))
===

Would you mind testing this on the 4.0 branch? Or should I do that?

> Should I close this out as  fixed in 4.1.2?


-- 


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

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

[reichelt at gcc dot gnu dot org]

--- Comment #9 from reichelt at gcc dot gnu dot org  2006-07-11 09:20 
---
Also fixed on the 4.1 branch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/28336] New: Cofiguration Options creates erroneous path in AVR GCC window

[rafurer at hawaii dot rr dot com]

July 10, 2006
Bug Report

Aloha from Honolulu,
The version info is at the end of this.  I'm not sure which program has the
bug; AVR GCC or AVR Studio 4.  Let me explain:

I'm using AVR Studio 4 and making the project in AVR GCC.  My OS is Windows XP
so all my directory slashes are backwards "\".  I use the Project Configuration
Options to set up my Include & Library file paths, so I didn't need an external
makefile.  The Configuration Options uses a graphic tree to show the path
chosen.  There seems no way to edit it manually.  The program compiled and
worked correctly.  My complaint is that I discovered an error in the file paths
when I tried to look at some of the files under External Dependencies in the
AVR GCC Project Window.  None would open.  Clicking on File Properties created
this Error message in the Messages Window:

gcc plug-in: C:AVR_Libcavrinclude\util\delay.h contains an invalid path.
gcc plug-in: C:AVR_Libcavrinclude\avr\io.h contains an invalid path.

The correct paths are:
C:AVR_Libc\avr\include\util\delay.h
C:AVR_Libc\avr\include\avr\io.h

As it happens both of these files are in sub-directories of
AVR_Libc\avr\include and the include statements in the program code use a
forward slash:
#include 
#include 

So I can see that where the backward slashes were used, they are ignored, but
the forward slashes are acknowledged.

I am afraid this is a bug in the program, but whether in AVR GCC or AVR Studio
I don't know.  I think if I could enter the path using forward slashes, into
the Configuration Options, there would be no error.  But I haven't found a way
to do that.

I hope this contributes to the further improvement/development of these
programs as I enjoy working with them.

Thank You,
Roger Furer
[EMAIL PROTECTED]

Here is version info from AVR STudio 4:
AVR Studio  4.12.462  Service Pack 1
GUI Version 4, 12, 0, 462
AVR Simulator   1, 0, 1, 6
ATMEGA169   257

Operating System
Major   5
Minor   1
PlatformID  2
Build   2600
Service Pack 2

Plugins:

AvrLcdPlugin1, 0, 0, 13
AvrPluginAvrAsmObject   1, 0, 0, 43
AvrPluginavrgccplugin   1, 0, 0, 5

I don't know where to find the info for AVR GCC.  I'm using WinAVR (20060421)
There is an avr-gcc-3.4.6 in the \bin directory (also an avr-gcc.exe) I don't
know what AVR Studio is using.

AVRLibc is 1.4.4

My OS is Windows XP Pro, version 2002, Service Pack 2.


-- 
   Summary: Cofiguration Options creates erroneous path in AVR GCC
window
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rafurer at hawaii dot rr dot com


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

[Bug c++/28337] New: [4.0/4.1/4.2 regression] ICE with string literals in templates

[reichelt at gcc dot gnu dot org]

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

==
template void foo()
{
  (0 ? "" : "X")+1;
}
==

bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: in fold_convert, at fold-const.c:2018
Please submit a full bug report, [etc.]

Without the template or if both string literals have the same length,
the code compiles fine.


-- 
   Summary: [4.0/4.1/4.2 regression] ICE with string literals in
templates
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-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=28337

[Bug c++/28337] [4.0/4.1/4.2 regression] ICE with string literals in templates

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

[Bug c++/28338] New: [4.0/4.1/4.2 regression] ICE/rejects-valid with references

[reichelt at gcc dot gnu dot org]

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

===
void foo()
{
  { static const int& i = 0; }
  { static const int& i = 0; }
}
===

bug.cc:4: error: redefinition of 'int _ZGRZ3foovE1i'
bug.cc:3: error: 'int _ZGRZ3foovE1i' previously declared here
bug.cc: In function 'void foo()':
bug.cc:4: internal compiler error: in layout_decl, at stor-layout.c:305
Please submit a full bug report, [etc.]

In addition the error message before the ICE is bogus, since the code
is valid. The error message was introduced in GCC 3.1.


-- 
   Summary: [4.0/4.1/4.2 regression] ICE/rejects-valid with
references
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, rejects-valid, 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=28338

[Bug c++/28338] [4.0/4.1/4.2 regression] ICE/rejects-valid with references

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

[Bug other/28336] Cofiguration Options creates erroneous path in AVR GCC window

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-11 10:51 ---
What happens if you use "\\" instead of "\" ?  From the sound of it, \ is being
recongized as the escape character?

Also this does not sound related to GCC if you are using an IDE.  
What happens if you invoke GCC directly?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |other


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

[Bug ada/28305] GNAT bug when inlining instance of a generic subprogram

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2006-07-11 11:03 ---
Confirmed on 4.0, 4.1 releases and HEAD.

gcc -c -gnatN test.ads

+===GNAT BUG DETECTED==+
| 4.0.3 (x86_64-unknown-linux-gnu) Program_Error sinput.adb:404 explicit raise|
| Error detected at a.adb:2:1 [test.ads:5:1]   |

+===GNAT BUG DETECTED==+
| 4.1.1 (x86_64-unknown-linux-gnu) Program_Error sinput.adb:404 explicit raise|
| Error detected at a.adb:2:1 [test.ads:5:1]   |

+===GNAT BUG DETECTED==+
| 4.2.0 20060627 (experimental) (x86_64-unknown-linux-gnu) Program_Error
sinput.adb:404 explicit raise|
| Error detected at a.adb:2:1 [test.ads:5:1]   |


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-07-11 11:03:48
   date||


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

[Bug c++/28338] [4.0/4.1/4.2 regression] ICE/rejects-valid with references

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-11 11:19 ---
>From the look of it, someone forgets to have an unique identifier for the
temporary variables (for references).  Right now it is semi unique but only to
the other functions.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-07-11 11:19:00
   date||


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

[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2006-07-11 11:21 ---
Subject: Bug 28277

Author: paolo
Date: Tue Jul 11 11:21:38 2006
New Revision: 115332

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115332
Log:
2006-07-11  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/28277 (partial: collate bits)
* include/bits/locale_facets.tcc (collate<>::do_transform(
const _CharT*, const _CharT*)): Avoid __builtin_alloca with no
limit; also avoid multiple calls (in a loop).
* testsuite/22_locale/collate/transform/char/28277.cc: New.
* testsuite/22_locale/collate/transform/wchar_t/28277.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/22_locale/collate/transform/char/28277.cc
trunk/libstdc++-v3/testsuite/22_locale/collate/transform/wchar_t/28277.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/locale_facets.tcc


-- 


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|blocker


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[pinskia at gcc dot gnu dot org]

-- 

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-07-11 11:56:56
   date||


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2006-07-11 12:04 
---
I am going to mark this as blocking PR 28217 though it does not officially, but
fixing either one will not fix the bootstrap.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||28217
  nThis||
   Keywords|build   |


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

[Bug fortran/28339] New: gfortran misses a record from a format statement

[mathewc at nag dot co dot uk]

A straight gfortran applied to the code

  PROGRAM MAIN
C .. Local Scalars ..
  INTEGER  I
C .. Local Arrays ..
  CHARACTER*8  REC(3)
C .. Executable Statements ..
C
  WRITE (REC,FMT=9)
C
  DO 20 I = 1, 3
 WRITE (*,FMT=*) REC(I)
   20 CONTINUE
C
9 FORMAT ('12345678',/'Record2',/'Record3')
  END

results in REC(1) containing '12345678', in REC(2) containing 'Record3', and in
REC(3) containing garbage.


-- 
   Summary: gfortran misses a record from a format statement
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathewc at nag dot co dot uk


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

[Bug libgcj/28340] New: gij ignores -Djava.security.manager

[gbenson at redhat dot com]

gij ignores -Djava.security.manager.  The reason for this is that the code to
handle it has not been merged from Classpath's java.lang.ClassLoader.


-- 
   Summary: gij ignores -Djava.security.manager
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gbenson at redhat dot com
OtherBugsDependingO 13603
 nThis:


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[gerald at pfeifer dot com]

--- Comment #17 from gerald at pfeifer dot com  2006-07-11 12:31 ---
i386-unknown-freebsd5.4 is also broken.


-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[pcarlini at suse dot de]

--- Comment #18 from pcarlini at suse dot de  2006-07-11 12:54 ---
Created an attachment (id=11858)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11858&action=view)
Please test!


-- 


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[pcarlini at suse dot de]

--- Comment #19 from pcarlini at suse dot de  2006-07-11 12:55 ---
Created an attachment (id=11859)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11859&action=view)
... and in case commit!


-- 


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[pcarlini at suse dot de]

--- Comment #20 from pcarlini at suse dot de  2006-07-11 12:56 ---
People affected by the breakage please carefully test the attached and, in
case, commit: I'm going away for a few hours... Thanks!


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[dje at gcc dot gnu dot org]

--- Comment #10 from dje at gcc dot gnu dot org  2006-07-11 13:28 ---
This now causes bootstrap failure on primary platforms.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org
   Priority|P3  |P1


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

[Bug c++/28341] New: [4.0/4.1/4.2 regression] ICE with references as template parameters

[reichelt at gcc dot gnu dot org]

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

=
template struct A {};

template struct B
{
  A a;
};

B b;
=

bug.cc: In instantiation of 'B':
bug.cc:8:   instantiated from here
bug.cc:5: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'indirect_ref'  in decl_linkage, at
cp/tree.c:2191
Please submit a full bug report, [etc.]

Before GCC 4.0.0 the following (not too helpful, if not bogus) error
message was issued:

bug.cc: In instantiation of `B':
bug.cc:8:   instantiated from here
bug.cc:5: error: `0' is not a valid template argument


-- 
   Summary: [4.0/4.1/4.2 regression] ICE with references as template
parameters
   Product: gcc
   Version: 4.2.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=28341

[Bug c++/28341] [4.0/4.1/4.2 regression] ICE with references as template parameters

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

[Bug tree-optimization/28162] [4.2 Regression] ICE in set_value_range, at tree-vrp.c:157

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2006-07-11 13:57 ---
Subject: Bug 28162

Author: rguenth
Date: Tue Jul 11 13:57:05 2006
New Revision: 115333

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

PR tree-optimization/28162
* fold-const.c (fold_binary): For (-A) * (-B) -> A * B
make sure to convert the operands to the correct type.

* gcc.dg/pr28162.c: New testcase.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr28162.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=28162

[Bug fortran/28339] gfortran misses a record from a format statement

[mathewc at nag dot co dot uk]

--- Comment #1 from mathewc at nag dot co dot uk  2006-07-11 14:10 ---
Apologies, as I should have added 
%gfortran -v
%Using built-in specs.
%Target: x86_64-unknown-linux-gnu
%Configured with: ./configure --enable-languages=c,fortran
%--prefix=/opt/gfortran/irun : (reconfigured) ./configure
%--prefix=/opt/gfortran/irun --enable-languages=c,fortran
%Thread model: posix
%gcc version 4.2.0 20060524 (experimental)


-- 


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

[Bug target/28342] New: undefined symbol [local label] for goto from nested function [SPARC]

[markosc at interia dot pl]

If there are two goto's that exit from nested functions and go to the same
label in main function, gcc generates references to two different labels, but
generates only one label to jump to. Result is undefined symbol and linking
error. This happens on both SPARC and SPARC64, both -O0 and -O3. However, x86
version works fine.

$ cat xb.c
int bar();

extern int en;

int foo ( ) {
__label__ err;
int res = 0;
void e1 ( ) {
res = -1;
en = 1;
goto err;
}
void e2 ( ) {
res = -1;
en = 2;
goto err;
}
while (1) {
switch (bar()) {
case 1: 
e1();
case 2: 
e2();
case 3: 
goto breakw;
case 4: 
res++;
}
continue;
breakw:
break;
}
err:
return res;
}
$ sparc64-elf64-linux-gcc -m32 -c xb.c -o xb.o
$ sparc64-elf64-linux-nm xb.o
 U bar
011c t e1.1118
00d8 t e2.1120
 U en
 T foo
 U .LL17

The problem also happens [though with different label name] for -m64 and/or
-O3.

The workaround is to reduce number of outside goto's per target label to 1,
either by throwing some goto's away, or declaring multiple labels in the target
place, having only one goto to each of them.


-- 
   Summary: undefined symbol [local label] for goto from nested
function [SPARC]
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markosc at interia dot pl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sparc64-elf64-linux-gnu


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

[Bug other/28336] Cofiguration Options creates erroneous path in AVR GCC window

[eweddington at cso dot atmel dot com]

--- Comment #2 from eweddington at cso dot atmel dot com  2006-07-11 14:15 
---
"My complaint is that I discovered an error in the file paths
when I tried to look at some of the files under External Dependencies in the
AVR GCC Project Window.  None would open.  Clicking on File Properties created
this Error message in the Messages Window:

gcc plug-in: C:AVR_Libcavrinclude\util\delay.h contains an invalid path.
gcc plug-in: C:AVR_Libcavrinclude\avr\io.h contains an invalid path."

This is a problem in AVR Studio and not in the WinAVR distribution of AVR GCC.

I would strongly suggest that you try AVR Studio 4.12 Service Pack 2 (at a
minimum): 
This is known to work with WinAVR 20060421. If you continue to have problems in
AVR Studio, then please conatact the AVR group in Atmel (see email address
within AVR Studio Help).

GCC Bugmasters: Please close this bug as invalid


-- 

eweddington at cso dot atmel dot com changed:

   What|Removed |Added

 CC||eweddington at cso dot atmel
   ||dot com


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

[Bug fortran/20903] types shouldn't propagate into interfaces

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2006-07-11 14:20 ---
Subject: Bug number PR20903

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-07/msg00459.html


-- 


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

[Bug c++/28343] New: [4.0/4.1/4.2 regression] ICE with invalid asm specifier for struct member

[reichelt at gcc dot gnu dot org]

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

=
struct A
{
  static int i __asm__(int);
};
=

bug.cc:3: error: expected string-literal before 'int'
bug.cc:3: error: expected `(' before 'int'
bug.cc:3: internal compiler error: tree check: expected string_cst, have
error_mark in grokfield, at cp/decl2.c:841
Please submit a full bug report, [etc.]

Testing a patch.


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


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

[Bug fortran/20893] unconditional use of optional argument not detected

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2006-07-11 14:35 ---
Subject: Bug number PR20893

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-07/msg00461.html


-- 


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

[Bug fortran/20893] unconditional use of optional argument not detected

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-07-11 14:42 ---
Patch submitted to the list


-- 

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


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

[Bug fortran/20903] types shouldn't propagate into interfaces

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2006-07-11 14:42 ---
Patch submitted


-- 

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


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

Bug in libstdc++ documentation of std::set

[Manuel Günther]

Hello,

I found a bug in the documentation of std::set. The begin()-function is said to 
return a read/write-iterator, but it doesn't. The iterator of the std::set is 
always a const_iterator. I would be glad, if you could fix this documentation 
error.

Sincerly

Manuel Günther
Institut für Neuroinformatik
Ruhr-Universität Bochum

[Bug fortran/20878] Interface body cannot access named entities by host association

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2006-07-11 15:04 ---
This is fixed by the patch that I have just submitted for PR20903

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


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

[Bug libstdc++/28344] New: [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[gcc-bugzilla at gcc dot gnu dot org]

libstdc++ fails to bootstrap on Tru64 UNIX as of 20060710:

/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/src/.libs
-B/vol/gcc/share/alpha-dec-osf4.0f/bin/ -B/vol/gcc/share/alpha-dec-osf4.0f/lib/
-isystem /vol/gcc/share/alpha-dec-osf4.0f/include -isystem
/vol/gcc/share/alpha-dec-osf4.0f/sys-include -Winvalid-pch -Wno-deprecated -x
c++-header -g -O2  -mieee
-I/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include/alpha-dec-osf4.0f
-I/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include
-I/vol/gccsrc/src/gcc/libstdc++-v3/libsupc++ -O2 -g
/vol/gccsrc/src/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h -o
alpha-dec-osf4.0f/bits/stdtr1c++.h.gch/O2g.gch
/vol/gccsrc/src/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h:30:25:
warning:
/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include/alpha-dec-osf4.0f/bits/stdc++.h.gch/O0g.gch:
not used because `__NO_INLINE__' not defined
/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include/tr1/random:1983:
error: expected ',' or '...' before numeric constant

This happens because tr1/random uses __alpha

  template
class gamma_distribution
{
[...]
  explicit
  gamma_distribution(const result_type& __alpha = result_type(1))
  : _M_alpha(__alpha)

which is predefined as 1 on Tru64 UNIX (and probably other alpha systems).

This was introduced by this patch:

2006-07-06  Paolo Carlini  <[EMAIL PROTECTED]>

* include/tr1/random (class gamma_distribution<>): Add.

Environment:
System: OSF1 haydn V4.0 1229 alpha
Machine: alpha

host: alpha-dec-osf4.0f
build: alpha-dec-osf4.0f
target: alpha-dec-osf4.0f
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build
alpha-dec-osf4.0f --target alpha-dec-osf4.0f
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2006-07-11 
15:29 ---
Fix:
This patch works around this issue:

Index: libstdc++-v3/include/tr1/random
===
--- libstdc++-v3/include/tr1/random (revision 115313)
+++ libstdc++-v3/include/tr1/random (working copy)
@@ -46,6 +46,8 @@
 #include 
 #include 

+#undef __alpha
+
 namespace std
 {
 _GLIBCXX_BEGIN_NAMESPACE(tr1)


-- 
   Summary: [4.2 Regression] Use of __alpha in tr1/random breaks
Tru64 UNIX bootstrap
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug libstdc++/28344] [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2006-07-11 15:30 ---
Paolo, your patch introduced this.

  Rainer


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pcarlini at suse dot de


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

[Bug c++/28345] New: static const "class" initialisation causes core dump

[john dot spelis at 3dlabs dot com]

A declaration
   static const Bad constBad = {
  ...
}
causes a core dump, fixed by removing the "const" keyword.

Example source file "b.cxx"

#include 

class Base {
public:
};

class Derived : public Base {
public:
   int a, b, c, d;
};

class Bad {
public:
   int Base::*mpField0;
   int Base::*mpField1;
};

class Good {
public:
   int Derived::*mpField0;
   int Derived::*mpField1;
};

int main( int argc, char *argv[] )
{
   static const Goodgood = {
 (int (Base::*)) &Derived::b,
 (int (Base::*)) &Derived::c
   };

   printf( "good.mpField0 = %d\n", good.mpField0 );
   printf( "good.mpField1 = %d\n", good.mpField1 );

   static Bad   bad = {
 (int (Base::*)) &Derived::b,
 (int (Base::*)) &Derived::c
   };

   printf( "bad.mpField0 = %d\n", bad.mpField0 );
   printf( "bad.mpField1 = %d\n", bad.mpField1 );

   // This initialisation generates a CORE dump!
   static const Bad constBad = {
 (int (Base::*)) &Derived::b,
 (int (Base::*)) &Derived::c
   };

   printf( "constBad.mpField0 = %d\n", constBad.mpField0 );
   printf( "constBad.mpField1 = %d\n", constBad.mpField1 );

   return 0;
}


 g++ -v -save-temps -o b b.cxx
===
Reading specs from /opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: /homes/spelis/dopt/gnu/gcc-3.4.1/configure
--prefix=/opt/s2tools/native
Thread model: posix
gcc version 3.4.1
 /opt/s2tools/native/libexec/gcc/i686-pc-linux-gnu/3.4.1/cc1plus -E -quiet -v
-D_GNU_SOURCE b.cxx -mtune=pentiumpro -o b.ii
ignoring nonexistent directory
"/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../include/c++/3.4.1

/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../include/c++/3.4.1/i686-pc-linux-gnu

/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../include/c++/3.4.1/backward
 /usr/local/include
 /opt/s2tools/native/include
 /opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/include
 /usr/include
End of search list.
 /opt/s2tools/native/libexec/gcc/i686-pc-linux-gnu/3.4.1/cc1plus -fpreprocessed
b.ii -quiet -dumpbase b.cxx -mtune=pentiumpro -auxbase b -version -o b.s
GNU C++ version 3.4.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-49).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o b.o b.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
 /opt/s2tools/native/libexec/gcc/i686-pc-linux-gnu/3.4.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o b
/usr/lib/crt1.o /usr/lib/crti.o
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/crtbegin.o
-L/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1
-L/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/lib
-L/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../.. b.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/crtend.o /usr/lib/crtn.o


-- 
   Summary: static const "class" initialisation causes core dump
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
 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=28345

[Bug fortran/25097] Component of optional argument allowed as arg. to PRESENT

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2006-07-11 16:10 ---
Subject: Bug number PR25097

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-07/msg00476.html


-- 


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

[Bug c++/28346] New: [4.0/4.1/4.2 regression] ICE creating pointer-to-reference-member

[reichelt at gcc dot gnu dot org]

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

=
template struct A
{
int& i;
A();
~A() { &A::i; }
};

A<0> a;
=

bug.cc: In destructor 'A< >::~A() [with int  = 0]':
bug.cc:9:   instantiated from here
bug.cc:6: internal compiler error: in gimplify_expr, at gimplify.c:5763
Please submit a full bug report, [etc.]

Before we got the error message:

bug.cc: In destructor `void A< >::A() [with int  = 0]':
bug.cc:9:   instantiated from here
bug.cc:6: cannot create pointer to reference member `A<0>::i'


-- 
   Summary: [4.0/4.1/4.2 regression] ICE creating pointer-to-
reference-member
   Product: gcc
   Version: 4.2.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=28346

[Bug c++/28346] [4.0/4.1/4.2 regression] ICE creating pointer-to-reference-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=28346

[Bug tree-optimization/19505] [4.0/4.1/4.2 Regression] java bytecode to native ICE in remove_unreachable_regions

[aph at gcc dot gnu dot org]

-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aph at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-01 04:41:11 |2006-07-11 16:16:04
   date||


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

[Bug c++/28347] New: [4.1/4.2 regression] ICE on typedef with initialization

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE on mainline and the 4.1
branch (introduced after GCC 4.1.1):

=
template void foo()
{
typedef int i = 0;
}
=

bug.cc: In function 'void foo()':
bug.cc:3: error: typedef 'i' is initialized (use __typeof__ instead)
bug.cc:3: internal compiler error: tree check: expected var_decl, have
type_decl in cp_finish_decl, at cp/decl.c:5080
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2 regression] ICE on typedef with initialization
   Product: gcc
   Version: 4.2.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=28347

[Bug c++/28347] [4.1/4.2 regression] ICE on typedef with initialization

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

[Bug c++/28348] New: ICE trying to gimplify invalid code

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since at least GCC 2.95.3:

=
namespace N
{
   struct A {};
   typedef void foo(A);
}

template void bar() { T t; foo(t); }

template void bar();
=

gimplification failed:
foo >
QI
size 
unit size 
align 8 symtab 0 alias set -1
arg-types 
chain >>
pointer_to_this >
used VOID file bug.cc line 4
align 1 context 
result 
QI size  unit size 
align 8 symtab 0 alias set -1 arg-types >>
bug.cc: In function 'void bar() [with T = N::A]':
bug.cc:9:   instantiated from here
bug.cc:7: internal compiler error: gimplification failed
Please submit a full bug report, [etc.]


-- 
   Summary: ICE trying to gimplify invalid code
   Product: gcc
   Version: 4.2.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=28348

[Bug c++/28349] New: [4.0/4.1/4.2 regression] ICE with va_arg

[reichelt at gcc dot gnu dot org]

The following valid (though questionable) code snippet triggers an ICE
since GCC 3.1:

=
#include 

void foo(int, ...)
{
va_list va;
int i;
i = va_arg(va, int&);
}
=

bug.cc: In function 'void foo(int, ...)':
bug.cc:7: warning: cannot receive objects of non-POD type 'int&' through '...';
call will abort at runtime
bug.cc:7: internal compiler error: in build_modify_expr, at cp/typeck.c:5643
Please submit a full bug report, [etc.]


-- 
   Summary: [4.0/4.1/4.2 regression] ICE with va_arg
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-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=28349

[Bug c++/28349] [4.0/4.1/4.2 regression] ICE with va_arg

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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[bkoz at gcc dot gnu dot org]

--- Comment #21 from bkoz at gcc dot gnu dot org  2006-07-11 16:50 ---

Huh. Sorry!

I'm checking in Paolo's patch.

-benjamin


-- 


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

[Bug target/19115] long double should be changed over to 128bit by default

[dje at gcc dot gnu dot org]

--- Comment #8 from dje at gcc dot gnu dot org  2006-07-11 16:59 ---
Switching actually causes problems on AIX due to AIX math.h header enabling
additional macros with types that conflict with GCC.


-- 


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

[Bug other/28251] dumped addresses makes diffing dumps unusable

[amylaar at gcc dot gnu dot org]

--- Comment #4 from amylaar at gcc dot gnu dot org  2006-07-11 17:23 ---
Created an attachment (id=11860)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11860&action=view)
patch with test case & unroller fix

I've added a testcase, and it showed failures due to unstable loop unrolling.
It looks like this should be trivial to fix by hashing on insn uids rather
than insn pointers.  I'm currently testing this patch.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #11819|0   |1
is obsolete||


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

[Bug c++/28051] [4.0/4.1 regression] ICE on invalid conversion operator

[lmillward at gcc dot gnu dot org]

--- Comment #6 from lmillward at gcc dot gnu dot org  2006-07-11 17:25 
---
Subject: Bug 28051

Author: lmillward
Date: Tue Jul 11 17:25:01 2006
New Revision: 115347

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115347
Log:
PR c++/28051
   * mangle.c (mangle_conv_op_name_for_type): Check for
   invalid types.
   * name-lookup.c (push_class_level_binding): Robustify.
   (do_class_using_decl): Return early if name is
   error_mark_node.


Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/using13.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/mangle.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/28051] [4.0/4.1 regression] ICE on invalid conversion operator

[lmillward at gcc dot gnu dot org]

--- Comment #7 from lmillward at gcc dot gnu dot org  2006-07-11 17:37 
---
Subject: Bug 28051

Author: lmillward
Date: Tue Jul 11 17:37:31 2006
New Revision: 115352

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115352
Log:
PR c++/28051
   * mangle.c (mangle_conv_op_name_for_type): Check for
   invalid types.
   * name-lookup.c (push_class_level_binding): Robustify.
   (do_class_using_decl): Return early if name is
   error_mark_node.


Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/using10.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/mangle.c
branches/gcc-4_0-branch/gcc/cp/name-lookup.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/28051] [4.0/4.1 regression] ICE on invalid conversion operator

[lmillward at gcc dot gnu dot org]

--- Comment #8 from lmillward at gcc dot gnu dot org  2006-07-11 17:38 
---
Fixed in 4.1.2 and 4.0.4


-- 

lmillward at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[bkoz at gcc dot gnu dot org]

--- Comment #22 from bkoz at gcc dot gnu dot org  2006-07-11 17:48 ---
Subject: Bug 28290

Author: bkoz
Date: Tue Jul 11 17:48:10 2006
New Revision: 115354

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115354
Log:
2006-07-11  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/28290
* include/ext/codecvt_specializations.h: Fix, adding missing
includes and guards.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/codecvt_specializations.h


-- 


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

[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.

[ro at gcc dot gnu dot org]

--- Comment #19 from ro at gcc dot gnu dot org  2006-07-11 17:52 ---
It is quite possible that this is very dependent on the specific IRIX 6.5
revision used: in IRIX 6.5.18 and up, ISO C99 support got introduced, which
certainly affects this.

Which revision (uname -R) do you run?

  Rainer


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org


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

[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.

[martinol at nrlssc dot navy dot mil]

--- Comment #20 from martinol at nrlssc dot navy dot mil  2006-07-11 18:01 
---
this machine is: 6.5 6.5.17m


-- 


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

[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.

[ro at techfak dot uni-bielefeld dot de]

--- Comment #21 from ro at techfak dot uni-bielefeld dot de  2006-07-11 
18:04 ---
Subject: Re:  GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0
worked.

martinol at nrlssc dot navy dot mil writes:

> this machine is: 6.5 6.5.17m

This most likely explains the difference: this is before C99 support was
introduced, and obviously most testers use relatively recent IRIX
releases.  I don't have an pre-6.5.18 machine myself, so the only chance is
probably to run the failing tests through gcc -g3 -save-temps and find out
why exactly they fail.

Rainer


-- 


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

[Bug libffi/28313] libffi has not been ported to mips64-linux-gnu

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2006-07-11 18:27 ---
This affects IRIX 6 as well (i.e. the N32 and N64 ABIs).

  Rainer


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org


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

[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2006-07-11 18:31 ---
I've posted a patch to fix this.


-- 


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

[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option

[ro at techfak dot uni-bielefeld dot de]

--- Comment #2 from ro at techfak dot uni-bielefeld dot de  2006-07-11 
18:50 ---
Subject: Re:   New: boostrapping with gcc fails with unrecognized linker option

"multix at gmail dot com" <[EMAIL PROTECTED]> writes:

> I boostrapped using gcc 3.3 from sgi, usning as configure option
> ../gcc-4.1.1/configure --with-as=/usr/local/bin/as
> --enable-languages=c,c++,objc
> and as make command
> gmake CFLAGS='-O' LIBCFLAGS='-O2' LIBCXXFLAGS='-O2 -fno-implicit-templates'
> bootstrap
> 
> bootstrapping fails with:
[...]
> /usr/local/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4'
> /usr/local/mips-sgi-irix6.5/bin/ld: use the --help option for usage 
> information
> collect2: ld returned 1 exit status

The problem is that you are have GNU ld installed in a place gcc searches
by default, but didn't configure with --with-gnu-ld.

Rainer


-- 


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

[Bug java/28329] [ecj] gcj leaves .jar and .zip files in /tmp

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2006-07-11 19:28 ---
%U implies %d

I debugged today and set a breakpoint in delete_if_ordinary.
I get this:

Breakpoint 1, delete_if_ordinary (
name=0x9af48c0 "-fzip-dependency=/tmp/ccQurYQS.zip")
at ../../trunk/gcc/gcc.c:2349

So the problem seems to be that gcc.c assumes that %U is only used
as a standalone argument.  This makes sense, so the fix, I think, is
to change the specs to pass this argument standalone somewhere.


-- 

tromey 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-07-11 19:28:31
   date||


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

[Bug c++/25357] [4.0 Regression] ICE in typeid

[dtemirbulatov at gmail dot com]

--- Comment #9 from dtemirbulatov at gmail dot com  2006-07-11 19:59 ---
fix posted here http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00144.html


-- 


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

[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.

[ebotcazou at gcc dot gnu dot org]

--- Comment #22 from ebotcazou at gcc dot gnu dot org  2006-07-11 20:01 
---
> This most likely explains the difference: this is before C99 support was
> introduced, and obviously most testers use relatively recent IRIX
> releases.

Mine is 6.5 6.5.26m.


-- 


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

[Bug other/28336] Cofiguration Options creates erroneous path in AVR GCC window

[rafurer at hawaii dot rr dot com]

--- Comment #3 from rafurer at hawaii dot rr dot com  2006-07-11 20:04 
---
Subject: Re:  Cofiguration Options creates erroneous path
 in AVR GCC window

Aloha,
Thanks for the tip.  I followed your advice and it did indeed 
correct the problem.  My files in External Dependencies have their 
proper path names.
Thank You,
Roger Furer


eweddington at cso dot atmel dot com wrote:
> --- Comment #2 from eweddington at cso dot atmel dot com  2006-07-11 
> 14:15 ---
> "My complaint is that I discovered an error in the file paths
> when I tried to look at some of the files under External Dependencies in the
> AVR GCC Project Window.  None would open.  Clicking on File Properties created
> this Error message in the Messages Window:
> 
> gcc plug-in: C:AVR_Libcavrinclude\util\delay.h contains an invalid path.
> gcc plug-in: C:AVR_Libcavrinclude\avr\io.h contains an invalid path."
> 
> This is a problem in AVR Studio and not in the WinAVR distribution of AVR GCC.
> 
> I would strongly suggest that you try AVR Studio 4.12 Service Pack 2 (at a
> minimum): 
> This is known to work with WinAVR 20060421. If you continue to have problems 
> in
> AVR Studio, then please conatact the AVR group in Atmel (see email address
> within AVR Studio Help).
> 
> GCC Bugmasters: Please close this bug as invalid
> 
> 


-- 


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

[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.

[ro at techfak dot uni-bielefeld dot de]

--- Comment #23 from ro at techfak dot uni-bielefeld dot de  2006-07-11 
20:06 ---
Subject: Re:  GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0
worked.

ebotcazou at gcc dot gnu dot org writes:

> Mine is 6.5 6.5.26m.

I'm running 6.5 6.5.28f.  Anything newer than 6.5.18 (or .19, I don't
really remember) shouldn't exhibit this failure.

Rainer


-- 


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

[Bug bootstrap/28326] [4.1 regression] profiledbootstrap will produce an ICE with "-mtune=power3 -mcpu=power3" in BOOT_CFLAGS

[markus at unixforces dot net]

--- Comment #3 from markus at unixforces dot net  2006-07-11 20:17 ---
I did some testing and this are the results:

gcc versions 3.4.6, 4.0.3 and 4.2-20060708 do all _not_ fail with
profiledbootstrap and "-mtune=power3 -mcpu=power3" in BOOT_CFLAGS.

which information do you need to get this fixed?


-- 

markus at unixforces dot net changed:

   What|Removed |Added

  Known to fail||4.1.1
  Known to work||3.4.6 4.0.3
Summary|[4.1/ICE] gcc-4.1.0 won't   |[4.1 regression]
   |compile on power3   |profiledbootstrap will
   ||produce an ICE with "-
   ||mtune=power3 -mcpu=power3"
   ||in BOOT_CFLAGS


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

[Bug other/28336] Cofiguration Options creates erroneous path in AVR GCC window

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-07-11 20:37 ---
Invalid as requested.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-07-11 20:39 ---
Can you try adding --with-gnu-as when configuring?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

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

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2006-07-11 20:56 ---
I am testing on the 4.0 branch now.


-- 


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

[Bug libstdc++/28344] [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[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
   Target Milestone|--- |4.2.0


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

[Bug middle-end/28342] undefined symbol [local label] for goto from nested function [SPARC]

[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|major   |normal
  Component|target  |middle-end


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

[Bug c++/28351] New: SIGSEGV rethrowing an exception with -m64 -static on ppc/linux

[sebor at roguewave dot com]

We're seeing the behavior below in 64-bit statically linked programs on
PowerPC/Linux (this has the same effect: gcc -m64 t.cpp -lsupc++). Here's
the stack trace, if it helps at all:

#0  0x100010e8 in .__cxa_get_globals_fast ()
#1  0x1d60 in .__cxa_end_catch ()
#2  0x1a98 in main () at t.cpp:10

$ cat t.cpp && gcc --version && g++ -m64 t.cpp -static && ./a.out 
void foo () { throw 0; }

int main ()
{
try {
try {
foo ();
}
catch (...) {
throw;
}
}
catch (...) {
return 0;
}

return 1;
} 
$ cat t.cpp && gcc --version && g++ -m64 t.cpp -static && ./a.out 
void foo () { throw 0; }

int main ()
{
try {
try {
foo ();
}
catch (...) {
throw;
}
}
catch (...) {
return 0;
}

return 1;
} 

gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Segmentation fault

gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Segmentation fault


-- 
   Summary: SIGSEGV rethrowing an exception with -m64 -static on
ppc/linux
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
 GCC build triplet: powerpc-suse-linux
  GCC host triplet: powerpc-suse-linux
GCC target triplet: powerpc-suse-linux


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

[Bug c++/28351] SIGSEGV rethrowing an exception with -m64 -static on ppc/linux

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-11 21:12 ---
I think this was a glibc bug with TLS.  What version of glibc you are using?

Also you should really report this to SUSE first as it is their distro.


-- 


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

[Bug other/28336] Cofiguration Options creates erroneous path in AVR GCC window

[rafurer at hawaii dot rr dot com]

--- Comment #5 from rafurer at hawaii dot rr dot com  2006-07-11 21:29 
---
Aloha,
Just to let you know, updating the service pack eliminated the problem.
Thank You,
Roger


-- 


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

[Bug libgcj/28352] New: Interpreter: Stack trace line numbers sometimes missing or incorrect

[mckinlay at redhat dot com]

When the following test case is built with gcj -C, the innermost frame is
missing from the stack trace:

public class Ex {
   void snafu( ) throws Exception {
 throw new Exception();
   }
   void bar( ) throws Exception {
 snafu( );
   }
   void foo( ) throws Exception {
 bar( );
   }
   public static void main( String[] args) throws Exception {
 new Ex( ).foo( );
  }
}


$ gij Ex
Exception in thread "main" java.lang.Exception
   at Ex.snafu(Ex.java)
   at Ex.bar(Ex.java:6)
   at Ex.foo(Ex.java:9)
   at Ex.main(Ex.java:12)

In addition, when built with a different bytecode compiler (ecj), the stack
trace is complete, but has off-by-one line number errors:

$ gij Ex
Exception in thread "main" java.lang.Exception
   at Ex.snafu(Ex.java:3)
   at Ex.bar(Ex.java:7)
   at Ex.foo(Ex.java:10)
   at Ex.main(Ex.java:13)


-- 
   Summary: Interpreter: Stack trace line numbers sometimes missing
or incorrect
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com


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

[Bug libgcj/28352] Interpreter: Stack trace line numbers sometimes missing or incorrect

[mckinlay at redhat dot com]

--- Comment #1 from mckinlay at redhat dot com  2006-07-11 21:32 ---
Correction: the description should read "the line number for the inner-most
frame is missing from the stack trace".


-- 


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

[Bug c++/28351] SIGSEGV rethrowing an exception with -m64 -static on ppc/linux

[sebor at roguewave dot com]

--- Comment #2 from sebor at roguewave dot com  2006-07-11 21:42 ---
Libc says it's 2.3.3 (20040412).


-- 


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

[Bug libstdc++/28344] [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2006-07-11 21:55 ---
Humpf, sorry! I will fix it in a moment. 


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-07-11 21:55:21
   date||


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

[Bug libstdc++/28344] [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2006-07-11 22:09 ---
Subject: Bug 28344

Author: paolo
Date: Tue Jul 11 22:08:56 2006
New Revision: 115355

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115355
Log:
2006-07-11  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/28344
* include/tr1/random (gamma_distribution<>::
gamma_distribution(const result_type&)): Don't use __alpha as
parameter name, a predefined macro on Alpha systems.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/random


-- 


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

[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)

[tromey at gcc dot gnu dot org]

-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-04-24 17:43:28 |2006-07-11 22:10:26
   date||


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

[Bug libstdc++/28344] [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2006-07-11 22:10 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.

[pcarlini at suse dot de]

--- Comment #24 from pcarlini at suse dot de  2006-07-11 22:23 ---
Thanks Rainer and Eric. Then, since we have a workaround in place for the issue
(--disable-wchar_t) and apparently it affects only very old ("broken" as far as
such features are concerned) releases of the OS, I'm inclined to close this PR
as WONTFIX. Any objections? I will go ahead in a few days...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||pcarlini at suse dot de


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

[Bug fortran/28353] New: ICE: Segmentation fault

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

gfortran -c mpi_bc_all.f
mpi_bc_all.F: In function 'mpi_bc_all':
mpi_bc_all.F:276: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

GNU Fortran 95 (GCC) 4.2.0 20060711 (experimental)


-- 
   Summary: ICE: Segmentation fault
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de


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

[Bug fortran/28353] ICE: Segmentation fault

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

--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de  
2006-07-11 23:01 ---
Created an attachment (id=11862)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11862&action=view)
Test file: mpi_bc_all.f


-- 


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

[Bug fortran/28353] ICE: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-07-12 00:00 ---
This file alone is not going to be able to reproduce this bug.
Can you attach mpif.h also?

INCLUDE 'mpif.h'


-- 


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

[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type

[pcarlini at suse dot de]

--- Comment #23 from pcarlini at suse dot de  2006-07-12 00:21 ---
Thanks Benjamin. FYI, I have just tweaked it back to my original version (if
c++config.h is not included first, _GLIBCXX_USE_ICONV is always found undefined
;)


-- 


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

[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2006-07-12 00:24 ---
The bug here is that Inflater needs an extra input byte in some situations.
I think ZipFile has to provide this byte; a patch to do this makes this
test case work again.  I need to investigate ZipInputStream and
GZIPInputStream, too, before committing.


-- 


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

[Bug libgcj/28352] Interpreter: Stack trace line numbers sometimes missing or incorrect

[rmathew at gcc dot gnu dot org]

--- Comment #2 from rmathew at gcc dot gnu dot org  2006-07-12 01:46 ---
Confirmed.


-- 

rmathew 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-07-12 01:46:30
   date||


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

[Bug fortran/28339] gfortran misses a record from a format statement

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2006-07-12 01:53 
---
This is curious.  I can confirm the behavior on my system here.  If the first
record is made one character less, "1234567", it appears to give a clean
result.

I will have to think about this one a little more.  I am in the middle of
another patch, but will get back to this after that.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-07-12 01:53:02
   date||


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

[Bug fortran/25828] [f2003] ACCESS='STREAM' io support

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2006-07-12 02:14 
---
I have the beginnings of a patch now with unformatted read and write working
and formatted write working.  Still need to do formatted read and checking of
all constraints.  It appears to me that this is progressing OK.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-20 11:22:11 |2006-07-12 02:14:27
   date||


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

[Bug libfortran/27704] Incorrect runtime error on multiple OPEN

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2006-07-12 02:16 
---
Fixed on 4.2 only.  If someone wants this on 4.1 let me know.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/27704] Incorrect runtime error on multiple OPEN

[jvdelisle at gcc dot gnu dot org]

-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.0


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

[Bug fortran/28339] gfortran misses a record from a format statement

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1


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