[Bug middle-end/41535] [4.5 Regression] Broken var location info after scheduling

[aoliva at gcc dot gnu dot org]

--- Comment #2 from aoliva at gcc dot gnu dot org  2009-10-07 07:23 ---
Thanks for the bug report, confirmed, looking into it.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org


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

[Bug middle-end/41535] [4.5 Regression] Broken var location info after scheduling

[aoliva at gcc dot gnu dot org]

-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 07:23:25
   date||


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

[Bug preprocessor/41445] Debug information is wrong with and without --save-temps.

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-10-07 07:37 ---
Created an attachment (id=18733)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18733&action=view)
gcc45-pr41445.patch

Updated patch that actually passed bootstrap.  Unfortunately it regresses many
gcc.dg/cpp/ tests, e.g. avoidpaste1.c is now preprocessed as:
# 1 "../../gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
# 1 ""
# 1 ""
# 1 "../../gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
# 25 "../../gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
:: : : : : :^: 1.0e-
# 14 "../../gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
1
# 26 "../../gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
: : : .. . 0 0 .


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18720|0   |1
is obsolete||


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

[Bug fortran/41603] [-fwhole-file] Add diagnostic for assumed-length character function

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-10-07 08:02 ---
More from the thread.

Richard Maine wrote:

  The Note appears to have been removed from f2003, but see
  F95 Note 5.6. Apparently it was the interface body case I was recalling
  rather than the module procedure case.

  "An interface body may be specified for a dummy or external function
   whose result has a character length parameter of * only if the function
   is not invoked. This is because this characteristic has to be specified
   to be the same in the interface body as in the procedure definition, but
   in order to invoke such a procedure, the calling routine is required to
   specify a length other than *."

   Well, I agree that the wording isn't as clear as I'd like. And I do note
   the switch from "consistent" to "same" in the above Note.

James Van Buskirk remarked "It seems possible to me that the Note was removed
   in the next edition because it was simply incorrect, not having been vetted
   to the same standard as normative text in the first place."

And Richard replied: "Granted"

(At least F2003 deprecates assumed-length functions: They are printed in 
smaller font size, which might be a reason for removal of the note.)

 * * *

One pragmatic solution would be to close this PR a won't fix and only fix the
items in PR 41604.


-- 


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

[Bug fortran/41604] Reject result with assumed-length character in INTERFACE decl

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-10-07 08:09 ---
Actually, according to a note (cf. PR 41603 comment 5) the interface actually
could be valid - as long it is not used.

While invoking the function directly is properly rejected, e.g. the following
  c = assumed_len(5)

using it as dummy is accepted:

 module funcs
   implicit none
   integer, parameter :: dp = kind(0.0)
   interface
  function assumed_len(x)
 character(*) assumed_len
 integer, intent(in) :: x
  end function assumed_len
   end interface
contains
  subroutine foo(x)
procedure(assumed_len) :: x !!! Invalid?!
! Check also using an "interface" directly
  end subroutine
  subroutine test()
call foo(assumed_len)
  end subroutine test
end module funcs



NAG f95 rejects it with:
Error: line 12: ASSUMED_LEN has an implicit interface, therefore it cannot be
used as a proc-interface

while Ifort as mentioned above already does not like the interface.

F95 had Note 5.6 (which is no longer in F2003):

  "An interface body may be specified for a dummy or external function
   whose result has a character length parameter of * only if the function
   is not invoked. This is because this characteristic has to be specified
   to be the same in the interface body as in the procedure definition, but
   in order to invoke such a procedure, the calling routine is required to
   specify a length other than *."


-- 


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

[Bug fortran/41615] New: Bogus error message: "internal function" should be "module procedure"

[burnus at gcc dot gnu dot org]

The following is properly rejected but the error message is bogus:

Error: Character-valued internal function 'assumed_len' at (1) must not be
assumed length

I tried to find an internal function, but all I see is a module procedure. (For
internal functions, assumed-length result values are also invalid.)

module funcs
   implicit none
contains
  function assumed_len(x)
 character(*) assumed_len
 integer, intent(in) :: x
  end function assumed_len
end module


-- 
   Summary: Bogus error message: "internal function" should be
"module procedure"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug preprocessor/41445] Debug information is wrong with and without --save-temps.

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-10-07 08:19 ---
Created an attachment (id=18734)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18734&action=view)
gcc45-pr41445.patch

An updated patch that actually fixes all cpp.exp regressions except 2 matches
in spacing1.c, we probably could either drop those or adjust the expected
output with # lines in between, or add -P, or add -P and add another test
without the two lines dropped and without -P.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18733|0   |1
is obsolete||


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

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2009-10-07 08:20 ---
(In reply to comment #8)
> Created an attachment (id=18732)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732&action=view) [edit]
> Potential patch to fix pr40737
> 
> Here is a patch from Adhemerval Zanella from our IBM LTC Performance team,
> that "fixes" the problem for me and bootstraps (powerpc64-linux) and
> regtests with no regressions.  Can someone else give this a try on their
> system?

I think it only paper bags the problem. The problem is that the span
information needs to be available in all places where the pointer is available
- also if the module a separate file from the one where the assignment is done
which can be again separate from the place where the pointer is used.

Thus, as written, I only see two solutions:

Solution 1: Always create that variable if they symbols is a pointer to an
array.
Solution 2: Defer it until we have the proper array descriptor, which handles
this.

I think in 4.6 we will finally go for solution 2.

Nevertheless, one should check whether the patch improves the situation for 4.5
and should thus be applied as interim solution.


-- 


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

[Bug libmudflap/38766] mudflap cannot detect errors on stack of nptl thread

[chris dot smith at st dot com]

--- Comment #1 from chris dot smith at st dot com  2009-10-07 08:33 ---
Did anyone ever find a solution to this? I'm seeing exactly the same effect
with gcc 4.3.2.


-- 


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

[Bug c++/41614] Compilation error with member templates

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-10-07 08:46 ---
The code is not valid, you need to change the line with the error to:

dbLeft.template detectFileChange<3>();


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug debug/41616] New: Variables promoted to Gimple registers by aliasing are not getting debug statements.

[hubicka at gcc dot gnu dot org]

In the following testcase:
inline int f(int *a)
{
  return *a;
}
main()
{
  int b=1;
  return f(&b);
}
We ought to be able to track that value of "b" is 1.  However we do not:
main ()
{
:
  # DEBUG a => &b
  return 1;

}


-- 
   Summary: Variables promoted to Gimple registers by aliasing are
not getting debug statements.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: aoliva at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
  GCC host triplet: x86_64-linux


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

