[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2008-08-08 07:50 ---
(In reply to comment #4)
> Interesting.  I may have a look into the CCP problem.
> 

Well, I think that we have pass_rebuild_cgraph_edges precisely because
passes like CCP are not trusted to update call graph correctly.  It is
not an elegant solution but might just work.

However, in order for it to work, gimple_call_fndecl() must be able to
find  the  declarations  (and  this  might also  be  problem  for  CCP
generated calls too).


-- 


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

[Bug libfortran/18985] opening unit 6 messes up print

[schilds at sun dot ac dot za]

--- Comment #8 from schilds at sun dot ac dot za  2008-08-08 08:31 ---
What does Fortran 2003 have to do with legacy mode? Nothing. So far as I know
the GCC compiler is at odds with Solaris, Intel, Vax, you name it. All of these
allowed you to touch unit 6 without affecting the print*, (or write(*,*))
statement. The behaviour is therefore both unexpected and difficult to track
down (not even a warning). 

This is a serious bug, make no mistake. It causes existing Fortran 77 code to
fail. It's wasted a lot of my time and, no doubt, a lot of other, good peoples'
too. The ubiquitousness of the print*, (or write(*,*)) statement makes fixing
this bug a priority.


-- 


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

[Bug c++/37057] New: 7 Internal Compiler Errors when compiling OpenFOAM-1.5

[jorn dot amundsen at ntnu dot no]

An attempt to build OpenFOAM 1.5 (www.opencfd.co.uk/openfoam/version1.5.html)
on
powerpc-ibm-aix5.3.0.0 resulted in 7 compiler internal errors (ICEs) with gcc
4.3.1 and 6 ICEs with gcc 4.2.0.

The 4.2.0 compiler suite is as downloaded from the IBM AIX RPM repository
(http://www-03.ibm.com/systems/p/os/aix/linux/toolbox/), while the 4.3.1 suite
is a rebuild with forward porting of the 4.2.0 patches.

At this time, only preprocessed files of the chemkinReader.C ICE is
provided. The 4.3.1 .ii file compiles w/o errors or warnings with gcc 4.3.0 on
a
x86_64 system. Similarly, as OF 1.5 builds on x86_64 with gcc 4.3, the other
ICEs should compile cleanly on this platform as well. Notice the difference in
size of the .s files between the 4.2 and 4.3 ICEs.

Any suggestions, patches and or development versions likely to reduce / remove
the ICEs are welcome. I have not checked if there are any common patterns
triggering the ICEs.

GCC431 ICEs
---
lnInclude/wrapper.cpp:320: internal compiler error: Segmentation fault
interpolation/surfaceInterpolation/limitedSchemes/vanAlbada/vanAlbada.C:36:
internal compiler error: Illegal instruction
lnInclude/Reaction.H:143: internal compiler error: Segmentation fault
chemistryReaders/chemkinReader/chemkinReader.C:230: internal compiler error:
Segmentation fault
RASModel/RASModel.C:205: internal compiler error: Segmentation fault
LESModel/LESModel.C:137: internal compiler error: Segmentation fault
lnInclude/ReactingCloud.C:101: internal compiler error: Segmentation fault
[lnInclude/Reaction.H: include from reaction/reactions/makeChemkinReactions.C]

Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.3.0.0
--target=powerpc-ibm-aix5.3.0.0 --build=powerpc-ibm-aix5.3.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-maix32' '-Daix' '-DDP' '-Wall'
'-Wno-strict-aliasing' '-Wextra' '-Wno-unused-parameter' '-Wold-style-cast'
'-DNoRepository' '-ftemplate-depth-40' '-IlnInclude' '-I.'
'-I/usr/local/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude'
'-I/usr/local/OpenFOAM/OpenFOAM-1.5/src/OSspecific/Unix/lnInclude'
'-shared-libgcc'
 /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/cc1plus -E -quiet -v
-IlnInclude -I. -I/usr/local/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude
-I/usr/local/OpenFOAM/OpenFOAM-1.5/src/OSspecific/Unix/lnInclude -D_ALL_SOURCE
-Daix -DDP -DNoRepository reaction/reactions/makeChemkinReactions.C -maix32
-Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast
-ftemplate-depth-40 -fpch-preprocess -o makeChemkinReactions.ii
ignoring nonexistent directory
"/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include-fixed"
ignoring nonexistent directory
"/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/../../../../powerpc-ibm-aix5.3.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
 lnInclude
 .
 /usr/local/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude
 /usr/local/OpenFOAM/OpenFOAM-1.5/src/OSspecific/Unix/lnInclude
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++

/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/powerpc-ibm-aix5.3.0.0
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/backward
 /usr/local/include
 /opt/freeware/include
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-maix32' '-Daix' '-DDP' '-Wall'
'-Wno-strict-aliasing' '-Wextra' '-Wno-unused-parameter' '-Wold-style-cast'
'-DNoRepository' '-ftemplate-depth-40' '-IlnInclude' '-I.'
'-I/usr/local/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude'
'-I/usr/local/OpenFOAM/OpenFOAM-1.5/src/OSspecific/Unix/lnInclude'
'-shared-libgcc'
 /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/cc1plus -fpreprocessed
makeChemkinReactions.ii -quiet -dumpbase makeChemkinReactions.C -maix32
-auxbase makeChemkinReactions -Wall -Wno-strict-aliasing -Wextra
-Wno-unused-parameter -Wold-style-cast -version -ftemplate-depth-40 -o
makeChemkinReactions.s
GNU C++ (GCC) version 4.3.1 (powerpc-ibm-aix5.3.0.0)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 75e8825e7e5e448ca4cc214b313b85d6
lnInclude/Reaction.H: In static member function 'static
Foam::autoPtr >
Foam::Reaction::addIstreamConstructorToTable::New(const
Foam::speciesTable&, const Foam::HashPtrTable&, Foam::Istream&) [with ReactionType =
Foam::NonEquilibriumReversibleReaction
> >, Foam::ArrheniusReactionRate>, ReactionThermo =
Foam::sutherlandTransport
> >]':
lnInclude/Reaction.H:143: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed sourc

[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5

[jorn dot amundsen at ntnu dot no]

--- Comment #1 from jorn dot amundsen at ntnu dot no  2008-08-08 08:48 
---
Created an attachment (id=16043)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16043&action=view)
g++ preprocessed file

g++ preprocessed file, ICE with powerpc-ibm-aix5.3.0.0 compiles cleanly with
x86_64-redhat-linux


-- 


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

[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5

[jorn dot amundsen at ntnu dot no]

--- Comment #2 from jorn dot amundsen at ntnu dot no  2008-08-08 08:53 
---
Created an attachment (id=16044)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16044&action=view)
makeChemkinReactions.C assembler output 

GCC 4.3.1 powerpc-ibm-aix5.3.0.0 assembler output from compiling
makeChemkinReactions.ii with -save-temps


-- 


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

[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5

[jorn dot amundsen at ntnu dot no]

--- Comment #3 from jorn dot amundsen at ntnu dot no  2008-08-08 09:01 
---
Created an attachment (id=16045)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16045&action=view)
g++ preprocessed file

GCC 4.2.0 powerpc-ibm-aix5.3.0.0 preprocessed source, not tested on any other
GCC 4.2.x platform


-- 


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

[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5

[jorn dot amundsen at ntnu dot no]

--- Comment #4 from jorn dot amundsen at ntnu dot no  2008-08-08 09:02 
---
Created an attachment (id=16046)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16046&action=view)
makeChemkinReactions.C assembler output

GCC 4.2.0 powerpc-ibm-aix5.3.0.0 assembler output from compiling
makeChemkinReactions.ii with -save-temps


-- 


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

[Bug libfortran/18985] opening unit 6 messes up print

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2008-08-08 09:50 ---
(In reply to comment #8)
> What does Fortran 2003 have to do with legacy mode? Nothing.

Well, any compiler strives to be standard compliant thus I would expect all of
the compilers to behave *by default* according to the standard (as defined by
the International Organization of Standardization, ISO, and its members such as
ANSI, DIN, BSI, ...).

Relying on anything else is problematic as it might break if you upgrade to a
new compiler version, change to a different compiler or change your system. As
long as a vendor extension or implementation choice is compatible with the
Fortran standard, I think it makes sense that compiler writers try to implement
them in a way compatible with the majority of other compilers. As soon as the
Fortran standard clashes with an implementation choice - even if is the
implementation of e.g. 8 wider spread compilers - the standard wins. (After
all, all major vendors are also on board of the standardization committee,
which means that either those who want to have the "changes" have better
arguments, more compilers behave differently or that the representative was
asleep.)

> So far as I know the GCC compiler is at odds with Solaris, Intel, Vax

It is not at the odds with g77, which is gfortran's ancestor (even though not
code wise). It is also compatible with g95, NAG f95, Open64/openf95 (which is
based on the SGI compiler) and may more compilers. Additionally, the compilers
you mentioned above will move to the Fortran 2003 standard in the future. With
default options your program will then break as well.

For vendors such as Intel the problem is bigger: They have customers which
expect the Fortran 2003 result (like me) and other customers which expect the
behavior of older versions of ifort (like you). Whatever they use as default,
it will break programs and leave angry customers behind.

(Though in case of unit=6 I/O the issue should not be too difficult to trace
down. Relying on zero default initialization, BOZ (where some implementation
choices are at odds with the Fortran 2003 standard) are much harder to trace
down.)

> The behaviour is therefore both unexpected and difficult to track
> down (not even a warning).

I agree that is unexpected, but that is always the case if one relies on
something undefined, where a few vendors choose one solution and the rest
choses different implementations. An example for this are random numbers. If
you call random_seed without any arguments, do you want to have the same random
number sequence every time you run the program or every time a different
sequence? It is not specified in the standard and one can argue for either one.

> This is a serious bug, make no mistake.
It is not. It is a inconvenience - and seemingly a major one for your program -
but not a serious bug.

> It causes existing Fortran 77 code to fail.

It only causes a small fraction of Fortran code to fail, which never was valid
Fortran 77. I have such a program, but there it simply write one more line to
the LOG file instead of to stdout. It is mildly annoying, but does not hamper
the use at all. Your program seems to be one of the few programs which use it
and where this causes a major problem.

> The ubiquitousness of the print*, (or write(*,*)) statement makes fixing
> this bug a priority.

First, while * is used in almost all Fortran programs, the "OPEN(6, file=" is
by far not ubiquitousness.

Secondly, as written it is not a bug but a feature, which relied on some
implementation choice. In any case there will never be a default-warning as the
code is perfectly valid and only clashes with an implementation choice.

Thirdly, if you think that there should be an option to warn (which had to be
turned on explicitly not via -Wall) or an option (flag) to behave differently,
you can open a new bug (Severity: Enhancement), but do not expect that this
will be a high-priority bug. -- Even better: As the source code is available,
we are happy to incorporate patches.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||schilds at sun dot ac dot za


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

[Bug tree-optimization/37056] [4.4 Regression] ICE in build2_stat, at tree.c:3257

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-08 10:00 ---
Mine.  Some tuplification errors in tree-ssa-loop-niter.c.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-08 10:00:47
   date||
Summary|ICE in build2_stat, at  |[4.4 Regression] ICE in
   |tree.c:3257 |build2_stat, at tree.c:3257
   Target Milestone|--- |4.4.0


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

[Bug target/37055] [4.4 Regression] Revision 138835 breaks -msse2 -mfpmath=sse -Os

[jh at suse dot cz]

--- Comment #2 from jh at suse dot cz  2008-08-08 10:47 ---
Subject: Re:  internal compiler error: in emit_unop_insn, at optabs.c:3806

Hi,
this is patch I am testing.

Index: optabs.c
===
*** optabs.c(revision 138862)
--- optabs.c(working copy)
*** maybe_emit_unop_insn (int icode, rtx tar
*** 3769,3774 
--- 3769,3775 
rtx temp;
enum machine_mode mode0 = insn_data[icode].operand[1].mode;
rtx pat;
+   rtx last = get_last_insn ();

temp = target;

*** maybe_emit_unop_insn (int icode, rtx tar
*** 3782,3788 

pat = GEN_FCN (icode) (temp, op0);
if (!pat)
! return false;

if (INSN_P (pat) && NEXT_INSN (pat) != NULL_RTX && code != UNKNOWN)
  add_equal_note (pat, temp, code, op0, NULL_RTX);
--- 3783,3792 

pat = GEN_FCN (icode) (temp, op0);
if (!pat)
! {
!   delete_insns_since (last);
!   return false;
! }

if (INSN_P (pat) && NEXT_INSN (pat) != NULL_RTX && code != UNKNOWN)
  add_equal_note (pat, temp, code, op0, NULL_RTX);
*** expand_fix (rtx to, rtx from, int unsign
*** 5157,5162 
--- 5161,5167 

if (icode != CODE_FOR_nothing)
  {
+   rtx last = get_last_insn ();
if (fmode != GET_MODE (from))
  from = convert_to_mode (fmode, from, 0);

*** expand_fix (rtx to, rtx from, int unsign
*** 5170,5180 
if (imode != GET_MODE (to))
  target = gen_reg_rtx (imode);

!   emit_unop_insn (icode, target, from,
!   doing_unsigned ? UNSIGNED_FIX : FIX);
!   if (target != to)
! convert_move (to, target, unsignedp);
!   return;
  }
}

--- 5175,5188 
if (imode != GET_MODE (to))
  target = gen_reg_rtx (imode);

!   if (maybe_emit_unop_insn (icode, target, from,
! doing_unsigned ? UNSIGNED_FIX : FIX))
! {
!   if (target != to)
! convert_move (to, target, unsignedp);
!   return;
! }
!   delete_insns_since (last);
  }
}

*** expand_sfix_optab (rtx to, rtx from, con
*** 5382,5387 
--- 5390,5396 
icode = convert_optab_handler (tab, imode, fmode)->insn_code;
if (icode != CODE_FOR_nothing)
  {
+   rtx last = get_last_insn ();
if (fmode != GET_MODE (from))
  from = convert_to_mode (fmode, from, 0);

*** expand_sfix_optab (rtx to, rtx from, con
*** 5389,5395 
  target = gen_reg_rtx (imode);

if (!maybe_emit_unop_insn (icode, target, from, UNKNOWN))
! return false;
if (target != to)
  convert_move (to, target, 0);
return true;
--- 5398,5407 
  target = gen_reg_rtx (imode);

if (!maybe_emit_unop_insn (icode, target, from, UNKNOWN))
! {
!   delete_insns_since (last);
!   continue;
! }
if (target != to)
  convert_move (to, target, 0);
return true;


-- 


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

[Bug tree-optimization/37056] [4.4 Regression] ICE in build2_stat, at tree.c:3257

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-08 11:31 ---
Subject: Bug 37056

Author: rguenth
Date: Fri Aug  8 11:30:13 2008
New Revision: 138865

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138865
Log:
2008-08-08  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/37056
* gimple.h (gimple_assign_rhs_class): New helper function.
* tree-ssa-loop-niter.c (get_val_for): Fix tuplification, handle
unary operations properly.

* gcc.c-torture/compile/pr37056.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37056.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c


-- 


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

[Bug tree-optimization/37056] [4.4 Regression] ICE in build2_stat, at tree.c:3257

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-08 11:31 ---
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=37056

[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2008-08-08 13:58 ---
(In reply to comment #4)
I can confirm that the reduced test case fails for me with gcc 4.0.4, 4.1.2,
4.2.4, and 4.3.1 on both powerpc and powerpc64. gcc-3.4.6 and older work.

It doesn't fail for me with gcc-4.x on either sparc64 or arm.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug debug/37020] [4.4 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2008-08-08 14:38 
---
The regression tester found that this regression was on revision 138238, by Jan
Hubicka.:


Jan, can you take a look at this please?


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-08 14:38:39
   date||


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

[Bug debug/37058] New: [4.4 Regression] profiling testcases fail with .cfi_endproc without corresponding .cfi_startproc

[rguenth at gcc dot gnu dot org]

I see

FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-use
-D_PROFILE_U
SE
FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
-D_PROFILE_US
E

which is because

pr34999.s: Assembler messages:
pr34999.s:114: Error: .cfi_endproc without corresponding .cfi_startproc
pr34999.s:124: Error: open CFI at the end of file; missing .cfi_endproc
directive

as both testcases use -freorder-blocks-and-partition (?)

> as --version
GNU assembler 2.16.91.0.5 20051219 (SUSE Linux)

and

> as --version
GNU assembler (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1


-- 
   Summary: [4.4 Regression] profiling testcases fail with
.cfi_endproc without corresponding .cfi_startproc
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug libstdc++/37059] New: ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

[danglin at gcc dot gnu dot org]

libtool: compile:  /Users/dave/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc
-B/Users
/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/Users/dave/gnu/gcc/objdir/i686-apple-d
arwin9/libstdc++-v3/src
-L/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc+
+-v3/src/.libs -B/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/bin/
-B/opt/gnu/gcc/g
cc-4.4.0/i686-apple-darwin9/lib/ -isystem
/opt/gnu/gcc/gcc-4.4.0/i686-apple-darw
in9/include -isystem /opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/sys-include
-I/Us
ers/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwi
n9 -I/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include
-I/Users
/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra
-
Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-fvisibility-inlines
-hidden -ffunction-sections -fdata-sections -g -O2 -c ctype_members.cc 
-fno-com
mon -DPIC -o .libs/ctype_members.o
ctype_members.cc:137: error: redefinition of 'bool
std::ctype::do_is(lo
ng unsigned int, wchar_t) const'
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-da
rwin9/bits/ctype_inline.h:118: error: 'virtual bool
std::ctype::do_is(l
ong unsigned int, wchar_t) const' previously defined here
ctype_members.cc:155: error: redefinition of 'const wchar_t*
std::ctype
::do_is(const wchar_t*, const wchar_t*, long unsigned int*) const'
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-da
rwin9/bits/ctype_inline.h:125: error: 'virtual const wchar_t*
std::ctype::do_is(const wchar_t*, const wchar_t*, long unsigned int*) const' previously d
efined here
ctype_members.cc:173: error: redefinition of 'const wchar_t*
std::ctype
::do_scan_is(long unsigned int, const wchar_t*, const wchar_t*) const'
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-da
rwin9/bits/ctype_inline.h:135: error: 'virtual const wchar_t*
std::ctype::do_scan_is(long unsigned int, const wchar_t*, const wchar_t*) const' previous
ly defined here
ctype_members.cc:182: error: redefinition of 'const wchar_t*
std::ctype
::do_scan_not(long unsigned int, const wchar_t*, const wchar_t*) const'
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-da
rwin9/bits/ctype_inline.h:144: error: 'virtual const wchar_t*
std::ctype::do_scan_not(long unsigned int, const wchar_t*, const wchar_t*) const' previou
sly defined here

[EMAIL PROTECTED]:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
Target: i686-apple-darwin9
Configured with: ../gcc/configure --build=i686-apple-darwin9
--host=i686-apple-darwin9 --target=i686-apple-darwin9 --with-gnu-as
--with-tune=generic --prefix=/opt/gnu/gcc/gcc-4.4.0 --enable-debug=no
--disable-nls --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-java-gc=boehm
Thread model: posix
gcc version 4.4.0 20080808 (experimental) [trunk revision 138857] (GCC)


-- 
   Summary: ctype_members.cc:137: error: redefinition of 'bool
std::ctype::do_is(lo ng unsigned int, wchar_t)
const'
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug middle-end/37060] New: [4.3/4.4 regression] Bogus __builtin___memcpy_chk overflow warning

[schwab at suse dot de]

$ gcc -O2 -S sparc-tdep.i 
In function ‘memcpy’,
inlined from ‘sparc32_store_return_value’ at sparc-tdep.i:39:
sparc-tdep.i:8: warning: call to __builtin___memcpy_chk will always overflow
destination buffer


-- 
   Summary: [4.3/4.4 regression] Bogus __builtin___memcpy_chk
overflow warning
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: ia64-*-*


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

[Bug middle-end/37060] [4.3/4.4 regression] Bogus __builtin___memcpy_chk overflow warning

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-08-08 15:16 ---
Created an attachment (id=16047)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16047&action=view)
Testcase


-- 


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

[Bug middle-end/37060] [4.3/4.4 regression] Bogus __builtin___memcpy_chk overflow warning

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-08 15:43 ---
We fail to see that the len == 16 case cannot happen in the second if (), more
specifically we fail to jump-thread because of the twisted CFG.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|ia64-*-*|
   Keywords||missed-optimization
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-08-08 15:43:24
   date||
   Target Milestone|--- |4.3.2


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

[Bug libfortran/18985] opening unit 6 messes up print

[kargl at gcc dot gnu dot org]

--- Comment #10 from kargl at gcc dot gnu dot org  2008-08-08 15:57 ---
(In reply to comment #8)
> What does Fortran 2003 have to do with legacy mode? Nothing.

You are aware that Fortran 2003 is backwards compatible with
Fortran 77, right?

> So far as I know the GCC compiler is at odds with Solaris, Intel, Vax,
> you name it. All of these allowed you to touch unit 6 without affecting
> the print*, (or write(*,*)) statement. The behaviour is therefore both
> unexpected and difficult to trackdown (not even a warning).

Then by all means use one of those compilers.

> 
> This is a serious bug, make no mistake.

Yes, it is a serious bug in your code.  So, fix it.

> It causes existing Fortran 77 code to fail.

No, it does not.  You are invoking processor dependent behavior.
Whatever results is correct.

> It's wasted a lot of my time and, no doubt, a lot of other, good peoples'
> too. The ubiquitousness of the print*, (or write(*,*)) statement makes
> fixing this bug a priority.

I seriously doubt that this issue has wasted a lot of other peoples'
time.  You're only person in the 6 year history of gfortran to whine
about it.

If anything, you're wasting the time of the gfortran developers.  You
know, those good people that have actually given the option of of a
free Fortran compiler.


-- 


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

[Bug ada/37005] GNAT Bug Box for cd2a24e.adb:37 at tree-vrp.c:392

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-08-08 16:03 ---
Also occurs on powerpc-rtems4.9 - 

4.4.0 20080807 (experimental) [trunk revision 138841]


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|sparc-rtems4.9  |sparc-rtems4.9 powerpc-
   ||rtems4.9
Summary|GNAT Bug Box for|GNAT Bug Box for
   |cd2a24e.adb:37 at tree- |cd2a24e.adb:37 at tree-
   |vrp.c:392   |vrp.c:392


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

[Bug ada/37040] GNAT Socket Code Broken on RTEMS

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-08-08 16:08 ---
Created an attachment (id=16048)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16048&action=view)
Updated RTEMS support for revision 138841


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16035|0   |1
is obsolete||


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

[Bug ada/37040] GNAT Socket Code Broken on RTEMS

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-08-08 16:08 ---
2008-08-08  Joel Sherrill <[EMAIL PROTECTED]>

* s-oscons-tmplt.c: RTEMS defines AF_INET6 but does support it.
* gsocket.h, socket.c: Update to support RTEMS.
* gcc-interface/Make-lang.in: Include CFLAGS_FOR_TARGET when cross.


-- 


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

[Bug bootstrap/37061] New: Build fails with REGISTER_TARGET_PRAGMAS redefined

[jeff at jgarrett dot org]

I'm compiling gcc snapshot 20080801 on a Solaris 2.10 (amd64) machine with host
tools from binutils 2.18 and gcc 4.3.

I've configured with:
../gcc-4.4-20080801/configure  --disable-static --enable-shared
--prefix=/home/huron/jeffga/sfw/gcc-4.4
--with-gmp=/home/huron/jeffga/sfw/gcc-4.4
--with-mpfr=/home/huron/jeffga/sfw/gcc-4.4 --with-gnu-as --with-gnu-ld

But make fails with:

[... snipped ..]
/home/huron/jeffga/src/obj/./prev-gcc/xgcc
-B/home/huron/jeffga/src/obj/./prev-gcc/
-B/home/huron/jeffga/sfw/gcc-4.4/i386-pc-solaris2.10/bin/ -c  -g -O2 -DIN_GCC  
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.4-20080801/gcc
-I../../gcc-4.4-20080801/gcc/build -I../../gcc-4.4-20080801/gcc/../include
-I./../intl -I../../gcc-4.4-20080801/gcc/../libcpp/include
-I/home/huron/jeffga/sfw/gcc-4.4/include
-I/home/huron/jeffga/sfw/gcc-4.4/include
-I../../gcc-4.4-20080801/gcc/../libdecnumber
-I../../gcc-4.4-20080801/gcc/../libdecnumber/dpd -I../libdecnumber  -o
build/genconstants.o ../../gcc-4.4-20080801/gcc/genconstants.c
In file included from ./tm.h:19,
 from ../../gcc-4.4-20080801/gcc/genconstants.c:31:
../../gcc-4.4-20080801/gcc/config/sol2.h:237:1: error:
"REGISTER_TARGET_PRAGMAS" redefined
In file included from ./tm.h:12,
 from ../../gcc-4.4-20080801/gcc/genconstants.c:31:
../../gcc-4.4-20080801/gcc/config/i386/i386.h:542:1: error: this is the
location of the previous definition
make[3]: *** [build/genconstants.o] Error 1
make[3]: Leaving directory `/home/huron/jeffga/src/obj/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/huron/jeffga/src/obj'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/huron/jeffga/src/obj'
make: *** [all] Error 2

The same REGISTER_TARGET_PRAGMAS redefined warning also showed up repeatedly in
the earlier compilation but as that all happened without -Werror, it continued.

Line 237 of gcc/config/sol2.h in the source does have:
#define REGISTER_TARGET_PRAGMAS() solaris_register_pragmas ()
Line 542 of gcc/config/i386/i386.h has:
#define REGISTER_TARGET_PRAGMAS() ix86_register_pragmas ()

The same configure command, with the same tools, will build gcc 4.3.1 without
issue.


-- 
   Summary: Build fails with REGISTER_TARGET_PRAGMAS redefined
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at jgarrett dot org
  GCC host triplet: i386-pc-solaris2.10


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

[Bug c++/37062] New: missing warning on unreachable return statement

[sebor at roguewave dot com]

gcc 4.3.0 issues warnings for the unreachable code on lines 7 and 9 below
but fails to issue one for line 17.

$ cat -n t.C && g++ -Wunreachable-code -c t.C
 1  int f ()
 2  {
 3  int i = 0;
 4
 5  if (i == 0) return 0;
 6
 7  throw i;// unreachable, warning
 8  return 1;   // unreachable, warning
 9  }
10
11  int g ()
12  {
13  int i = 0;
14
15  if (i == 0) return 0;
16
17  return 1;   // unreachable, no warning
18  }
19
t.C: In function ‘int f()’:
t.C:7: warning: will never be executed
t.C:8: warning: will never be executed


-- 
   Summary: missing warning on unreachable return statement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug c++/37062] missing warning on unreachable return statement

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-08 19:06 ---
>17  return 1;   // unreachable, no warning

This is only unreachable with optimization turned on so closing as invalid.


-- 

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

[Bug c++/37063] New: missing optimiation on unreachable code

[sebor at roguewave dot com]

I would expect gcc to optimize away the unreachable code in both functions
below but only in the first one is it eliminated. In addition, even though
the call to f1() in f3() can never be executed the compiler issues no
warning.

$ cat -n t.C && g++ -Wunreachable-code -O3 -S t.C
 1  void f1 ();
 2
 3  int f2 ()
 4  {
 5  int x = 0;
 6
 7  if (x == 0) return 0;
 8  f1 ();
 9
10  return 1;
11  }
12
13  int f3 ()
14  {
15  static int x;
16
17  if (x == 0) return 0;
18  f1 (); 
19
20  return 1;
21  }
22
t.C: In function ‘int f2()’:
t.C:8: warning: will never be executed


-- 
   Summary: missing optimiation on unreachable code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug c++/37063] missing optimiation on unreachable code

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-08 19:43 ---
Fixed in for 4.4.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||missed-optimization
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c/37064] New: missing warning on pure function with side-effects

[sebor at roguewave dot com]

gcc assumes that functions defined with the pure attribute have no side
effects and do not modify program state, including through pointers passed
to such functions as arguments. The function below does modify the object
pointed to by its argument. It would be useful if gcc issued a diagnostic
for this and other similar violations of the "pure" assumption, analogously
to how it diagnoses noreturn functions that do return.

$ cat -n t.C && g++ -c -O2 -Wall -W t.C
 1  int f0 () __attribute ((noreturn));
 2  int f0 () { return 0; }
 3
 4  int f1 (int*) __attribute ((pure));
 5  int f1 (int *i)
 6  {
 7  *i = 0;
 8  return 0;
 9  }
10
t.C: In function ‘int f0()’:
t.C:2: warning: function declared ‘noreturn’ has a ‘return’ statement
t.C:2: warning: ‘noreturn’ function does return


-- 
   Summary: missing warning on pure function with side-effects
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug c/37064] missing warning on pure function with side-effects

[sebor at roguewave dot com]

--- Comment #1 from sebor at roguewave dot com  2008-08-08 19:47 ---
Similarly, functions declared with the const attribute such as f1() in the
test case below that violate the compiler's assumptions should be diagnosed:

$ cat -n t.C && g++ -c -O2 -Wall -W t.C
 1  extern int i;
 2  int f1 () __attribute ((const));
 3  int f1 ()
 4  {
 5  return i;
 6  }
 7


-- 


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

[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-08-08 20:16 
---
This breaks building the kernel as well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   GCC host triplet|i586-*-*|
 GCC target triplet||i586-*-*
   Priority|P3  |P1
   Target Milestone|--- |4.3.2


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

[Bug fortran/34567] module name without a module

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2008-08-08 20:34 ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> If you look, the patch preceeded the PR.  Toon posted the problem on the list,
> promising to develop this testcase. This he duly did.  Please keep it open
> another few days; I'll clean up testcases, if needs be, and so on.
> 
> Thanks for the reminder, Daniel.
> 

me too ;-) ?


-- 


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

[Bug fortran/34805] defined assignment not allowed to vector subscripted array

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2008-08-08 20:39 ---
has J3 judged the testcase ?


-- 


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

[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault

[andreast at gcc dot gnu dot org]

--- Comment #21 from andreast at gcc dot gnu dot org  2008-08-08 20:50 
---
Ok, to clarify, the bootstrap issue 'has gone', but the reduced test case from
#17 still fails. Failure confirmed on i686-apple-darwin r138861.


-- 


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

[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90

[jv244 at cam dot ac dot uk]

--- Comment #19 from jv244 at cam dot ac dot uk  2008-08-08 20:52 ---
Is this still an ice-on-valid-code ? I can't reproduce that here.


-- 


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

[Bug c/37064] missing warning on pure function with side-effects

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-08 20:53 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-08-08 20:53:56
   date||


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

[Bug c/37064] missing warning on pure function with side-effects

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-08-08 21:01 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-08-08 21:01 ---
*** Bug 37064 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sebor at roguewave dot com


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[jv244 at cam dot ac dot uk]

--- Comment #9 from jv244 at cam dot ac dot uk  2008-08-08 21:06 ---
what is the 'rejects-valid' testcase here? apart from ifort, all compilers I
can access right now reject the program in the initial comment.


-- 


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

[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-08 
21:06 ---
Subject: Re:  ICE: GNU MP: Cannot reallocate memory for
gfortran.dg/parameter_array_init_3.f90

> --- Comment #19 from jv244 at cam dot ac dot uk  2008-08-08 20:52 ---
> Is this still an ice-on-valid-code ? I can't reproduce that here.

Seems fixed .

Dave


-- 


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

[Bug fortran/35718] deallocating non-allocated pointer target does not fail

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2008-08-08 21:13 ---
works correctly with e.g. ifort and xlf90, so worth fixing somehow.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail||4.4.0


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

[Bug c++/35985] [4.2/4.3/4.4 regression] ICE with pointer to member function as base

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2008-08-08 21:19 
---
Subject: Bug 35985

Author: reichelt
Date: Fri Aug  8 21:17:54 2008
New Revision: 138886

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138886
Log:
PR c++/35985
* decl.c (xref_basetypes): Check base for MAYBE_CLASS_TYPE_P,
and make sure it is not a union.

* g++.dg/inherit/base3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/inherit/base3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35985] [4.2/4.3 regression] ICE with pointer to member function as base

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2008-08-08 21:22 
---
Fixed on mainline.

Btw, the patch was approved here:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00194.html


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |04/msg01530.html|05/msg00542.html
Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE
   |with pointer to member  |with pointer to member
   |function as base|function as base


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

[Bug fortran/35840] ICE for character expression in I/O specifier

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-08-08 21:31 ---
This turned in a rejects valid ?
pr35840.f90:1.25:

write(10,*, asynchronous="Y"//"E"//trim("S  "))
1
Error: ASYNCHRONOUS= specifier at (1) must be an initialization expression


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |rejects-valid
  Known to fail||4.4.0


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

[Bug fortran/35937] Wrong type for charlength of function

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2008-08-08 21:38 ---
the testcase in comment #4 is working now. Is the bug still open?


-- 


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

[Bug c/35746] [4.3 regression] ICE with undefined variables

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2008-08-08 21:40 
---
I can still reproduce this on the 4.3 branch as of 2008-08-07.
On mainline the bug disappeared between 2008-07-29 and 2008-08-02.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with
   |with undefined variables|undefined variables


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

[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2008-08-08 21:43 ---
also works without problems on x86_64 (linux)


-- 


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

[Bug fortran/36091] false positive in bounds checking with forall

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-08-08 21:48:30
   date||


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

[Bug fortran/35937] Wrong type for charlength of function

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2008-08-08 21:50 ---
On i686-apple-darwin9, the testcase in comment #4 gives a "Bus error" at -m32
(rev. 138886).


-- 


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

[Bug fortran/36214] Wrong simplification of BOZ constants

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2008-08-08 22:15 ---
Maybe a hint from xlf90:

xlf90 test.f90
"test.f90", line 3.41: 1516-045 (E) Source is longer than target. Truncation
will occur on the left.
"test.f90", line 6.14: 1516-045 (E) Source is longer than target. Truncation
will occur on the left.

and xlf90 works code works fine.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to fail||4.4.0


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

[Bug fortran/36526] pointer in pure function

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2008-08-08 22:23 ---
this bug seems fixed in 4.4.0, should it be closed?


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to work||4.4.0


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

[Bug fortran/36582] Namelist I/O error: Bogus "Cannot match namelist object"

[jv244 at cam dot ac dot uk]

--- Comment #14 from jv244 at cam dot ac dot uk  2008-08-08 22:27 ---
This appears fixed on current trunk, should the bug be closed.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail|4.1.3 4.2.1 4.3.1 4.4.0 |4.1.3 4.2.1 4.3.1
  Known to work||4.4.0


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

[Bug fortran/36795] crash with character allocatable array argument

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2008-08-08 22:33 ---
I wonder if this bug can be closed, the testcase appears to work with trunk


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to work||4.4.0


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

[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug testsuite/36087] [4.4 Regression] test failures between revs. 134696 and 134717

[mmitchel at gcc dot gnu dot org]

--- Comment #6 from mmitchel at gcc dot gnu dot org  2008-08-08 22:46 
---
Janis --

I don't understand this PR.  It sounds like this should just be closed out,
since the failures reported are long-standing, and, if necessary, new PRs
opened for the other issues reported here.  Is that correct?

Thanks,

-- Mark


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot
   ||org, mmitchel at gcc dot gnu
   ||dot org


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

[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug target/36904] [4.4 Regression] vector context sensitive keyword vs macros

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug bootstrap/36908] [4.4 Regression] bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c

[mmitchel at gcc dot gnu dot org]

--- Comment #5 from mmitchel at gcc dot gnu dot org  2008-08-08 22:50 
---
The submitter indicates that a subsequent revision corrected the problem.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-08 22:52 ---
This effects more than SPU, for shared libaries, the more runtime relocations
that happen, the slower the load time (usually).  Just for SPU, runtime
relocations are not supported which is why there is error here.  I am going to
change it back to a P3 so Mark can re-decide based on this extra piece of
information. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org
   Keywords||missed-optimization
   Priority|P5  |P3


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

[Bug fortran/31217] ICE using FORALL on character substrings

[jv244 at cam dot ac dot uk]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-01-01 01:25 ---
*** Bug 34633 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||holst at matmech dot com
   Target Milestone|--- |4.3.0


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

[Bug c/28875] "-Wextra -Wno-unused-parameter -Wall" doesn't work as expected

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-08-08 23:16 ---
Subject: Bug 28875

Author: manu
Date: Fri Aug  8 23:15:31 2008
New Revision: 138890

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138890
Log:
2008-08-08  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR 28875
* flags.h (set_Wunused): Delete
* toplev.c (process_options): Handle Wunused flags here.
* opts.c (maybe_warn_unused_parameter): Delete.
(common_handle_option): Replace set_Wunused by warn_unused.
(set_Wextra): Do not handle Wunused-parameter here.
(set_Wunused): Delete.
* c-opts.c (c_common_handle_option): Replace set_Wunused by
warn_unused.
* common.opt (Wunused): Add Var and Init.
(Wunused-function): Likewise.
(Wunused-label): Likewise.
(Wunused-parameter): Likewise.
(Wunused-value): Likewise.
(Wunused-variable): Likewise.
fortran/
* options.c (set_Wall): Replace set_Wunused by warn_unused.
java/   
* lang.c (java_handle_option): Replace set_Wunused with
warn_unused.
testsuite/
* gcc.dg/unused-6-no.c: New.
* gcc.dg/unused-6-WallWextra.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/unused-6-WallWextra.c
trunk/gcc/testsuite/gcc.dg/unused-6-no.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-opts.c
trunk/gcc/common.opt
trunk/gcc/flags.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c
trunk/gcc/java/ChangeLog
trunk/gcc/java/lang.c
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/toplev.c


-- 


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

[Bug c/28875] "-Wextra -Wno-unused-parameter -Wall" doesn't work as expected

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-08-08 23:20 ---
FIXED in GCC 4.4

Thanks for the report Behdad!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/35746] [4.3 regression] ICE with undefined variables

[aldyh at gcc dot gnu dot org]

--- Comment #6 from aldyh at gcc dot gnu dot org  2008-08-08 23:23 ---
(In reply to comment #5)
> I can still reproduce this on the 4.3 branch as of 2008-08-07.
> On mainline the bug disappeared between 2008-07-29 and 2008-08-02.
> 

I see the error, but there is no longer an ICE.

$ ./cc1 --version
GNU C (GCC) version 4.3.2 20080808 (prerelease) [gcc-4_3-branch revision
138890] (x86_64-unknown-linux-gnu)
$ ./cc1 a.c -O2
 bar
a.c: In function 'bar':
a.c:6: error: 'X' undeclared (first use in this function)
a.c:6: error: (Each undeclared identifier is reported only once
a.c:6: error: for each function it appears in.)
a.c:6: error: expected ';' before 'j'
a.c:8: error: 'j' undeclared (first use in this function)
a.c:8: confused by earlier errors, bailing out

Is this not the expected behavior?


-- 


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

[Bug fortran/37011] F2003, type extension: multiple inheritence not rejected

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2008-08-08 23:24 ---
Subject: Bug 37011

Author: pault
Date: Fri Aug  8 23:22:51 2008
New Revision: 138891

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138891
Log:
2008-08-09  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37011
* symbol.c (gfc_add_extension): New function.
* decl.c (gfc_get_type_attr_spec): Call it.
(gfc_match_derived_decl): Set symbol extension attribute from
attr.extension.
* gfortran.h : Add prototype for gfc_add_extension.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/symbol.c


-- 


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

[Bug c/35746] [4.3 regression] ICE with undefined variables

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-08-08 23:25 ---
The ICE is there still, you just don't see it:
> a.c:8: confused by earlier errors, bailing out

That means there was an ICE after other errors had happened :).


-- 


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

[Bug fortran/37011] F2003, type extension: multiple inheritence not rejected

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-08-08 23:26 ---
Fixed as obvious.

Thanks for the report.

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

[Bug fortran/37011] F2003, type extension: multiple inheritence not rejected

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2008-08-08 23:28 ---
No testcase?


-- 


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

[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags

[manu at gcc dot gnu dot org]

--- Comment #27 from manu at gcc dot gnu dot org  2008-08-08 23:33 ---
Subject: Bug 7651

Author: manu
Date: Fri Aug  8 23:32:23 2008
New Revision: 138892

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138892
Log:
2008-08-09  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR 7651
* doc/invoke.texi (-Wextra): Move warning from here...
(-Wuninitialized): ... to here.
cp/
* class.c (check_bases_and_members): Warn with -Wuninitialized
instead of -Wextra.
testsuite/
* g++.dg/warn/Wuninitializable-member.C: New.
* g++.dg/warn/Wuninitializable-member-no.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wuninitializable-member-no.C
trunk/gcc/testsuite/g++.dg/warn/Wuninitializable-member.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/36087] [4.4 Regression] test failures between revs. 134696 and 134717

[janis at gcc dot gnu dot org]

--- Comment #7 from janis at gcc dot gnu dot org  2008-08-08 23:34 ---
Mark, the tests started failing because -fdump-rtl-loop2 used to produce dump
files for all loop2_* passes.  The compiler could be fixed to do that again, or
the tests mentioned here could be changed to use -fdump-rtl-loop2_unroll and
-fdump-rtl-loop2_invariant instead of -fdump-rtl-loop2.  I was expecting
someone to fix the compiler after Andrew complained about the change, but I
wouldn't mind modifying the tests and closing this PR.


-- 


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

[Bug testsuite/36087] [4.4 Regression] test failures between revs. 134696 and 134717

[mark at codesourcery dot com]

--- Comment #8 from mark at codesourcery dot com  2008-08-08 23:40 ---
Subject: Re:  [4.4 Regression] test failures between
 revs. 134696 and 134717

janis at gcc dot gnu dot org wrote:
> --- Comment #7 from janis at gcc dot gnu dot org  2008-08-08 23:34 ---
> Mark, the tests started failing because -fdump-rtl-loop2 used to produce dump
> files for all loop2_* passes.  The compiler could be fixed to do that again, 
> or
> the tests mentioned here could be changed to use -fdump-rtl-loop2_unroll and
> -fdump-rtl-loop2_invariant instead of -fdump-rtl-loop2.  I was expecting
> someone to fix the compiler after Andrew complained about the change, but I
> wouldn't mind modifying the tests and closing this PR.

OK, I understand much better now, thanks!  Do we have a separate PR open 
for the problem as well, or shall I retitle this one to more accurately 
reflect the problem?

Thanks,


-- 


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

[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

[mmitchel at gcc dot gnu dot org]

--- Comment #2 from mmitchel at gcc dot gnu dot org  2008-08-08 23:44 
---
Andrew --

If indeed this is an optimization regression on other platforms, then I agree
that this should be a P2 defect.  Is the optimization problem present on all
platforms with -fPIC?  If not, what's a specific platform where the problem
occurs?  Also, what values are being relocated at run time in the tests case? 
Do you think the compiler should be generating PC-relative addresses for the
tables?  Or that the inliner should be resolving "xxx(8)" to a constant?

Thanks,

-- Mark


-- 


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #10 from sgk at troutmask dot apl dot washington dot edu  
2008-08-08 23:46 ---
Subject: Re:  scope of variables in statement function do not acquire rank from
host

On Fri, Aug 08, 2008 at 09:06:37PM -, jv244 at cam dot ac dot uk wrote:
> 
> --- Comment #9 from jv244 at cam dot ac dot uk  2008-08-08 21:06 ---
> what is the 'rejects-valid' testcase here? apart from ifort, all compilers I
> can access right now reject the program in the initial comment.
> -- 
> 

Well, to start with, the code in comment #1 is valid Fortran 95.
See comment #3.  In checking, F2003 the exact same text appears.
I suppose you need to file bug reports with the other compiler
vendors.



-- 


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

[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-08-08 23:58 ---
Subject: Bug 36901

Author: manu
Date: Fri Aug  8 23:57:19 2008
New Revision: 138893

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138893
Log:
2008-08-09  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR 36901
* diagnostic.def (DK_PEDWARN, DK_PERMERROR): New.  
* diagnostic.c (pedantic_warning_kind, permissive_error_kind):
Moved from diagnostic.h
(diagnostic_report_diagnostic): Return bool. Handle DK_PEDWARN and
DK_PERMERROR.
(emit_diagnostic): New.
(warning0, pedwarn0): Delete.
(warning, warning_at, pedwarn, permerror): Return bool.  
* diagnostic.h (pedantic_warning_kind, permissive_error_kind):
Moved to diagnostic.c.
(struct diagnostic_context): Use correct type for
classify_diagnostic.
(diagnostic_report_diagnostic): Update declaration.
(emit_diagnostic): Declare.
* errors.c (warning): Return bool.  
* errors.h (warning): Update declaration.
* toplev.h (warning0, pedwarn0): Delete.
(warning, warning_at, pedwarn, permerror): Return bool.
* c-errors.c (pedwarn_c99, pedwarn_c90): Use DK_PEDWARN.
* c-decl.c (locate_old_decl): Delete 'diag' argument. Always use
inform. Update all calls.
(diagnose_mismatched_decls): Check return value of warning/pedwarn
before giving informative note.
(implicit_decl_warning): Likewise.  
* c-typeck.c (build_function_call): Likewise.  
* tree-sssa.c (warn_uninit): Likewise.  
* builtins.c (gimplify_va_arg_expr): Likewise.
fortran/
* f95-lang.c (gfc_mark_addressable): Use "pedwarn (0," instead of
'pedwarn0'.
cp/
* cp-tree.h (struct diagnostic_context, struct diagnostic_info):
Delete forward declarations. Check that toplev.h has not been
included before this file. Include toplev.h and diagnostic.h.
* error.c (cp_cpp_error): Use DK_PEDWARN.
(cxx_incomplete_type_diagnostic): Update declaration.
(cxx_incomplete_type_error): Use DK_ERROR.
* typeck2.c (cxx_incomplete_type_diagnostic): Take a diagnostic_t
as argument. Use emit_diagnostic.
(cxx_incomplete_type_error): Use DK_ERROR.
(add_exception_specifier): Use diagnostic_t instead of custom
codes.  
* typeck.c (complete_type_or_else): Update call to
cxx_incomplete_type_diagnostic.
* init.c (build_delete): Likewise.  
* call.c (diagnostic_fn_t): Remove unused typedef.
(build_temp): Pass a pointer to diagnostic_t.
(convert_like_real): Use emit_diagnostic.
(joust): Check return value of warning before giving informative
note.  
* friend.c (do_friend): Check return value of warning
before giving informative note.
* parser.c (cp_parser_template_id): Likewise.

testsuite/
* gcc.dg/pr36901-1.c: New.
* gcc.dg/pr36901-3.c: New.
* gcc.dg/pr36901-2.c: New.
* gcc.dg/pr36901-4.c: New.
* gcc.dg/pr36901-system.h: New.
* gcc.dg/pr36901.h: New.
* gcc.target/powerpc/altivec-macros.c: Update.
* gcc.target/i386/regparm.c: Update.
* gcc.dg/funcdef-var-1.c: Update.
* gcc.dg/parm-mismatch-1.c: Update.
* gcc.dg/attr-noinline.c: Update.
* gcc.dg/wtr-static-1.c: Update.
* gcc.dg/redecl-11.c: Update.
* gcc.dg/pr27953.c: Update.
* gcc.dg/proto-1.c: Update.
* gcc.dg/decl-3.c: Update.
* gcc.dg/redecl-13.c: Update.
* gcc.dg/pr15360-1.c: Update.
* gcc.dg/redecl-15.c: Update.
* gcc.dg/enum-compat-1.c: Update.
* gcc.dg/dll-3.c: Update.
* gcc.dg/array-5.c: Update.
* gcc.dg/Wredundant-decls-2.c: Update.
* gcc.dg/inline4.c: Update.
* gcc.dg/redecl-2.c: Update.
* gcc.dg/inline-14.c: Update.
* gcc.dg/tls/diag-3.c: Update.
* gcc.dg/funcdef-var-2.c: Update.
* gcc.dg/20041213-1.c: Update.
* gcc.dg/old-style-then-proto-1.c: Update.
* gcc.dg/decl-2.c: Update.
* gcc.dg/redecl-12.c: Update.
* gcc.dg/decl-4.c: Update.
* gcc.dg/Wshadow-1.c: Update.
* gcc.dg/transparent-union-2.c: Update.
* gcc.dg/visibility-7.c: Update.
* gcc.dg/dll-2.c: Update.
* gcc.dg/redecl-16.c: Update.
* gcc.dg/inline1.c: Update.
* gcc.dg/decl-8.c: Update.
* gcc.dg/nested-redef-1.c: Update.
* gcc.dg/inline3.c: Update.
* gcc.dg/redecl-1.c: Update.
* gcc.dg/inline5.c: Update.
* gcc.dg/pr35899.c: Update.
* gcc.dg/noncompile/label-lineno-1.c: Update.
* gcc.dg/noncompile/label-1.c: Update.
* gcc.dg/noncompile/20020220-1.c: Update.
* gcc.dg/noncompile/redecl-1.c: Update.
* gcc.dg/redecl-5.c: Update.
* gcc.dg/qual-return-3

[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-08-08 23:59 ---
Fixed in GCC 4.4


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/12242] g++ should warn about out-of-range int->enum conversions

[manu at gcc dot gnu dot org]

--- Comment #18 from manu at gcc dot gnu dot org  2008-08-09 00:32 ---
Subject: Bug 12242

Author: manu
Date: Sat Aug  9 00:30:41 2008
New Revision: 138898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138898
Log:
2008-08-09  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR c++/12242
cp/
* cvt.c (ocp_convert): Warn for out-of-range conversions to enum.

testsuite/
* g++.dg/warn/pr12242.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr12242.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/12242] g++ should warn about out-of-range int->enum conversions

[manu at gcc dot gnu dot org]

--- Comment #19 from manu at gcc dot gnu dot org  2008-08-09 00:35 ---
FIXED in GCC 4.4


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/37065] New: Virtual function from member constructor and destructor

[HHG01200 at nifty dot ne dot jp]

While member objects are constructed or destructed, the owner object's
overloaded virtual function is called.
It may be a problem because the owner object is not fully constructed at these
stage.
I think it is correct if base class' virtual function is called because the
base object is fully constructed at these stage.

--
#include 

class A
{
public:
A() {printf("A::A(),  "); v();}
virtual ~A() {printf("A::~A(), "); v();}
virtual void v() {puts("A::v()");}
};

class C
{
public:
A* p;
C(A* a) : p(a) {printf("C::C(),  "); p->v();}
~C() {printf("C::~C(), "); p->v();}
};

class B : public A
{
public:
C c;
B() : c(this) {printf("B::B(),  "); v();}
~B() {printf("B::~B(), "); v();}
void v() {puts("B::v()");}
};


int main()
{
 B b;

 return 0;
}

--
Actual result:

A::A(),  A::v()
C::C(),  B::v()
B::B(),  B::v()
B::~B(), B::v()
C::~C(), B::v()
A::~A(), A::v()

--
(I think) correct result:

A::A(),  A::v()
C::C(),  A::v()
B::B(),  B::v()
B::~B(), B::v()
C::~C(), A::v()
A::~A(), A::v()


-- 
   Summary: Virtual function from member constructor and destructor
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: HHG01200 at nifty dot ne dot jp
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90

[kargl at gcc dot gnu dot org]

--- Comment #21 from kargl at gcc dot gnu dot org  2008-08-09 05:15 ---
(In reply to comment #19)
> Is this still an ice-on-valid-code ? I can't reproduce that here.
> 

As with Dave, I can confirm that this problem no longer occurs
on x86_64-*-freebsd.  The PR can probably be closed.


-- 


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

[Bug fortran/36582] Namelist I/O error: Bogus "Cannot match namelist object"

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-08-09 05:20 
---
I was holding this open until I back port to 4.3.  I got too busy on other
stuff, so I will try this weekend.


-- 


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

[Bug target/37055] [4.4 Regression] Revision 138835 breaks -msse2 -mfpmath=sse -Os

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2008-08-09 
06:33 ---
The proposed patch eliminated the previous failures but I am now see some
additional ones in current gcc trunk...

FAIL: gcc.target/i386/incoming-1.c scan-assembler andl[\\t ]*\\$-16,[\\t ]*%esp
FAIL: gcc.target/i386/incoming-4.c scan-assembler andl[\\t ]*\\$-16,[\\t ]*%esp
FAIL: gcc.target/i386/incoming-5.c scan-assembler andl[\\t ]*\\$-8,[\\t ]*%esp


-- 


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