[Bug c/41610] Non-standard identifier's names

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-10-07 09:29 ---
Huh?  You just cited the errors you got.  Use -pedantic if you want to be
warned about $ in identifiers.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-10-07 09:33 ---
Raphael, can you look into this?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||espindola at google dot com
OtherBugsDependingO||41588
  nThis||


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

[Bug c++/41614] Compilation error with member templates

[zhnmju123 at gmx dot de]

--- Comment #2 from zhnmju123 at gmx dot de  2009-10-07 09:33 ---
Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
worked, so I thought it would be valid.
Maybe a more expressive error message could help. In this shortened example the
error message is ... well... okay, but in my reallife project I get this as a
first error, which is totally misleading (and lead me into thinking this is a
compiler bug):

C:\Programme\C++\Projects\FreeFileSync\algorithm.cpp|565|error: no match for
'operator<' in 'dbLeft->DetectChanges::detectFileChange [with
FreeFileSync::SelectedSide side = side, bool respectFiltering = true] <
(FreeFileSync::SelectedSide)0u'|
C:\Programme\C++\wxWidgets\include\wx\string.h|1572|note: candidates are: bool
operator<(const wxString&, const wxString&)|
C:\Programme\C++\wxWidgets\include\wx\string.h|1574|note: bool
operator<(const wxString&, const wxChar*)|
C:\Programme\C++\wxWidgets\include\wx\string.h|1576|note: bool
operator<(const wxChar*, const wxString&)|
C:\Programme\C++\wxWidgets\include\wx\longlong.h|1040|note:
bool operator<(long int, const wxLongLong&)|
C:\Programme\C++\wxWidgets\include\wx\longlong.h|1053|note:
bool operator<(long unsigned int, const wxULongLong&)|


-- 


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

[Bug fortran/41613] ICE for gfortran.dg/dynamic_dispatch_*.f03 on powerpc-apple-darwin

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-10-07 09:45 ---
The fix in revision 152513 has been regtested without regression. Closing as
fixed.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/41614] Compilation error with member templates

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2009-10-07 09:48 ---
(In reply to comment #2)
> Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
> worked, so I thought it would be valid.

You should be wary of using VC++ to determine if code is valid, it's not often
right!

> Maybe a more expressive error message could help. In this shortened example 
> the
> error message is ... well... okay, but in my reallife project I get this as a
> first error, which is totally misleading (and lead me into thinking this is a
> compiler bug):
> 
> C:\Programme\C++\Projects\FreeFileSync\algorithm.cpp|565|error: no match for
> 'operator<' in 'dbLeft->DetectChanges::detectFileChange [with
> FreeFileSync::SelectedSide side = side, bool respectFiltering = true] <
> (FreeFileSync::SelectedSide)0u'|
> C:\Programme\C++\wxWidgets\include\wx\string.h|1572|note: candidates are: bool
> operator<(const wxString&, const wxString&)|
> C:\Programme\C++\wxWidgets\include\wx\string.h|1574|note: bool
> operator<(const wxString&, const wxChar*)|
> C:\Programme\C++\wxWidgets\include\wx\string.h|1576|note: bool
> operator<(const wxChar*, const wxString&)|
> C:\Programme\C++\wxWidgets\include\wx\longlong.h|1040|note:
> bool operator<(long int, const wxLongLong&)|
> C:\Programme\C++\wxWidgets\include\wx\longlong.h|1053|note:
> bool operator<(long unsigned int, const wxULongLong&)|
> 

Although it may be confusing, the message is technically correct, due to the
complicated parsing rules of C++.

no match for
'operator<' in 'dbLeft->DetectChanges::detectFileChange [...] <
(FreeFileSync::SelectedSide)0u'

says that the expression is being interpreted as 'x < y' where x is the member
'detectFileChange' and y is an integer constant. There is no appropriate
operator< available so it lists the visible overloads of operator<

The rules of C++ specifically say that the compiler must interpret it like
that, see 14.3 [temp.names] paragraph 4. The way to resolve it is to say you
are calling a template member function, by inserting the keyword 'template'
before the template-id, as I showed.


-- 


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

[Bug lto/41606] Not all types are fixed up

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-07 09:50 ---
I am looking into this.


-- 

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 |2009-10-07 09:50:11
   date||


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

[Bug objc/41617] New: [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[doko at ubuntu dot com]

Seen with a lot of GNUstep applications:

gcc AppController.m -c \
  -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG
-fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -O2
-fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS
-fgnu-runtime -fconstant-string-class=NSConstantString -I.
-I/usr/local/include/GNUstep -I/usr/include/GNUstep \
   -o obj/AppController.m.o
In file included from Date.h:4,
 from Event.h:3,
 from AppointmentEditor.h:3,
 from AppController.m:4:
/usr/include/ical.h:22:2: warning: #warning "#include  is deprecated. 
Please #include  instead."
/tmp/ccdTn0Sv.s: Assembler messages:
/tmp/ccdTn0Sv.s:11021: Error: symbol `_OBJC_CLASS_AppController' is already
defined
make[2]: *** [obj/AppController.m.o] Error 1


-- 
   Summary: [4.4/4.5 regression] ObjC: Error: symbol
`_OBJC_CLASS_AppController' is already defined
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
GCC target triplet: arm-linux-gnueabi


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

[Bug objc/41617] [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2009-10-07 09:52 ---
Created an attachment (id=18735)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18735&action=view)
preprocessed source


-- 


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

[Bug objc/41617] [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2009-10-07 09:53 ---
Created an attachment (id=18736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18736&action=view)
assembler file


-- 


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

[Bug objc/41617] [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[doko at ubuntu dot com]

--- Comment #3 from doko at ubuntu dot com  2009-10-07 09:53 ---
Created an attachment (id=18737)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18737&action=view)
preprocessed source


-- 


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

[Bug objc/41617] [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[doko at ubuntu dot com]

--- Comment #4 from doko at ubuntu dot com  2009-10-07 09:54 ---
Created an attachment (id=18738)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18738&action=view)
assembler file


-- 


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

[Bug fortran/41601] GNU Fortran is not working

[chris dot hhodges at gmail dot com]

--- Comment #4 from chris dot hhodges at gmail dot com  2009-10-07 10:23 
---
(In reply to comment #3)
> Please let us know if you fix this and/or you are still stuck.
> 

Yes. I've got this fixed now!
gcc now fully compiled. 

Many thanks for the pointer to the __gmp_get_memory_functions
error. I couldn't have done it without this info.
http://www.mpfr.org/faq.html#undef_ref1 describes the problem I had and
suggests some solutions.

In short I had two GMP libraries. One in /usr/local/lib, which I had compiled
from source, and one in /usr/lib, which was there from the distro.

Rather than fiddle about with compiler options and library paths I just updated
the gmp symlink in /usr/lib to point to the new library in /usr/local/lib and
then everything worked a treat.

Many thanks, once again.


-- 


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

[Bug fortran/41615] Bogus error message: "internal function" should be "module procedure"

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2009-10-07 10:32 ---
Confirmed, I'll investigate what we can do here (and look at similar cases).


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 10:32:55
   date||


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

[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-10-07 11:21 ---
(In reply to comment #1)
> Yes GPU libraries would be nice but this needs a lot of work to begin with. 
> First you have to support the GPUs.  This also amounts to doubling the 
> support.
>  If you really want them, since this is open source, start contributing.


Here is a contribution from my buds at NVidia ...


Quote from the Article:

"... support for native execution of C++. For the first time in history, a GPU
can run C++ code with no major issues or performance penalties ..."


nVidia GT300's Fermi architecture unveiled: 512 cores, up to 6GB GDDR5 
http://www.brightsideofnews.com/news/2009/9/30/nvidia-gt300s-fermi-architecture-unveiled-512-cores2c-up-to-6gb-gddr5.aspx


That should be more than 3/4 of the job done; only took 6 months.

Rob


-- 


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

[Bug debug/41616] Variables promoted to Gimple registers by aliasing are not getting debug statements.

[hubicka at ucw dot cz]

--- Comment #1 from hubicka at ucw dot cz  2009-10-07 11:26 ---
Subject: Re:   New: Variables promoted to Gimple registers by aliasing are not
getting debug statements.

> We ought to be able to track that value of "b" is 1.  However we do not:
> main ()
> {
> :
>   # DEBUG a => &b

Note that Richi was mentioning that &b is invalid given that b is
register.  I think it is OK - the ADDR_EXPRs in DEBUG statements does
not count as dereferences.

However we sould be able to track here a => &1 and at dwarf2out time try
to look up 1 in constant pool if there.  For integer constants this is
unlikely going to win, but for i.e. string constants this is quite
common case we might get better debug info. The tree expansion facility
now has neccesary code to do that, I can put it into RTL expansion too.

Honza


-- 


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

[Bug c++/41614] Compilation error with member templates

[zhnmju123 at gmx dot de]

--- Comment #4 from zhnmju123 at gmx dot de  2009-10-07 12:30 ---
This seems to be the member template analogon to cases where "typename" is
needed for nested types. Thanks for the detailed explanation!


-- 


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

[Bug fortran/41618] New: [OOP] accepts-invalid with CLASS pointer component

[janus at gcc dot gnu dot org]

The following invalid program is currently accepted:

 type t1
   integer :: comp
   class(t1),pointer :: cc
 end type

 class(t1) :: x! invalid: must be dummy, allocatable or pointer

 x%comp = 3
 print *,x%comp

end


Removing the line which defines the class pointer component 'cc' causes the
program to be correctly rejected.


-- 
   Summary: [OOP] accepts-invalid with CLASS pointer component
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug objc/41617] [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-10-07 12:57 ---
This doesn't even compile, you forgot NXConstStr.h stuff.
When it is added, it compiles just fine, at least on x86_64-linux and
i686-linux, no assembler errors.


-- 


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

[Bug c++/41619] New: ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon

[kenneth dot hoste at elis dot ugent dot be]

While doing a bunch of experiments with randomly constructed sets of
optimization flags, I ran into the following compilation error while trying to
build SPEC CPU2000's 252.eon:

internal compiler error: in insert_save, at caller-save.c:1122

The problem occurs during compilation of various of the benchmark's C++ source
files, mainly for  mrSpotAreaXYDiskLuminaire.cc and mrGrid.cc, while using any
of the following combination of flags:

-O1 -fno-ira-share-save-slots -fcaller-saves 
-O2 -fno-ira-share-save-slots 
-O3 -fno-ira-share-save-slots 
-Os -fno-ira-share-save-slots 

I've created a significantly reduced testcase using delta (attached).

Reproducing the error should be as simple as the line below, using g++ 4.4.1:

g++ -O2 -fno-ira-share-saved-spill-slots testcase.ii


-- 
   Summary: ICE in insert_save (caller-save.c) for SPEC CPU2000's
252.eon
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kenneth dot hoste at elis dot ugent dot be
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/41619] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon

[kenneth dot hoste at elis dot ugent dot be]

--- Comment #1 from kenneth dot hoste at elis dot ugent dot be  2009-10-07 
13:13 ---
Created an attachment (id=18739)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18739&action=view)
reduced testcase for this bug


-- 


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

[Bug bootstrap/41620] New: [4.5 regression] Bootstrap failure

[hjl dot tools at gmail dot com]

On Linux/i686, revision 152526 failed to bootstrap:

[...@gnu-29 libjava]$ /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc
-shared-libgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc -nostdinc++
-L/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/src
-L/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../src-trunk/libjava -I./include -I./gcj -I../../../src-trunk/libjava
-Iinclude -I../../../src-trunk/libjava/include
-I../../../src-trunk/libjava/classpath/include -Iclasspath/include
-I../../../src-trunk/libjava/classpath/native/fdlibm
-I../../../src-trunk/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../src-trunk/libjava/libltdl -I../../../src-trunk/libjava/libltdl
-I../../../src-trunk/libjava/.././libjava/../gcc
-I../../../src-trunk/libjava/../libffi/include -I../libffi/include -fno-rtti
-fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall
-D_GNU_SOURCE -DPREFIX=\"/usr/local\" -DTOOLEXECLIBDIR=\"/usr/local/lib\"
-DJAVA_HOME=\"/usr/local\"
-DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-4.5.0.jar\"
-DJAVA_EXT_DIRS=\"/usr/local/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/usr/local/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/usr/local/lib/gcj-4.5.0-11\" -DPATH_SEPARATOR=\":\"
-DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/usr/local/lib/gcj-4.5.0-11/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.5.0-11/classmap.db\" -g -O2
-D_GNU_SOURCE -MT gij.lo -MD -MP -MF .deps/gij.Tpo -c
../../../src-trunk/libjava/gij.cc  -fPIC -DPIC -o .libs/gij.o
/tmp/ccwSEiop.s: Assembler messages:
/tmp/ccwSEiop.s:1468: Error: junk at end of line, first unrecognized character
is `*'
/tmp/ccwSEiop.s:1469: Error: junk at end of line, first unrecognized character
is `*'
/tmp/ccwSEiop.s:1470: Error: expected comma after "_ZGAN8__JArrayC1Ev"
[...@gnu-29 libjava]$

There are

1468 .globl _ZGAN8__JArrayC1Ev *INTERNAL*
1469 .hidden _ZGAN8__JArrayC1Ev *INTERNAL*
1470 .set_ZGAN8__JArrayC1Ev *INTERNAL* ,_ZN8__JArrayC1Ev *INTERNAL*

Revision 152518 is OK.


-- 
   Summary: [4.5 regression] Bootstrap failure
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[jakub at gcc dot gnu dot org]

--- Comment #34 from jakub at gcc dot gnu dot org  2009-10-07 13:35 ---
Linker bug, so closing.  Workaround also exists, use a non-buggy linker, or use
non-obsolete crt files.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/41620] [4.5 regression] Bootstrap failure

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-10-07 13:35 ---
It may be caused by revision 152520:

http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00169.htm


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug c/41610] Non-standard identifier's names

[hudson at comp dot ufla dot br]

--- Comment #2 from hudson at comp dot ufla dot br  2009-10-07 13:47 ---
Ok, but this isn't a warning, it's an *error*. Concordant to specification
ANSI, it's not acceptable. Even -pedantic option must to give an error, no?

Anyway, thanks by reply!


-- 


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

[Bug c/41610] Non-standard identifier's names

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-10-07 13:58 ---
You are looking for -pedantic-errors I guess.


-- 


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

[Bug bootstrap/41620] [4.5 regression] Bootstrap failure

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||i686-pc-linux-gnu
   Target Milestone|--- |4.5.0


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

[Bug fortran/37427] Passed-object dummy argument should be polymorphic

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2009-10-07 14:04 ---
At least now this can be considered fully implemented, I think.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/38849] ICE in fold_convert with C_F_POINTER and C binding

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2009-10-07 14:09 ---
This is still happening with current gfortran trunk, though the ICE is now in

[/tmp]# gfortran-dev test.f90 
test.f90: In function 'myfortran_error':
test.f90:8:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2789
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I will work on this.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-24 20:36:57 |2009-10-07 14:09:36
   date||


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

[Bug fortran/41507] Documentation misleading on MAXLOC/MINLOC array type requirement

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2009-10-07 14:10 ---
I'll try to find some better formulation for the manual.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 14:10:34
   date||


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

[Bug fortran/38849] ICE in fold_convert with C_F_POINTER and C binding

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2009-10-07 14:12 ---
As another note, I already did the mistake of indexing a string as str(n)
instead of str(n:n) for single characters multiple times; and IIRC there's not
much useful a diagnostic in any case, so maybe I can improve there as well.


-- 


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-25 04:25:03 |2009-10-07 14:57:24
   date||


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

[Bug lto/41606] Not all types are fixed up

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-07 14:57 ---
It's mostly

 a) target specific builtin types and decls that do not get fixed up

 b) LTO (or rather generic) builtin functions and types not get fixed up

 c) the tree.c local canonical type machinery that isn't giving the same
answer as gimple_register_type () does.

with that "fixed" the sanity-checking patch works fine.

For a more proper patch I have to think about the tree.c type hashing
and unification some more.


-- 


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

[Bug target/41621] New: [4.4 regression] powerpc-linux-gnu 32bit testsuite regressions with -Os

[debian-gcc at lists dot debian dot org]

seen with builds from the 4.4 branch, compiler configured biarch, defaulting to
32bit; these testcase don't fail when the testsuite is run with -m64. Not seen
on trunk 20090803.

gcc is configured with: --with-pkgversion='Debian 4.4.1-5'
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-threads=posix --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-objc-gc --disable-softfloat
--enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux
--with-cpu=default32 --with-long-double-128 --enable-checking=release
--build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu

  Matthias

FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/memset-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/stpcpy-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/strcat-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/strcpy-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/strncat-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/strncpy-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -Os 
FAIL: gcc.c-torture/execute/921113-1.c execution,  -Os 
FAIL: gcc.c-torture/execute/pr24135.c execution,  -Os 
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -Os 
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -Os 
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -Os 
FAIL: gcc.c-torture/execute/va-arg-pack-1.c execution,  -Os 
WARNING: program timed out.
WARNING: program timed out.
WARNING: program timed out.
WARNING: program timed out.
WARNING: program timed out.
WARNING: program timed out.
FAIL: gcc.c-torture/execute/ieee/inf-2.c execution,  -Os 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/ieee/inf-3.c execution,  -Os 

gfortran (didn't check if all the fortran tests are in 4.3 as well). None of
these is failing with -m64:

Running target unix
FAIL: gfortran.dg/alloc_comp_assign_8.f90  -Os  execution test
FAIL: gfortran.dg/array_2.f90  -Os  execution test
FAIL: gfortran.dg/array_constructor_23.f  -Os  execution test
FAIL: gfortran.dg/array_constructor_24.f  -Os  execution test
FAIL: gfortran.dg/comma.f  -Os  execution test
FAIL: gfortran.dg/cray_pointers_2.f90  -Os  execution test
FAIL: gfortran.dg/cray_pointers_8.f90  -Os  execution test
FAIL: gfortran.dg/entry_13.f90  -Os  execution test
FAIL: gfortran.dg/entry_14.f90  -Os  execution test
FAIL: gfortran.dg/equiv_7.f90  -Os  execution test
FAIL: gfortran.dg/f2003_io_1.f03  -Os  execution test
FAIL: gfortran.dg/f2003_io_4.f03  -Os  execution test
FAIL: gfortran.dg/f2c_1.f90  -Os  execution test
FAIL: gfortran.dg/f2c_2.f90  -Os  execution test
FAIL: gfortran.dg/f2c_6.f90  -Os  execution test
FAIL: gfortran.dg/f2c_9.f90  -Os  execution test
FAIL: gfortran.dg/fmt_bz_bn.f  -Os  execution test
FAIL: gfortran.dg/fmt_float.f90  -Os  execution test
FAIL: gfortran.dg/fmt_missing_period_2.f  -Os  execution test
FAIL: gfortran.dg/func_derived_1.f90  -Os  execution test
FAIL: gfortran.dg/integer_exponentiation_2.f90  -Os  execution test
FAIL: gfortran.dg/integer_exponentiation_3.F90  -Os  execution test
FAIL: gfortran.dg/intrinsic_spread_1.f90  -Os  execution test
FAIL: gfortran.dg/namelist_11.f  -Os  execution test
FAIL: gfortran.dg/namelist_internal.f90  -Os  execution test
XPASS: gfortran.dg/nint_2.f90  -O0  execution test
FAIL: gfortran.dg/pack_mask_1.f90  -Os  execution test
FAIL: gfortran.dg/past_eor.f90  -Os  execution test
FAIL: gfortran.dg/pr19155.f  -Os  execution test
FAIL: gfortran.dg/pr35944-1.f90  -Os  execution test
FAIL: gfortran.dg/pr37243.f  -Os  execution test
FAIL: gfortran.dg/proc_decl_2.f90  -Os  execution test
FAIL: gfortran.dg/proc_ptr_1.f90  -Os  execution test
FAIL: gfortran.dg/proc_ptr_25.f90  -Os  execution test
FAIL: gfortran.dg/proc_ptr_3.f90  -Os  execution test
FAIL: gfortran.dg/random_3.f90  -Os  execution test
FAIL: gfortran.dg/reshape-alloc.f90  -Os  execution test
FAIL: gfortran.dg/scalar_mask_2.f90  -Os  execution test
FAIL: gfortran.dg/secnds-1.f  -Os  execution test
FAIL: gfortran.dg/streamio_8.f90  -Os  execution test
FAIL: gfortran.dg/streamio_9.f90  -Os  execution test
FAIL: gfortran.dg/subref_array_pointer_2.f90  -Os  execution test
FAIL: gfortran.dg/value_1.f90  -Os  execution test
FAIL: gfortran.dg/g77/dnrm2.f  -Os  execution test
FAIL: gfortran.dg/g77/f90-intrinsic-numeric.f  -Os  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-bessel.f  -Os  execution test
FAIL: gfortran.dg/g77/intrinsic-unix-erf.f  -Os  execution test
WARNING: program timed out.
WARNING: program tim

[Bug bootstrap/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2009-10-07 
15:09 ---
Subject: Re:  [4.5 Regression] Internal error compiling fortran/intrinsic.c

> > I see this has -g and this sounds like PR41343 where cc1 is killed because 
> > the
> > compiler runs out of VM . Could you try the same file without -g or without
> > var-tracking ? 
> 
> Didn't help.  I will try to figure out which change caused the regression.

It was introduced by revision 151348.

Dave


-- 


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

[Bug objc/41617] [4.4/4.5 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined

[doko at ubuntu dot com]

--- Comment #6 from doko at ubuntu dot com  2009-10-07 15:15 ---
Created an attachment (id=18740)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18740&action=view)
preprocessed source

regenerated with objc/NXConstStr.h included.


-- 

doko at ubuntu dot com changed:

   What|Removed |Added

  Attachment #18737|0   |1
is obsolete||


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

[Bug libstdc++/41622] New: [c++0x] std::hash::operator() copies its argument

[jbytheway at gmail dot com]

The following program:


#include 
#include 

int main()
{
  std::unordered_set set;
  std::string key("foo");

  for (int i=0; i<1000; ++i) {
set.count(key);
  }
  return 0;
}


(if compiled without optimizations) makes 1000 calls to the std::string copy
constructor (according to profiling by valgrind --tool=callgrind).  This is
because the std::hash::operator() takes its argument by value
rather than by const reference (see tr1_impl/functional_hash.h lines 164--166).

This slowed one of my programs by about 10-20%, the faster time being achieved
by using boost::hash instead of std::hash.  The boost
implementation takes its argument by const reference (See
http://gitorious.org/boost/svn/blobs/750d0927ebb5adc7f4150c854305e5e28924d747/boost/functional/hash/hash.hpp
lines 351--369 and line 389).  I believe libstdc++ should follow this lead on
performance grounds.  String keys for unordered associative containers are a
very common use case, and it seems silly not to make them as fast as possible.

Looking at a draft standard (N2914, [unord.hash]) it does seem to suggest that
std::hash::operator() must take its argument by value, but my standard-fu is
insufficient to be sure if it's really insisting.

As evidence that the change is OK:

- boost::hash claims in its documentation
(http://www.boost.org/doc/libs/1_40_0/doc/html/hash.html) to be compliant with
TR1, linking to N1836, in which [tr.unord.hash] has essentially the same
content as the draft standard.  I would expect Boost to get this right,
therefore I conclude that it is acceptable to use a const reference argument.

- If you were specializing std::hash for a movable-but-not-copyable type, then
it would be impossible to take the argument by value.  The standard certainly
seems to imply that Key types need not be copyable.

- The only obvious constraint on user-supplied hash functions is "A hash
function is a function object that takes a single argument of type Key and
returns a value of type std::size_t." ([unord.req], p4); it doesn't insist on
taking the argument by value.


-- 
   Summary: [c++0x] std::hash::operator() copies its
argument
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbytheway at gmail dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug libstdc++/41622] [c++0x] std::hash::operator() copies its argument

[jbytheway at gmail dot com]

--- Comment #1 from jbytheway at gmail dot com  2009-10-07 15:45 ---
Created an attachment (id=18741)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18741&action=view)
Patch providing proof-of-concept implementation

I attach a patch implementing this change on svn HEAD.  It doesn't break any
tests here, but I am fairly sure I've done the wrong thing to the linker script
(gnu.ver); I don't really understand the linker script, so it was rather
monkey-see-monkey-do.


-- 


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

[Bug libstdc++/41622] [c++0x] std::hash::operator() copies its argument

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2009-10-07 16:07 ---
(In reply to comment #1)
> but I am fairly sure I've done the wrong thing to the linker script
> (gnu.ver); I don't really understand the linker script, so it was rather
> monkey-see-monkey-do.

I think the commented out lines should not be there.
Commented out lines are usually used as placeholders for symbols which are
defined later, because more specific globs are needed e.g.

  std::basic_istr[a-d]*;
# std::basic_istream;
  std::basic_istr[f-z]*;

This is a hint that the istream symbols are handled elsewhere (the reason being
that some istream members are only present in C++0x and need to have a
different symbol version to the C++98 ones)


-- 


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

[Bug c/41610] Non-standard identifier's names

[hudson at comp dot ufla dot br]

--- Comment #4 from hudson at comp dot ufla dot br  2009-10-07 16:23 ---
Oh, yeah! I'm sorry!

I'll take care in the next time...
Thanks a lot!


-- 


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

[Bug libstdc++/41622] [c++0x] std::hash::operator() copies its argument

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-10-07 16:42 
---
Nope. This library follows the ISO Standards ad TRs, and both the current CD
and TR1 mandates by value. I can try to raise the issue in Santa Cruz by
certainly we can't just change the implementation like this.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/41622] [c++0x] std::hash::operator() copies its argument

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-10-07 16:51 
---
Two very general comments: 1- Certainly, you can't change old exports like
this, you can only *add* exports at later version numbers; 2- If you mean to
contribute more to the library (that would be great!) I would suggest starting
as soon as possible the paperwork for Copyright Assignment
(http://gcc.gnu.org/contribute.html) by sending an email to
assignme...@gcc.gnu.org. Thanks!


-- 


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

[Bug c++/24985] caret diagnostics

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2009-10-07 16:56 ---

Beyond caret diagnostics there is also range info for the diagnostic location.

See:
http://clang.llvm.org/diagnostics.html


-- 


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

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2009-10-07 17:06 ---
(In reply to comment #9)
> Beyond caret diagnostics there is also range info for the diagnostic location.

See the patch and thread at

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

and the requested patch:

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

Feel free to take anything and do as you please.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-02-20 18:43:14 |2009-10-07 17:06:57
   date||


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

[Bug middle-end/22072] bizarre code for int*int/2 for -Os

[vmakarov at gcc dot gnu dot org]

--- Comment #15 from vmakarov at gcc dot gnu dot org  2009-10-07 17:18 
---
Subject: Bug 22072

Author: vmakarov
Date: Wed Oct  7 17:18:38 2009
New Revision: 152533

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152533
Log:
2009-10-07  Vladimir Makarov  

PR middle-end/22072
* ira-lives.c (check_and_make_def_conflict): Process all operands.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c


-- 


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

[Bug bootstrap/41620] [4.5 regression] Bootstrap failure

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-10-07 17:54 ---
Yep, reverting that patch fixes libjava build.  The patch incorrectly makes us
emit the abstract pre-cloning constructor.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 17:54:36
   date||


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

[Bug c++/39863] [c++0x] variadic templates : wrong error "mismatched argument pack lengths"

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 17:55:08
   date||


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

[Bug target/41512] dllexport broken on cygwin

[davek at gcc dot gnu dot org]

--- Comment #10 from davek at gcc dot gnu dot org  2009-10-07 17:55 ---
(In reply to comment #9)
> Fixed at revision 152511.
> 

  My tests (r.152512) have now run far enough to confirm that all the new FAILs
are fixed.  Thanks Danny!


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug fortran/41615] Bogus error message: "internal function" should be "module procedure"

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2009-10-07 18:13 ---
Subject: Bug 41615

Author: domob
Date: Wed Oct  7 18:13:28 2009
New Revision: 152534

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152534
Log:
2009-10-07  Daniel Kraft  

PR fortran/41615
* resolve.c (resolve_contained_fntype): Clarify error message for
invalid assumed-length character result on module procedures.

2009-10-07  Daniel Kraft  

PR fortran/41615
* gfortran.dg/assumed_charlen_function_6.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/assumed_charlen_function_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/41615] Bogus error message: "internal function" should be "module procedure"

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2009-10-07 18:15 ---
Fixed on trunk, now the message really prints "module procedure" for module
procedures.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/24985] caret diagnostics

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2009-10-07 18:31 ---
(In reply to comment #10)
> http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00459.html

That's a vasprintf patch, I don't see the connection.


-- 


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

[Bug c++/41623] New: ICE: emit_move_insn at expr.c 3162 when compiling template code.

[marvin dot decker at gmail dot com]

Internal compiler error reported with target code with linux gcc 4.* series
compilers.

Tried: 4.1.2, 4.2.2, 4.2.4, 4.3.4.  All fail.

Compiles fine in 3.4+.


-- 
   Summary: ICE: emit_move_insn at expr.c 3162 when compiling
template code.
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marvin dot decker at gmail dot com


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

[Bug middle-end/41623] ICE: emit_move_insn at expr.c 3162 when compiling template code.

[marvin dot decker at gmail dot com]

--- Comment #1 from marvin dot decker at gmail dot com  2009-10-07 18:37 
---
Created an attachment (id=18742)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18742&action=view)
Precompiled source demonstrating error with 4.*


-- 


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

[Bug c/41624] New: RFE: -fno-nested-functions

[ajax at redhat dot com]

Nested functions in C are a serious misfeature, for any number of reasons (some
of which are even in the manual).  They should be something a project should be
able to ban the use of at the language level, without forcing a switch to
strict non-gnu mode.

Also, unlike most g89 language features, they seriously impede the ability of
the parser to tell you where syntax errors occur.  As it is, a missing }
doesn't get noticed until the end of the compilation unit; non-nested-function
dialects of C can fail at exactly the nested function declaration.


-- 
   Summary: RFE: -fno-nested-functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajax at redhat dot com


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-10-07 18:56 ---
Subject: Bug 41038

Author: jason
Date: Wed Oct  7 18:56:28 2009
New Revision: 152536

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152536
Log:
PR c++/41038
* tree.c (build_qualified_name): Call convert_from_reference.

Added:
trunk/gcc/testsuite/g++.dg/template/scope3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/39863] [c++0x] variadic templates : wrong error "mismatched argument pack lengths"

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-10-07 18:56 ---
Subject: Bug 39863

Author: jason
Date: Wed Oct  7 18:56:39 2009
New Revision: 152537

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152537
Log:
PR c++/39863
* pt.c (tsubst_pack_expansion): Don't do anything now if we
have incomplete packs of different lengths.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic95.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/41624] RFE: -fno-nested-functions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-07 19:00 ---
I don't think they are a misfeature at all.  Ada for an example actually
requires nested functions even with the reasons we mention in the manual, that
is trampolines and such.  Fortran also has nested functions.

Now non local gotos are in my thoughts a more misfeature than nested functions.

Also some ABIs don't require a trampoline at all.  The PowerOpen/AIX/PowerPC64
Linux ABI does not require a trampoline and creates a function descriptor with
the needed chain pointer.


-- 


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

[Bug middle-end/41623] [4.3 Regression] ICE: emit_move_insn at expr.c 3162 when compiling template code.

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-07 19:03 ---
Confirmed.  Reduced testcase:

#include 
#include 
template< class Iter, class Aggregator > 
inline typename Aggregator::value_type 
aggregate( Iter first, Iter second, Aggregator p_arg ) {
};
template< class A, class V > struct sum_equals {
typedef V value_type;
};
template< class FUNC > class unary_aggregator {
public:
typedef FUNC functor_type;
typedef typename functor_type::value_type value_type;
unary_aggregator( const value_type & p_init = value_type(),
  const functor_type & p_func = functor_type() ) 
:m_value(p_init), m_functor(p_func){
}
value_type m_value;
functor_type m_functor;
};
template< class A, class V > struct accumulate 
: public unary_aggregator< sum_equals< A, V > > {
accumulate( const V & p_arg = V() )
:unary_aggregator< sum_equals< A, V > >( p_arg ){
}
};
int main( int, char ** ) {
std::vector< float > c_args(3);
std::cout << aggregate( c_args.begin(), c_args.end(), 
accumulate(0) ) << std::endl;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.3.4
  Known to work||3.4.6 4.4.1 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 19:03:07
   date||
Summary|ICE: emit_move_insn at  |[4.3 Regression] ICE:
   |expr.c 3162 when compiling  |emit_move_insn at expr.c
   |template code.  |3162 when compiling template
   ||code.
   Target Milestone|--- |4.3.5


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

[Bug c++/39863] [c++0x] variadic templates : wrong error "mismatched argument pack lengths"

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-10-07 19:32 ---
Subject: Bug 39863

Author: jason
Date: Wed Oct  7 19:31:56 2009
New Revision: 152538

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152538
Log:
PR c++/39863
* pt.c (tsubst_pack_expansion): Don't do anything now if we
have incomplete packs of different lengths.

PR c++/41038
* tree.c (build_qualified_name): Call convert_from_reference.

* pt.c (register_specialization): Push DECL_SOURCE_LOCATION to the
clones.

* decl.c (grok_special_member_properties): Only adjust
TYPE_HAS_COMPLEX_* if the function is defaulted in the class body.
(cp_finish_decl): Push DECL_DELETED_FN/DECL_DEFAULTED_FN to the
clones.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/defaulted13.C
  - copied unchanged from r152373,
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted13.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/variadic95.C
  - copied unchanged from r152537,
trunk/gcc/testsuite/g++.dg/cpp0x/variadic95.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/scope3.C
  - copied unchanged from r152537,
trunk/gcc/testsuite/g++.dg/template/scope3.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/cp/pt.c
branches/gcc-4_4-branch/gcc/cp/tree.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-10-07 19:32 ---
Subject: Bug 41038

Author: jason
Date: Wed Oct  7 19:31:56 2009
New Revision: 152538

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152538
Log:
PR c++/39863
* pt.c (tsubst_pack_expansion): Don't do anything now if we
have incomplete packs of different lengths.

PR c++/41038
* tree.c (build_qualified_name): Call convert_from_reference.

* pt.c (register_specialization): Push DECL_SOURCE_LOCATION to the
clones.

* decl.c (grok_special_member_properties): Only adjust
TYPE_HAS_COMPLEX_* if the function is defaulted in the class body.
(cp_finish_decl): Push DECL_DELETED_FN/DECL_DEFAULTED_FN to the
clones.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/defaulted13.C
  - copied unchanged from r152373,
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted13.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/variadic95.C
  - copied unchanged from r152537,
trunk/gcc/testsuite/g++.dg/cpp0x/variadic95.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/scope3.C
  - copied unchanged from r152537,
trunk/gcc/testsuite/g++.dg/template/scope3.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/cp/pt.c
branches/gcc-4_4-branch/gcc/cp/tree.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/39863] [c++0x] variadic templates : wrong error "mismatched argument pack lengths"

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-10-07 19:32 ---
Fixed for 4.4.2 and 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-10-07 19:33 ---
Fixed for 4.4.2 and 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/40283] [C++0x] Context-specific explicit conversion doesn't work

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-10-07 19:36 ---
Fixed for 4.5 (a few weeks ago).


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/40682] [C++0x] Require direct binding of short-lived references to rvalues

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-10-07 19:45 ---
Neither 4.4.1 nor 4.5 try to call the copy constructor in your example; I
believe I fixed this issue in 4.4.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/34219] [C++0x] gcc doesn't accept const members of variadic templates as const (regression)

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-10-07 19:50 ---
This was fixed long ago.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[andreast at gcc dot gnu dot org]

--- Comment #35 from andreast at gcc dot gnu dot org  2009-10-07 19:54 
---
Seems like powerpc-*-freebsd* is now also affected.
I have the -O1 patch in testing.
The newer binutils option is a nop since FreeBSD (has to) stay(s) on binutils
2.15.


-- 


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

[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

[potswa at mac dot com]

--- Comment #30 from potswa at mac dot com  2009-10-07 19:57 ---
The FSF receptionist says that the lawyer seems to have taken an unannounced
vacation this week. It's now three weeks since I requested the forms (and since
he confirmed my request). What is the timeframe we're shooting for?

On an unrelated note, I checked out the bidirectional iterator implementation a
couple weeks ago and it seems to be completely extraneous. The forward iterator
implementation is very similar to my algorithm, and performs exactly (n -
gcd(n,k)) swaps with a linear memory access pattern. The bidirectional
implementation always performs (n) swaps and sweeps over the memory range
twice, which hurts performance.

So, I'd argue for deleting the bidirectional iterator function and letting the
forward iterator function handle it.


-- 


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

[Bug middle-end/41625] New: no-ending memory allocation

[denis dot onischenko at gmail dot com]

system hang due to no-ending memory allocation when compiling this code


-- 
   Summary: no-ending memory allocation
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: denis dot onischenko at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug middle-end/41625] no-ending memory allocation

[denis dot onischenko at gmail dot com]

--- Comment #1 from denis dot onischenko at gmail dot com  2009-10-07 20:25 
---
Created an attachment (id=18743)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18743&action=view)
preprocessed file


-- 


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

[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement

[paolo dot carlini at oracle dot com]

--- Comment #31 from paolo dot carlini at oracle dot com  2009-10-07 20:25 
---
4.5.0 still seems a realistic target to me. I would suggest you using the time
it takes for the paperwork to complete (unfortunately, it *always* takes a lot
of time) to figure out a *minimal*, completely trustworthy set of changes,
maybe not the best one, still a noticeable improvement. Further changes can be
prepared for future releases.


-- 


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

[Bug middle-end/41625] no-ending memory allocation

[denis dot onischenko at gmail dot com]

--- Comment #2 from denis dot onischenko at gmail dot com  2009-10-07 20:27 
---
Created an attachment (id=18744)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18744&action=view)
console output


-- 


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

[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran

[davek at gcc dot gnu dot org]

--- Comment #15 from davek at gcc dot gnu dot org  2009-10-07 20:33 ---
Created an attachment (id=18745)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18745&action=view)
global log

(In reply to comment #14)
> Subject: Re:  Can't build libgomp without
>  --enable-languages=fortran
> 
> * davek at gcc dot gnu dot org wrote on Wed, Sep 30, 2009 at 11:26:26PM CEST:
> > --- Comment #13 from davek at gcc dot gnu dot org  2009-09-30 21:26 
> > ---
> > Created an attachment (id=18680)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18680&action=view) [edit]
> >  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18680&action=view)
> > "bash -x" log of configure script run
> 
> Hmm, from that I can't gather what $GFORTRAN was set to from the
> toplevel.  Do you have a global log?  It should be sufficient to
>   rm $target/libgomp/Makefile
>   make configure-target-libgomp SHELL=/bin/sh\ -x

  Attached.  Sorry about the delay.


-- 


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

[Bug middle-end/41625] no-ending memory allocation

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-07 20:51 ---
Likely a dup of PR41343


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||41343


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

[Bug bootstrap/41626] New: GCC does not bootstrap on powerpc64

[meissner at gcc dot gnu dot org]

GCC does not bootstrap on powerpc64.  It fails in the 2nd stage, when it links
build/gensupport.o.  On the powerpc, the statements:

static struct obstack obstack;
struct obstack *rtl_obstack = &obstack;

On the powerpc generate a reference to an unknown external 'obstack', while on
the x86_64, it generates 'obstack' as a bss item.  The option
-fkeep-static-consts does not help the issue.


-- 
   Summary: GCC does not bootstrap on powerpc64
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug bootstrap/41626] GCC does not bootstrap on powerpc64

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2009-10-07 21:14 
---
Created an attachment (id=18746)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18746&action=view)
Simplified test case that fails on the powerpc.


-- 


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

[Bug bootstrap/41626] [4.5 Regression] GCC does not bootstrap on powerpc64

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
Summary|GCC does not bootstrap on   |[4.5 Regression] GCC does
   |powerpc64   |not bootstrap on powerpc64
   Target Milestone|--- |4.5.0


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

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu dot org]

--- Comment #12 from manu at gcc dot gnu dot org  2009-10-07 21:25 ---
(In reply to comment #11)
> (In reply to comment #10)
> > http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00459.html
> 
> That's a vasprintf patch, I don't see the connection.
> 

Ops, bad first link. This is the correct:

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-10-07 17:06:57 |2009-10-07 21:25:54
   date||


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

[Bug c++/36816] [c++0x] error deducing template argument taking the address of rvalue reference template

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-10-07 21:27 ---
This is core issue 873,
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#873


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 21:27:37
   date||


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2009-10-07 21:32 
---
*** Bug 41625 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||denis dot onischenko at
   ||gmail dot com


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

[Bug middle-end/41625] no-ending memory allocation

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-07 21:32 ---
It is.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/41585] [OOP] Reject CLASS(T) as component of "TYPE :: T"

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-10-07 21:50 ---
This can be fixed by:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (Revision 152525)
+++ gcc/fortran/decl.c  (Arbeitskopie)
@@ -1465,7 +1465,7 @@ build_struct (const char *name, gfc_charlen *cl, g

   /* If the current symbol is of the same derived type that we're
  constructing, it must have the pointer attribute.  */
-  if (current_ts.type == BT_DERIVED
+  if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
   && current_ts.u.derived == gfc_current_block ()
   && current_attr.pointer == 0)
 {


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 21:50:03
   date||


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

[Bug fortran/41608] ICE with CLASS and invalid code

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-10-07 21:58 ---
The fix:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (Revision 152525)
+++ gcc/fortran/decl.c  (Arbeitskopie)
@@ -3751,7 +3751,8 @@ gfc_match_data_decl (void)
   if (m != MATCH_YES)
 return m;

-  if (current_ts.type == BT_DERIVED && gfc_current_state () != COMP_DERIVED)
+  if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
+  && gfc_current_state () != COMP_DERIVED)
 {
   sym = gfc_use_derived (current_ts.u.derived);

@@ -3771,7 +3772,8 @@ gfc_match_data_decl (void)
   goto cleanup;
 }

-  if (current_ts.type == BT_DERIVED && current_ts.u.derived->components ==
NULL
+  if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
+  && current_ts.u.derived->components == NULL
   && !current_ts.u.derived->attr.zero_comp)
 {


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-07 21:58:53
   date||


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

[Bug bootstrap/41626] [4.5 Regression] GCC does not bootstrap on powerpc64

[meissner at gcc dot gnu dot org]

--- Comment #2 from meissner at gcc dot gnu dot org  2009-10-07 22:00 
---
Subversion revision 152520 is the revision that breaks this.

The change in question is:
009-10-07  Jan Hubicka  

* lto-symtab.c (lto_cgraph_replace_node): Assert that inline clones has
no address taken.


-- 


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

[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-10-07 22:25 ---
This testcase works at -O0 but fails at -O1.


-- 

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 |2009-10-07 22:25:08
   date||


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

[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-07 22:34 ---
Reverting just the varpool.c file back to what it was, allows this testcase to
work.


-- 


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[amodra at bigpond dot net dot au]

--- Comment #36 from amodra at bigpond dot net dot au  2009-10-07 22:35 
---
Andreas, there is no way this bug can be fixed 100% in gcc, except perhaps if
you are willing to compile -static.  Source and/or compiler fixes only work to
the extent that they limit code+data size to less than 33M.  If you go over
that size, and are using the old-style bss plt with .eh_frame data, then you
start playing russian roulette.


-- 


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

[Bug c/41182] [4.5 Regression] Revision 145254 caused ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[jsm28 at gcc dot gnu dot org]

--- Comment #12 from jsm28 at gcc dot gnu dot org  2009-10-07 22:36 ---
Testing a patch.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-09-18 03:58:06 |2009-10-07 22:36:15
   date||


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

[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-10-07 22:37 ---
This part is what is causing it:
!   /* When reading back varpool at LTO time, we re-construct the queue in
order
!  to have "needed" list right by inserting all needed nodes into
varpool.
!We however don't want to re-analyze already analyzed nodes.  */
!   if (!analyzed)
!   {
! gcc_assert (!in_lto_p);
!   /* Compute the alignment early so function body expanders are
!already informed about increased alignment.  */
!   align_variable (decl, 0);

!   if (DECL_INITIAL (decl))
!   record_references_in_initializer (decl);
!   }

Moving the record_references_in_initializer outside of the !analyzed condition
allows this testcase to work.


-- 


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

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dh458 at oakapple dot net]

--- Comment #11 from dh458 at oakapple dot net  2009-10-07 22:42 ---
(In reply to comment #10)

> > Here is a patch from Adhemerval Zanella from our IBM LTC Performance team,
> > that "fixes" the problem for me and bootstraps (powerpc64-linux) and
> > regtests with no regressions.  Can someone else give this a try on their
> > system?

I can compile now the original source SPECmpi 129.tera_tf
but I still don't execute correctly.The variables Ro and Ets get undefined
somehow. Has anybody used any version of gfortran successfully to compile
and correctly execute all of SPECmpi ?


-- 


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

[Bug fortran/41627] New: mixing common and modules elicits seg fault

[dh458 at oakapple dot net]

Using a (patched) 4.4.1 gofortran on linux/x86, try to compile the attached
tcommon.f90

I get

gfortran /tmp/tcommon.f90
/tmp/tcommon.f90: In function 'tf_ad_splitting_driver_plane':
/tmp/tcommon.f90:109: internal compiler error: Segmentation fault

This was incidentally uncovered while trying to work around bug 40737.
Mixing common and modules is not good practice, but it shouldn't core dump.


-- 
   Summary: mixing common and modules elicits seg fault
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dh458 at oakapple dot net


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