[Bug c++/36767] New: Segmentation fault with -fprofile-arcs -O2

[gcc at dpinol dot com]

Hi,

The code at the bottom compiled with this line
  gcc -fprofile-arcs -O2  -c kk.cpp
causes this crash
  gcc: Internal error: Segmentation fault (program cc1plus)

It occurs on both:
 * Suse 11.0 with gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036] (rpms: gcc43-4.3.1_20080507-6.1 and gcc-c++-4.3-39.1)

 * gcc 4.3.1 compiled with default options on Suse 10.2

best regards

#include 


class PathElement {

public:
float a;

~PathElement() {}
};

class PathPlanning {

public:

std::vector v;

PathPlanning();
};
PathPlanning offset2[2];


-- 
   Summary: Segmentation fault with -fprofile-arcs -O2
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at dpinol dot com


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

[Bug c++/36768] New: Segmentation fault with -fprofile-arcs -O2

[gcc at dpinol dot com]

Hi,

The code at the bottom compiled with this line
  gcc -fprofile-arcs -O2  -c kk.cpp
causes this crash
  gcc: Internal error: Segmentation fault (program cc1plus)

It occurs on both:
 * Suse 11.0 with gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036] (rpms: gcc43-4.3.1_20080507-6.1 and gcc-c++-4.3-39.1)

 * gcc 4.3.1 compiled with default options on Suse 10.2

best regards

#include 


class PathElement {

public:
float a;

~PathElement() {}
};

class PathPlanning {

public:

std::vector v;

PathPlanning();
};
PathPlanning offset2[2];


-- 
   Summary: Segmentation fault with -fprofile-arcs -O2
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at dpinol dot com


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

Sell Cisco Systems equipment items

[[EMAIL PROTECTED]]

Hello,
 We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale 
If you are interested, pls feel free to contact me.
example of the products:
CWDM-SFP-1G 38dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm 
WS-G5483,
GLC-SX-MM
SFP-GE-L
WS-G5487,
WS-G5484,
WS-G5486,
GLC-SX-MM,
GLC-LH-SM,
GLC-ZX-SM,
GLC-T,
..
NM-2FE2W-T1,
NM-2FE2W-E1,
NM-2FE2W-V2,
WIC-1T,
WIC-2T,
WIC-2A/S,
WIC-1B/ST,
WIC-1ENET,
VWIC-1MFT-T1,
VWIC-1MFT-E1,
VWIC-2MFT-T1,
VWIC-2MFT-E1,
VWIC-1MFT-G703,
VWIC-2MFT-G703,
VWIC-1MFT-T1-DI,
VWIC-2MFT-T1-DI,
NM-1E,
NM-4E,
..
WS-C2950-24,
WS-C2950T-24,
WS-C2950G-24-EI,
WS-C2950G-48-EI,
..
CONSOLE CABLE,
CAB-STACK-1M/3M,
CAB-V35MT,
CAB-V35FC,
CAB-SS-V.35MT,
CAB-SS-V.35FC,
CAB-SS-232MT,
CAB-SS-232FC,
CAB-232MT,
CAB-232FC,
CAB-SS-X21MT,
CAB-SS-X21FC,
CAB-X21MT,
..
MEM-npe400-512MB,
MEM-3660-128mb, 
MEM2600-32D, 
MEM2600-16FS, 
MEM2600XM-64D, 
MEM-S1-128MB, 
MEM-S2-256MB, 
MEM-S2-512MB, 
MEM-MSFC-128MB, 
MEM2801-256D, 
MEM3800-256D, 
MEM3800-512, 
MEM3745-256D, 
MEM1841-256D, 
MEM180X-256D, 
WS-X6K-MSFC2-KIT, 

and so on. 
Regards
Helen.Zhou
NEWSTAR NETWORKING TECHNOLOGY
www.nstnetwork.com
MSN:   [EMAIL PROTECTED]
Email: [EMAIL PROTECTED]
AOL helenxuezhou
Icq 320-880-606

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2008-07-09 11:13 
---
(In reply to comment #6)
> Subject: Re:  Simple std::bind use causes warnings with -Wextra
> 
> paolo dot carlini at oracle dot com wrote:
> 
> > Thanks Tom. In fact, yesterday I was writing without remembering my past
> > analyses of this type of issue, with system header warnings not suppressed:
> > TREE_NO_WARNING is *not* generically uses for that. Everything boils down to
> > DECL_IN_SYSTEM_HEADER  on the decl instead.
> 
> Why is it reasonable for a libstdc++ header to return a cv-qualified 
> type, but not for user code to do so?
> 
> In general, the system-header hack is to work around things we don't 
> control; we need to accept weird code in  because the OS 
> distributor controls that, not us.  But, if it's not practical for 
> libstdc++ to avoid this warning, then it's probably not practical for 
> users to avoid it either, so then I wonder how beneficial the warning 
> is.  On the other hand, I'd expect that libstdc++ could just avoid the 
> warning, by using a traits class to strip the cv-qualifier?

I'm sorry Mark, I'm not sure to understand.

We are working under the assumption (result of past discussions) that, in
general, we do want to warn for return types which are CV-qualified void and
builtin types. Ok.

Now, we can certainly make the library a tad more complex and strip those
CV-qualifiers. Probably we'll do that, anyway, I'd like to ear Doug, the
original author, about it.

On the other hand, we have the #pragma for system headers which is currently
able to suppress *any* warning besides this one, having to do with return
types. Seems a separate question to me. It looks to me that the pragma should
suppress this warning too. Do you agree?

A final remark: for better and worse, our library is not currently
-Wsystem-headers clean, not only because we don't have control over the
underlying C library (that makes for a separate issue, rather annoying
sometimes) but also for other reasons, for example, at times, suppressing any
possible false positive would make the code much more complex (and I think we
all agree that we absolutely want to avoid warnings from inside the headers),
uncertainty about whether we do want a warning or not (e.g., the library would
not warn if a core DR is implemented), etc.


-- 


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

[Bug c++/36769] New: implicit conversion do not work

[jia3ep at gmail dot com]

Have to take place implicit convesion type1 to type2 to sss in function main()
in string:
 sss xxx = x;
But it works (workaround?) for only the following syntax:
 sss xxx( x );

All addition info follows (test4.ii includes all source required):

[EMAIL PROTECTED]:~/test$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

[EMAIL PROTECTED]:~/test$ uname -a
Linux zork.elvees.com 2.6.24-19-server #1 SMP Wed Jun 18 15:18:00 UTC 2008 i686
GNU/Linux

[EMAIL PROTECTED]:~/test$ g++ test4.cpp -save-temps
test4.cpp: In function 'int main()':
test4.cpp:16: error: conversion from 'type1' to non-scalar type 'sss' requested

[EMAIL PROTECTED]:~/test$ cat test4.ii
# 1 "test4.cpp"
# 1 ""
# 1 ""
# 1 "test4.cpp"
struct type1 {
  type1() {};
};

struct type2 {
 type2( const type1& ) {};
};

struct sss {
  sss( type2 ) {
 };
};

int main() {
 type1 x;
 sss xxx = x;

 return 0;
}


-- 
   Summary: implicit conversion do not work
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jia3ep at gmail dot com


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

[Bug c++/36567] Cannot use std::tr1::tie() with unordered_map<> of std::vector<>

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-07-09 11:18 
---
(In reply to comment #3)
> a) The problem does not exist on gcc 4.2 (Intel), but I do not have a 
> 4.2 PPC x-compiler - only 4.0. So I cannot confirm a x-compile issue in 4.2.

Ok.

> b) It would be very helpful if you would tell me GCC's support policy. 
> i.e. How far back from the latest release will bug reports be 
> considered? In this case, I've reported a bug only three minor releases 
> back of the latest [4.2 at the time] and you seem to be saying "too old".

Well, it's easy, we just closed 4_1-branch, 4_0-branch has been closed a lot of
time ago. That means, you can certainly find somehow a volunteer working on the
release branch you care about, but since the branch is closed, the fix will not
appear in any further official release from the branch.

> c) I identified the problem as "C++", but more correctly it is an STL 
> problem.

Wrongly. There is no "STL" mention in the C++ Standard in force (C++98 + TC1),
"STL" is a legacy acronym dating back to the HP / SGI times. The problem would
be, in case, libstdc++, that this our (GNU) implementation of the C++ Standard
Library.

> d) If and when I can reproduce the problem in a current release, I'll 
> let you know.

Ok. For now, I'm going to close this one, for lack, to date, of compelling
evidence. Thanks again.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/36769] implicit conversion do not work

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-07-09 11:41 ---
Only a single user-defined conversion is allowed in an implicit conversion
sequence, but the copy-initialization would require two.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/36769] implicit conversion do not work

[jia3ep at gmail dot com]

--- Comment #2 from jia3ep at gmail dot com  2008-07-09 12:30 ---
Please, look at the following code. There are the same conversions, but it's
compiles and works without any errors. In the following sample takes place
implicit conversion 'int' to 'double' and then copy-initialization(that
requires implicit conversion too).
That's have to work in all cases(with type1/type2 and with int/double) in one
way.

struct sss {
  sss( double ) {
  };
};

int main() {
 int x = 7;
 sss xxx = x;

 return 0;
}

And finnaly look at the sample with template class. It's may compile or not
depending on what type will be selected:
struct type1 {
  type1() {};
};

struct type2 {
  type2( const type1& ) {};
};

template
struct sss {
  sss( T ) {
  };
};

int main() {
 int i = 7;
 sss xxx = i; // int to double works!

 type1 t;
 sss xxx2 = t; // type1 to type2 leads to compile time error!

 return 0;
}


-- 

jia3ep at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/36767] Segmentation fault with -fprofile-arcs -O2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-07-09 12:32 ---
*** Bug 36768 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/36768] Segmentation fault with -fprofile-arcs -O2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-07-09 12:32 ---


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


-- 

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

[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-07-09 12:53 ---
This one blows the stack recursing through

#40147 0x0065fa9a in mangle_decl (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:2655
2655  tree id = get_identifier_nocopy (mangle_decl_string (decl));
(gdb) up
#40148 0x00d23724 in decl_assembler_name (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/tree.c:304
304 lang_hooks.set_decl_assembler_name (decl);
(gdb) 
#40149 0x006566c7 in write_unqualified_name (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:1104
1104write_source_name (DECL_ASSEMBLER_NAME (decl));
(gdb) up
#40150 0x0065471b in write_unscoped_name (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:884
884   write_unqualified_name (decl);
(gdb) 
#40151 0x006542d0 in write_name (decl=0x7f398018d0a0, 
ignore_local_scope=0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:818
818 write_unscoped_name (decl);
(gdb) 
#40152 0x00653b0c in write_encoding (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:738
738   write_name (decl, /*ignore_local_scope=*/0);
(gdb) 
#40153 0x00653329 in write_mangled_name (decl=0x7f398018d0a0, 
top_level=1 '\001')
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:708
708   write_encoding (decl);
(gdb) 
#40154 0x0065f6a4 in mangle_decl_string (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:2631
2631write_mangled_name (decl, true);
(gdb) 
#40155 0x0065fa9a in mangle_decl (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:2655
2655  tree id = get_identifier_nocopy (mangle_decl_string (decl));
(gdb) 
#40156 0x00d23724 in decl_assembler_name (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/tree.c:304
304 lang_hooks.set_decl_assembler_name (decl);
...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-07-09 12:53:06
   date||
Summary|Segmentation fault with -   |[4.3/4.4 Regression]
   |fprofile-arcs -O2   |Segmentation fault with -
   ||fprofile-arcs -O2
   Target Milestone|--- |4.3.2


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

[Bug c++/36769] implicit conversion do not work

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2008-07-09 13:06 ---
int->double is not a user-defined conversion, but a standard conversion.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/36759] C_LOC and characters greater then one in length.

[brtnfld at hdfgroup dot org]

--- Comment #5 from brtnfld at hdfgroup dot org  2008-07-09 14:24 ---
The behavior conforms to the standard:

For the C_LOC(X) function X must be interpretable and interpretable for a
character the standard says:

15.2.1 Interoperability of intrinsic types
  A Fortran intrinsic
4 type with particular type parameter values is interoperable with a C type if
the type and kind type
5 parameter value are listed in the table on the same row as that C type; if
the type is character, inter
6 operability also requires that the length type parameter be omitted or be
specified by an initialization
7 expression whose value is one.

so it conforms to the standard by requiring

CHARACTER(LEN=1, KIND=C_CHAR), TARGET :: chr(2)
or
CHARACTER(KIND=C_CHAR), TARGET :: chr(2)


-- 

brtnfld at hdfgroup dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[mmitchel at gcc dot gnu dot org]

--- Comment #8 from mmitchel at gcc dot gnu dot org  2008-07-09 14:28 
---
Paolo --

You're absolutely right; I'd not thought about the orthogonality between what
the library should do and how the compiler should behave.  I agree that the
patch is correct; go ahead check it in.

I was also trying to raise the issue of whether we think the warning is useful.
 If it's not practical to avoid the warning in the library, then I wonder if
it's practical to avoid it other generic-programming code.  But, I agree that
this is a separate issue.

Thanks,

-- Mark


-- 


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

[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-07-09 14:49 ---
(In reply to comment #3)
> > b = a(1:12)
> > Error: Different shape for array assignment at (1) on dimension 1 (1 and 12)
> > ? I don't have that many patches left.
> 
> Hmm, I currently get the same (with all gfortrans I have). I really wonder why
> I did not get this before. Let me recheck tomorrow.

Same thing here.

What doesn't raise a warning, but could, is

integer,allocatable :: a(:)
integer :: b(1)
allocate(a(12))
b = a
end


-- 


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

[Bug c/36770] New: PowerPC generated PTR code ineffiency

[gunnar at greyhound-data dot com]

GCC fails to generate efficient code for basic pointer operations.

Please have a look at this example:
***
test.c:
register int * src asm("r15");

int test( ){
  src[1]=src[0];
  src++;
}

main(){
}

***

compile the above with gcc -S -O3 test.c

shows us the following ASM output:

test:
mr 9,15
addi 15,15,4
lwz 0,0(9)
stw 0,4(9)
blr

compile with gcc -S -Os test.c
Gives this output
test:
mr 9,15
addi 15,15,4
lwz 0,0(9)
stw 0,4(9)
blr


As you can see both -O3 and -Os produce the same output.
The generated output is far from optimal.

GCC generates for the simple pointer operation this code:
mr 9,15
addi 15,15,4
lwz 0,0(9)
stw 0,4(9)

But GCC should rather generate this:
lwz 0,0(15)
stwu 0,4(15)


Two of the four instructions are unneeded.
We've here code with literally thousands of unneeded instructions generated
like this.


I very much hope that this information is helpful to you and that you can fix
this.

Many thanks in advance

Gunnar von Boehn


-- 
   Summary: PowerPC generated PTR code ineffiency
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 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=36770

[Bug fortran/36771] New: Non-Standard addition for C_LOC and character strings

[brtnfld at hdfgroup dot org]

Would it be possible to implement the non-standard extension for a character
argument X in C_LOC(X) to have a LEN >1. Most if not all the current Fortran
compilers provide this extension and I think it would be useful for other users
of gfortran as well.

The feature would allow:

CHARACTER(LEN=80, KIND=C_CHAR), TARGET :: X

f_ptr = C_LOC(X)

or for an assumed size character in a subroutine:

CHARACTER(LEN=*, KIND=C_CHAR), TARGET :: X

f_ptr = C_LOC(X)

Thanks


-- 
   Summary: Non-Standard addition for C_LOC and character strings
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brtnfld at hdfgroup dot org


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

[Bug c/36772] New: GCC generates impossible BRANCH instruction

[gunnar at greyhound-data dot com]

Andreas Schwab and Gunther Nikl have pointed out that GCC
will incorrectly create "on purpose" impossible branch instructions.

Reason Summary:
- GCC is able to simplify certain compares.
- GCC seems to be unable to correctly rewrite the corresponding branch
instructions.
- GCC thereby generates branches that are by definition impossible to do.

Example:

  void foo (unsigned long j)
  {
unsigned int i;
for (i = 0; i < (j>>5); ++i)
  ;
  }


In this example the generated code does include a compare with a variable that
is ZERO.

GCC correctly knows that it can simplify a compare against ZERO.
But GCC fails to correctly adapt the condition codes.

Background:
A compare of two unsigned variables can set the CARRY flag.
A compare against ZERO can never set the CARRY flag.

While GCC recognizes that it can rewrite a CMP with 0 ,
GCC does not rewrite the branch that checks for the Carry.

GCC hereby creates branches that include conditions that are known to be
impossible at compile time.


> The following link should be the thread about this issue 
> http://gcc.gnu.org/ml/gcc/2003-10/msg01236.html


The problem that we describe here leads to the following:
GCC creates branches that include impossible conditions.
GCC does not remove the impossible conditions.
GCC wants to rewrite the CMP with 0 with a more efficient code.
But the 68K backend need to forbid this.
Normally it would be possible to leave the CMP 0,variable simply away.
And all branches that test for a condition that could actually be set by a cmp
with 0 would be possible to evaluate.
But as GCC writes branches which include known impossible conditions leaving
the cmp away is not possible.
The CMP with 0 is explicitly needed to ensure that all flags are cleared to
ensure that the branches to known impossible conditions are not taken.


It would be great if you could fix the reason for this instead curing the
sympton.
As this would allow the backend to really remove the unneeded CMP instructions
thereby generating smaller and faster code.

Many thanks in advance

Gunnar von Boehn


-- 
   Summary: GCC generates impossible BRANCH instruction
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 GCC build triplet: m68k-linux-gnu
  GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug fortran/36751] assignment between allocatable arrays of different size causes glibc error

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-07-09 15:31 ---
(In reply to comment #2)

> I am not sure the code is valid.

It's not, as -fbounds-check will tell you:

$ gfortran -fbounds-check foo.f90
$ ./a.out
At line 15 of file foo.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of
array 'a2' (1/2)

You need -fbounds-check for this to be detected.  As this
test is only possible at run-time, checking in the absence
of -fbounds-check isn't done.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/33800] ICE-on-valid (segfault) on x86_64

[lloyd at randombit dot net]

--- Comment #3 from lloyd at randombit dot net  2008-07-09 15:39 ---
Seemingly fixed in 4.3.0 or 4.3.1, closing this pr. Tested attached testcase
with

$ g++ -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj
--enable-languages=c,c++,objc,obj-c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1'
Thread model: posix
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1) 

All cases that had failed with the 20070907 snapshot worked fine.


-- 

lloyd at randombit dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo at gcc dot gnu dot org]

--- Comment #9 from paolo at gcc dot gnu dot org  2008-07-09 15:46 ---
Subject: Bug 36760

Author: paolo
Date: Wed Jul  9 15:45:50 2008
New Revision: 137660

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137660
Log:
/cp
2008-07-09  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/36760
* pt.c (tsubst_function_type): Don't warn for type qualifiers
on function return type in case of system header.

/testsuite
2008-07-09  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/36760
* g++.dg/warn/pragma-system_header5.C: New.
* g++.dg/warn/pragma-system_header5.h: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/warn/pragma-system_header5.C
trunk/gcc/testsuite/g++.dg/warn/pragma-system_header5.h
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/36729] the parallel version of std::random_shuffle does not shuffle for OMP_NUM_THREADS=1

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-07-09 15:54 
---
Fixed for mainline and 4.3.2. Many thanks again for the PR!


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug tree-optimization/33928] [4.3/4.4 Regression] 22% performance slowdown from 4.2.2 to 4.3/4.4.0 in floating-point code

[lucier at math dot purdue dot edu]

--- Comment #34 from lucier at math dot purdue dot edu  2008-07-09 16:05 
---
Problem still exists with

euler-18% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../mainline/configure --enable-checking=release
--with-gmp=/pkgs/gmp-4.2.2/ --with-mpfr=/pkgs/gmp-4.2.2/
--prefix=/pkgs/gcc-mainline --enable-languages=c
--enable-gather-detailed-mem-stats
Thread model: posix
gcc version 4.4.0 20080708 (experimental) [trunk revision 137644] (GCC) 

Just checking whether recent changes happened to fix it.


-- 


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

[Bug libfortran/36773] New: zero-sized arrays with cshift and eoshift

[tkoenig at gcc dot gnu dot org]

$ cat cshift.f90
program main
  real, dimension(1,0) :: a,b
  print *,size(a),size(b)
  b = cshift(a,1)
end program main
$ gfortran cshift.f90
$ ./a.out
   0   0
Segmentation fault (core dumped)
$ cat eoshift.f90
program main
  real, dimension(1,0) :: a,b
  print *,size(a),size(b)
  b = eoshift(a,1)
end program main
$ gfortran eoshift.f90
$ ./a.out
   0   0
Segmentation fault (core dumped)
$


-- 
   Summary: zero-sized arrays with cshift and eoshift
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug c/36774] New: -Wmissing-prototypes triggers on nested functions

[mj at ucw dot cz]

When a nested function is compiled with -Wmissing-prototypes, the compiler
reports that the function lacks a prototype. A prototype with an `auto' storage
class silences the warning, but the usefulness of such a prototype is very
dubious.

The right solution seems to be to make the warning ignore nested functions
altogether.


-- 
   Summary: -Wmissing-prototypes triggers on nested functions
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mj at ucw dot cz
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/36774] -Wmissing-prototypes triggers on nested functions

[mj at ucw dot cz]

--- Comment #1 from mj at ucw dot cz  2008-07-09 16:10 ---
Created an attachment (id=15877)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15877&action=view)
A test case


-- 


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

[Bug middle-end/33262] Disappearing loop conditions

[mj at ucw dot cz]

--- Comment #2 from mj at ucw dot cz  2008-07-09 16:11 ---
Can I do anything to help catch the bug?


-- 


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

[Bug middle-end/33262] Disappearing loop conditions

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-07-09 16:19 ---
Try with a recent GCC 4.2 version - GCC 4.2.4 is available.  Also try
GCC 4.3.1.  Try to reduce the testcase or at least make it executable and
arrange for it to abort () whenever the problem appears.


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[bangerth at dealii dot org]

--- Comment #10 from bangerth at dealii dot org  2008-07-09 17:04 ---
(In reply to comment #8)
> I was also trying to raise the issue of whether we think the warning is 
> useful.
>  If it's not practical to avoid the warning in the library, then I wonder if
> it's practical to avoid it other generic-programming code.

I agree with this. As I mentioned in PR 30601, code like this

  template  class ArrayView {
T& operator();
T operator() const;
  };

is quite common and I don't see a need to make it more complicated than
necessary just for a warning. Yet, this class will trigger a warning if
instantiated as ArrayView because the return type of the second
operator() is now 'const double'. (Think of the class as providing a view
to a part of an array, so instantiating it with T=const double provides a
view that does not allow the elements to be modified.)

Personally, I find the fact that the compiler now warns about this very
annoying indeed.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2008-07-09 17:11 
---
Well I didn't want to reopen a discussion which I considered closed. But yes, I
also agree. And in case, we should have the change in 4_3-branch too. 


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2008-07-09 17:13 
---
And, by the way, I'm noticing the hard way that return by reference is the most
annoying case: if you want to suppress the warnings still deal appropriately
with references, it's a huge special casing everywhere, sigh.


-- 


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

[Bug target/36772] GCC generates impossible BRANCH instruction

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target


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

[Bug middle-end/36770] PowerPC generated PTR code ineffiency

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-09 18:22 ---
forward-propagate is causing some of the issues as shown by:
int *test(int *a ){
  a[1]=a[0];
  a++;
  return a;
}
But using the register extension is causing the rest :).  I would recommend
against using them in real code really, they are not that useful and cause too
many issues in general.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org, bonzini at gnu dot org
   Severity|major   |normal
 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-09 18:22:19
   date||


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[mark at codesourcery dot com]

--- Comment #13 from mark at codesourcery dot com  2008-07-09 19:08 ---
Subject: Re:  Simple std::bind use causes warnings with -Wextra

bangerth at dealii dot org wrote:
> --- Comment #10 from bangerth at dealii dot org  2008-07-09 17:04 ---
> (In reply to comment #8)
>> I was also trying to raise the issue of whether we think the warning is 
>> useful.
>>  If it's not practical to avoid the warning in the library, then I wonder if
>> it's practical to avoid it other generic-programming code.
> 
> I agree with this. As I mentioned in PR 30601, code like this
> 
>   template  class ArrayView {
> T& operator();
> T operator() const;
>   };
> 
> is quite common and I don't see a need to make it more complicated than
> necessary just for a warning.

Me neither.  I think writing:

   const int f();

or:

   template 
   const int f(T);

is probably worth warning about, but maybe we ought to just skip this 
warning when instantiating a template function.  In other words, warn at 
the point of original declaration of the template if it is already 
obviously meaningless at that point to add the cv-qualifier, but not 
warn at instantiation.


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2008-07-09 19:20 
---
(In reply to comment #13)
> is probably worth warning about, but maybe we ought to just skip this 
> warning when instantiating a template function.  In other words, warn at 
> the point of original declaration of the template if it is already 
> obviously meaningless at that point to add the cv-qualifier, but not 
> warn at instantiation.

Ah, I didn't consider this option! Seems also trivial to implement, just remove
completely the pt.c version of the warning and keep the one in decl.c. Then,
over the next hours, if I don't see objections, I'm going to implement and post
it, proposing it for 4_3-branch too, because of the very annoying warning from
 per this PR...


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[bangerth at dealii dot org]

--- Comment #15 from bangerth at dealii dot org  2008-07-09 19:22 ---
(In reply to comment #14)
> Ah, I didn't consider this option! Seems also trivial to implement, just 
> remove
> completely the pt.c version of the warning and keep the one in decl.c. Then,
> over the next hours, if I don't see objections, I'm going to implement and 
> post
> it, proposing it for 4_3-branch too, because of the very annoying warning from
>  per this PR...

I think that would be awesome!
W.


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #16 from paolo dot carlini at oracle dot com  2008-07-09 19:34 
---
Humm, this case

  template 
  const int i(T);

is a little more tricky, let's what I can do...


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #17 from paolo dot carlini at oracle dot com  2008-07-09 19:38 
---
Ignore my last message, I had a spurious #pragma system header in my
experiments. Great ;)


-- 


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

[Bug target/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[rsandifo at gcc dot gnu dot org]

--- Comment #6 from rsandifo at gcc dot gnu dot org  2008-07-09 20:04 
---
Subject: Bug 35802

Author: rsandifo
Date: Wed Jul  9 20:03:40 2008
New Revision: 137670

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137670
Log:
gcc/
PR target/35802
* config/mips/mips.h (reg_class): Remove V1_REG.
(REG_CLASS_NAMES, REG_CLASS_CONTENTS): Update accordingly.
* config/mips/mips.c (mips_regno_to_class): Map $3 to M16_NA_REGS
instead of V1_REGS.
(mips_get_tp): New function.
(mips_legitimize_tls_address): Use it.
* config/mips/constraints.md (v): Delete.
* config/mips/mips.md (TLS_GET_TP_REGNUM): New constant.
(tls_get_tp_): Allow any GPR destination and clobber $3.
After reload, split into a move and ...
(*tls_get_tp__split): ...this new instruction.

gcc/testsuite/
PR target/35802
* gcc.target/mips/pr35802.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr35802.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/constraints.md
trunk/gcc/config/mips/mips.c
trunk/gcc/config/mips/mips.h
trunk/gcc/config/mips/mips.md
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[rsandifo at gcc dot gnu dot org]

--- Comment #7 from rsandifo at gcc dot gnu dot org  2008-07-09 20:06 
---
Subject: Bug 35802

Author: rsandifo
Date: Wed Jul  9 20:06:20 2008
New Revision: 137671

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137671
Log:
gcc/
PR target/35802
* config/mips/mips.h (reg_class): Remove V1_REG.
(REG_CLASS_NAMES, REG_CLASS_CONTENTS): Update accordingly.
* config/mips/mips.c (mips_regno_to_class): Map $3 to M16_NA_REGS
instead of V1_REGS.
(mips_get_tp): New function.
(mips_legitimize_tls_address): Use it.
* config/mips/constraints.md (v): Delete.
* config/mips/mips.md (TLS_GET_TP_REGNUM): New constant.
(tls_get_tp_): Allow any GPR destination and clobber $3.
After reload, split into a move and ...
(*tls_get_tp__split): ...this new instruction.

gcc/testsuite/
PR target/35802
* gcc.target/mips/pr35802.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/mips/pr35802.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/mips/constraints.md
branches/gcc-4_3-branch/gcc/config/mips/mips.c
branches/gcc-4_3-branch/gcc/config/mips/mips.h
branches/gcc-4_3-branch/gcc/config/mips/mips.md
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[rsandifo at gcc dot gnu dot org]

--- Comment #8 from rsandifo at gcc dot gnu dot org  2008-07-09 20:08 
---
Patch applied.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-07-09 20:34 ---
The current fork/exec implementation is incorrect. Basically, it
re-implements system (). It is tricky to get it 100% correct. One
can take a look at system () source to see it him/herself.  I think
we should call chmod directly, rather than fix fork/exec.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Severity|enhancement |normal


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

[Bug c/36775] New: Incorrect code generated - value tested before it is set.

[sfalco at harris dot com]

I have found a bug in the gcc cross-compiler supplied in eldk-4.2 for
ppc_4xxFP-gcc.  (Available from http://denx.de)

I noticed that the dumpe2fs program segfaulted on my sequoia powerpc evaluation
board (running Linux with nfs as the rootfs).  After a lot of detective work, I
have produced a small program that illustrates the problem.

I'll attach the .i file along with the -v output.  I'll also attach a dump of
the executable.

The bug is that the compiler collapses two "if" tests together, but in doing
so, it tests a value before assigning to it.

The two "if" statements are:

if (!*pp)   /* function ext2fs_get_mem */
if (!bb->list) {/* function make_u32_list */

The following section of the dump shows the problem (this correlates to the
second malloc in routine make_u32_list():

14c4:   48 04 05 d5 bl  10040a98 <[EMAIL PROTECTED]>
14c8:   81 61 00 08 lwz r11,8(r1)
14cc:   7c 60 fe 70 srawi   r0,r3,31
14d0:   7c 09 1a 78 xor r9,r0,r3
14d4:   83 eb 00 0c lwz r31,12(r11) /* copies bb->list into
r31 too early */
14d8:   7d 29 00 50 subfr9,r9,r0
14dc:   3c 00 80 d4 lis r0,-32556
14e0:   7d 3d fe 70 srawi   r29,r9,31
14e4:   60 00 48 ba ori r0,r0,18618
14e8:   2f 9f 00 00 cmpwi   cr7,r31,0   /* tests uninitialized
version of bb->list */
14ec:   7f bd 00 38 and r29,r29,r0
14f0:   3d 3d 7f 2c addis   r9,r29,32556
14f4:   90 7c 00 0c stw r3,12(r28)  /* bb->list finally
receives malloc pointer here */

At 14c4 we call malloc, and the return value is in r3.  The "if"
test appears at 14e8 and checks r31.  Looking back at 14d4 we
see bb->list is loaded into r31.  However, r3 is not loaded into bb->list
until 14f4, long after bb->list has been used.


-- 
   Summary: Incorrect code generated - value tested before it is
set.
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfalco at harris dot com
  GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: powerpc-linux


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

[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-09 20:48 ---
> The current fork/exec implementation is incorrect.

How is it incorrect?  Since file could have spaces in it, using system is not
useful at all and even harder to do the correct thing.  Really it does not use
system because creating a string to use with system makes it even more
incorrect than it is currently.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c/36775] Incorrect code generated - value tested before it is set.

[sfalco at harris dot com]

--- Comment #1 from sfalco at harris dot com  2008-07-09 20:49 ---
Created an attachment (id=15878)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15878&action=view)
Source code .i file


-- 


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

[Bug c/36775] Incorrect code generated - value tested before it is set.

[sfalco at harris dot com]

--- Comment #2 from sfalco at harris dot com  2008-07-09 20:50 ---
Created an attachment (id=15879)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15879&action=view)
Output of the -v option to the compiler


-- 


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

[Bug c/36775] Incorrect code generated - value tested before it is set.

[sfalco at harris dot com]

--- Comment #3 from sfalco at harris dot com  2008-07-09 20:51 ---
Created an attachment (id=15880)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15880&action=view)
Object dump


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo at gcc dot gnu dot org]

--- Comment #18 from paolo at gcc dot gnu dot org  2008-07-09 20:53 ---
Subject: Bug 36760

Author: paolo
Date: Wed Jul  9 20:52:45 2008
New Revision: 137672

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137672
Log:
/cp
2008-07-09  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/36760
* pt.c (tsubst_function_type): Remove warning for type qualifiers
on function return type.

/testsuite
2008-07-09  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/36760
* g++.dg/warn/Wreturn-type-4.C: Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wreturn-type-4.C


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[paolo dot carlini at oracle dot com]

--- Comment #19 from paolo dot carlini at oracle dot com  2008-07-09 20:55 
---
Fixed for 4.4.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug c++/36776] New: Internal compiler error with template/pointer to member functions

[maksverver at geocities dot com]

I first encountered this problem with GCC 4.3.1. With that compiler, the
program compiles fine (without warnings) but crashes at runtime. I tried a
recent snapshot of version 4.4 before submitting a bug report, and there an
internal compiler error is produced instead. So although this bug report is
filed for 4.4, a similar bug is present in at least 4.3.1 (and probably
others).

I don't really understand what causes the bug, so I'll just give you the source
code for a (self-contained, simplified) test case that causes the internal
compiler error along with my output, and hope you are able to figure it out.
;-)

$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4-20080704/configure
--prefix=/home/maks/gcc-4.4-20080704
Thread model: posix
gcc version 4.4.0 20080704 (experimental) (GCC)

$ g++ -c -Wall -Wextra bug.cpp
bug.cpp: In function ‘void invoke() [with C = Foo, void (C::* M)() =
method]’:
bug.cpp:9: internal compiler error: in expand_expr_real_1, at expr.c:7279
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: Internal compiler error with template/pointer to member
functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maksverver at geocities 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=36776

[Bug c++/36776] Internal compiler error with template/pointer to member functions

[maksverver at geocities dot com]

--- Comment #1 from maksverver at geocities dot com  2008-07-09 20:57 
---
Created an attachment (id=15881)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15881&action=view)
The test case that produces the output described in the bug summary.


-- 


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

[Bug middle-end/36775] Incorrect code generated - value tested before it is set.

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-07-09 21:04 ---
This looks like an aliasing violation.What happens if you compile with -O2
-fno-strict-aliasing ?


-- 


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

[Bug middle-end/36775] Incorrect code generated - value tested before it is set.

[sfalco at harris dot com]

--- Comment #5 from sfalco at harris dot com  2008-07-09 21:08 ---
That works.  Here is what the generated code looks like.  As you can see, r3 is
immediately stored to bb->list, which is what I would expect.

14c0:   48 04 05 d1 bl  10040a90 <[EMAIL PROTECTED]>
14c4:   90 7d 00 0c stw r3,12(r29)
14c8:   7c 60 fe 70 srawi   r0,r3,31
14cc:   81 61 00 08 lwz r11,8(r1)
14d0:   7c 09 1a 78 xor r9,r0,r3
14d4:   83 8b 00 0c lwz r28,12(r11)
14d8:   7d 29 00 50 subfr9,r9,r0
14dc:   3c 00 80 d4 lis r0,-32556
14e0:   7d 3d fe 70 srawi   r29,r9,31
14e4:   60 00 48 ba ori r0,r0,18618
14e8:   2f 9c 00 00 cmpwi   cr7,r28,0
14ec:   7f bd 00 38 and r29,r29,r0
14f0:   3d 3d 7f 2c addis   r9,r29,32556
14f4:   3b a9 b7 46 addir29,r9,-18618
14f8:   41 9e 00 2c beq-cr7,1524



-- 


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

[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-07-09 21:18 ---
(In reply to comment #3)
> > The current fork/exec implementation is incorrect.
> 
> How is it incorrect?  Since file could have spaces in it, using system is not
> useful at all and even harder to do the correct thing.  Really it does not use
> system because creating a string to use with system makes it even more
> incorrect than it is currently.
> 

It should handle signal and check return from wait to match pid.


-- 


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

[Bug ada/36777] New: Protected type cannot have access taken from its body.

[prog at msobczak dot com]

Protected type cannot have access taken from its body.
The following should work:

   protected type P is
  procedure Foo;
   end P;

   protected body P is
  procedure Foo is
 Ptr : access P;  -- here P denotes the type P
  begin
 Ptr := P'Access; -- here P denotes the "this" instance of P
  end;
   end P;

The compiler complains that 'Access cannot be applied to a type, which is in
conflict with AARM 9.4-21/2.


-- 
   Summary: Protected type cannot have access taken from its body.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prog at msobczak dot com


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

[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Severity|enhancement |minor


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

[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-07-09 21:24 ---
Here is one working implementation:

http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/posix/system.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=glibc


-- 


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

[Bug middle-end/36775] Incorrect code generated - value tested before it is set.

[schwab at suse dot de]

--- Comment #6 from schwab at suse dot de  2008-07-09 21:30 ---
extern __inline__ errcode_t ext2fs_get_mem(unsigned long size, void *ptr)
{
 void **pp = (void **)ptr;

 *pp = malloc(size);
[...]
}
[...]
{
 ext2_u32_list bb;
 errcode_t retval;

 retval = ext2fs_get_mem(sizeof(struct ext2_struct_u32_list), &bb);

This is writing a value of type void* through a pointer to a different type
(ext2_u32_list).


-- 


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

[Bug middle-end/36775] Incorrect code generated - value tested before it is set.

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-07-09 21:50 ---
Not a bug as the code violates aliasing rules.


-- 

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

[Bug c++/36778] New: [feature request] -Wfatal-warnings

[gcc-bugzilla at contacts dot eelis dot net]

Gcc has a versatile set of warning/error flags that let one tune its behavior,
but there is one thing that it seems is currently not supported: the ability to
have gcc abort on the first diagnostic, without losing information about
whether that diagnostic is a warning or an error.

One can use -Werror -Wfatal-errors to get abortion on the first diagnostic, but
then warnings like "suggest parentheses around && within ||" are reported as
errors.

Ideally, there would be a flag -Wfatal-warnings, which would cause the compiler
to abort compilation on the first warning. One could then use -Wfatal-errors
-Wfatal-warnings to get abortion on the first diagnostic without losing
information about whether that diagnostic is a warning or an error.

While I believe this feature would be more generally useful, the particular use
case I'm requesting this for is geordi ( http://www.eelis.net/geordi/ ), a
popular educational IRC C++ bot which compiles C++ code snippets with gcc and
reports the first diagnostic (if any). Since only the first diagnostic is
needed, geordi uses -Werror -Wfatal-errors to reduce its response time, but
this means it misreports warnings like the one mentioned above, as errors.
Having -Wfatal-warnings would trivially solve this without imposing a
responsiveness penalty.

I realize this request might be a bit of a stretch, but I thought I'd give it a
shot. Thanks for your time.


-- 
   Summary: [feature request] -Wfatal-warnings
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36778] [feature request] -Wfatal-warnings

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug other/36779] New: make pdf fails if done before another make

[hal at oz dot net]

This is pretty trivial, but it would be nice to fix.

I tried to generate the pdf documents for gcc 4.3.1 on an x86 running fedora 9
without building gcc first.  I ran configure with no options (in a separate
directory from the gcc source tree), then "make pdf".  It generated a lot of
the pdf documents, but then quit in one of the subdirectories because
./gcc/xgcc didn't exist.  Here's the tail end of the console output:

Checking multilib configuration for libgomp...
mkdir -p -- i686-pc-linux-gnu/libgomp
Configuring in i686-pc-linux-gnu/libgomp
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
/home/perkins/src/gcc-4.3.1/libgomp/configure: line 2167:
/home/perkins/src/gcc-4.3.1-build/./gcc/xgcc: No such file or directory
checking for i686-pc-linux-gnu-gcc...
/home/perkins/src/gcc-4.3.1-build/./gcc/xgcc
-B/home/perkins/src/gcc-4.3.1-build/./gcc/ -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
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libgomp] Error 1
make[1]: Leaving directory `/home/perkins/src/gcc-4.3.1-build'
make: *** [do-pdf] Error 2


-- 
   Summary: make pdf fails if done before another make
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hal at oz dot net


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

[Bug other/36779] make pdf fails if done before another make

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-09 22:31 ---
I think this is by design.


-- 


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

[Bug other/36779] make pdf fails if done before another make

[hal at oz dot net]

--- Comment #2 from hal at oz dot net  2008-07-09 22:36 ---
Fair enough, but if that's the case, it'd be better to generate a "you can't do
that - make the compiler first" message and quit gracefully.

BTW, this used to not work at all, but now make pdf does work in gcc/doc and
libiberty without a previous make.  Feature or bug?

Thanks


-- 


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

[Bug c++/36633] [4.4 regression] warning "array subscript is below array bounds" on delete [] with -O2, -Wall

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2008-07-09 22:49 
---
Mark, could you possibly comment on this PR? With some good hints I could even
try to work on it...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-06-13 23:06:13 |2008-07-09 22:55:31
   date||


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

[Bug libstdc++/36552] includes itself: ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2008-07-10 00:06 ---
Subject: Bug 36552

Author: bkoz
Date: Thu Jul 10 00:05:27 2008
New Revision: 137677

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137677
Log:
2008-07-09  Andreas Beckmann  <[EMAIL PROTECTED]>

PR libstdc++/36552
* include/ext/pb_ds/detail/left_child_next_sibling_heap_/
null_metadata.hpp: Remove self-include.


Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp


-- 


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

[Bug libstdc++/36552] includes itself: ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2008-07-10 00:38 ---
Subject: Bug 36552

Author: bkoz
Date: Thu Jul 10 00:38:13 2008
New Revision: 137682

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137682
Log:
2008-07-09  Andreas Beckmann  <[EMAIL PROTECTED]>

PR libstdc++/36552
* include/ext/pb_ds/detail/left_child_next_sibling_heap_/
null_metadata.hpp: Remove self-include.


Modified:
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_3-branch/libstdc++-v3/include/ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp


-- 


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

[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32

[nightstrike at gmail dot com]

--- Comment #6 from nightstrike at gmail dot com  2008-07-10 00:49 ---
Kai, can you apply FX's fix?


-- 


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

[Bug libstdc++/36552] includes itself: ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp

[bkoz at gcc dot gnu dot org]

--- Comment #4 from bkoz at gcc dot gnu dot org  2008-07-10 01:05 ---
Mine


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-10 01:05:50
   date||


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

[Bug libstdc++/36552] includes itself: ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2008-07-10 01:06 ---
fixed for 4.3.2


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libstdc++/36543] Precompiled headers are not installed

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2008-07-10 01:10 ---

This is by design. It turns out that PCH files vary enough system-to-system
that rebuilding them on a per-computer basis is necessary. Thus, schlepping
around 20-40MB files is of limited value.

Instead, we are now advocating the following:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch03s02.html#manual.intro.using.headers.pre

Let me know if you have something better in mind, or have improvements to the
docs.

best,
-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/36780] New: [4.3/4.4 Regression] Wrong reload generated for subreg address on SH

[kkojima at gcc dot gnu dot org]

For trunk and 4.3-branch, bootstrapping on SH fails during building
libstdc++-v3

/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:559:
error: insn does not satisfy its constraints:
(insn 2055 2054 716 106
/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:473
(set (reg:SI 2 r2)
(plus:SI (reg:SI 3 r3)
(const_int 40 [0x28]))) 35 {*addsi3_compact} (nil))
/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:559:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:395

It starts to fail after the patch

r137639 | jsm28 | 2008-07-09 05:23:56 +0900 (Wed, 09 Jul 2008) | 3 lines

* reload.c (find_reloads_subreg_address): Do not require validity
of address in original mode before reloading address.

is applied.


-- 
   Summary: [4.3/4.4 Regression] Wrong reload generated for subreg
address on SH
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh-*-*


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

[Bug libstdc++/36505] C++ includes do not work

[bkoz at gcc dot gnu dot org]

--- Comment #4 from bkoz at gcc dot gnu dot org  2008-07-10 01:24 ---

This is pretty suspicious, in that C++ on x86/linux for the 4.3.1 release is
well-trod territory and if stdlib.h was missing, many other people would be
seeing this too.

That leads me to think that this is probably some oddity in your configure or
setup of your source/build dirs, or NFS issues, or something like that.

>From your report: 

Configured with: /home/pa01/ws/syde/MAIN/ext/src/gcc-4.3.1/configure
--prefix=/home/pa01/ws/syde/MAIN/ext

I'm not quite sure what's up here, but one thing you could try is to
double-check the setup of your source, build, and install directories. (It
looks like you install into an enclosing directory for the sources.)

Something like:

/home/pa01/ws/syde/MAIN/ext/src/gcc-4.3.1
/home/pa01/ws/syde/MAIN/ext/bld/gcc-4.3.1
/home/pa01/ws/syde/MAIN/ext/installed/gcc-4.3.1

is a more typical setup.

best,
benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||i686-pc-linux-gnu


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

[Bug target/36780] [4.3/4.4 Regression] Wrong reload generated for subreg address on SH

[kkojima at gcc dot gnu dot org]

--- Comment #1 from kkojima at gcc dot gnu dot org  2008-07-10 01:27 ---
Created an attachment (id=15882)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15882&action=view)
A reduced test case for -O0

Before r137639, the insn in problem was

(insn 200 330 331 20 yyy.cc:181 (set (mem/c:SI (plus:SI (reg:SI 6 r6)
(const_int 0 [0x0])) [0 D.2244+4 S8 A32])
(reg:SI 1 r1 [261])) 175 {movsi_ie} (nil))

and now the memory address is reloaded like as

(insn 331 330 200 20 xxx.cc:181 (set (reg:SI 2 r2)
(plus:SI (reg:SI 6 r6)
(const_int 0 [0x0]))) 35 {*addsi3_compact} (nil))

(insn 200 331 332 20 xxx.cc:181 (set (mem/c:SI (reg:SI 2 r2) [0 D.2244+4 S8
A32])
(reg:SI 1 r1 [261])) 175 {movsi_ie} (nil))

but SH has no add instruction whose destination and source differs.


-- 


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

[Bug libstdc++/36451] Broken links in libstdc++ online documentation

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2008-07-10 01:31 ---

Thanks for providing feedback on the docs.

Yes, you are correct about the broken links. Fixing...


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-10 01:31:28
   date||


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

[Bug libstdc++/36451] Broken links in libstdc++ online documentation

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2008-07-10 01:42 ---
Subject: Bug 36451

Author: bkoz
Date: Thu Jul 10 01:41:29 2008
New Revision: 137685

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137685
Log:
2008-07-09  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/36451
* doc/xml/manual/allocator.xml: Fix links.
* doc/html/*: Regenerate.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/html/api.html
trunk/libstdc++-v3/doc/html/manual/abi.html
trunk/libstdc++-v3/doc/html/manual/api.html
trunk/libstdc++-v3/doc/html/manual/backwards.html
trunk/libstdc++-v3/doc/html/manual/bitmap_allocator.html
trunk/libstdc++-v3/doc/html/manual/bk01pt01ch01.html
trunk/libstdc++-v3/doc/html/manual/bk01pt01ch03s02.html
trunk/libstdc++-v3/doc/html/manual/bk01pt02pr01.html
trunk/libstdc++-v3/doc/html/manual/bk01pt04ch11.html
trunk/libstdc++-v3/doc/html/manual/bk01pt06ch14.html
trunk/libstdc++-v3/doc/html/manual/bk01pt06ch15.html
trunk/libstdc++-v3/doc/html/manual/bk01pt09pr02.html
trunk/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html
trunk/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html
trunk/libstdc++-v3/doc/html/manual/bk01pt12pr03.html
trunk/libstdc++-v3/doc/html/manual/codecvt.html
trunk/libstdc++-v3/doc/html/manual/messages.html
trunk/libstdc++-v3/doc/html/manual/parallel_mode.html
trunk/libstdc++-v3/doc/html/manual/shared_ptr.html
trunk/libstdc++-v3/doc/html/manual/spine.html
trunk/libstdc++-v3/doc/xml/manual/allocator.xml


-- 


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

[Bug libstdc++/36451] Broken links in libstdc++ online documentation

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2008-07-10 01:44 ---
Fixed.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/36647] configure scripts can not find out version of GNU ld 2.18

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2008-07-10 01:52 ---
Ian last to change gnu_ld_version bits, which are currently broken with stock
2.18 GNU release for libstdc++/libgomp.

It would be really nice to fix this in one place, not two.


-- 


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

[Bug libstdc++/36647] configure scripts can not find out version of GNU ld 2.18

[ian at airs dot com]

--- Comment #3 from ian at airs dot com  2008-07-10 01:52 ---
What is the output of ld --version using your 2.18 version of ld?


-- 

ian at airs dot com changed:

   What|Removed |Added

 CC|iant at google dot com  |ian at airs dot com


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

[Bug other/36781] New: gcc can't be compiled in an environment that requires CFLAGS

[mikulas at artax dot karlin dot mff dot cuni dot cz]

If you have an environment where special CFLAGS are needed for compilation, gcc
doesn't compile (in my example, it was Sparc that requires -m64). The
configure/make scripts are so messed up that they will eventually drop CFLAGS
and try to compile parts of gcc without them.

How to reproduce on any system:
move file /usr/bin/gcc to /usr/bin/gcc.x. Create new /usr/bin/gcc containing
this script:
#!/bin/sh
if [ -z "`echo "$@"|grep -- -fomit-frame-pointer`" ]; then
echo GCC WAS EXECUTED WITHOUT CFLAGS
exit 1
fi
gcc.x "$@"

Unpack gcc, set CFLAGS, CPPFLAGS and LDFLAGS to -fomit-frame-pointer and try to
compile. gcc attempts to compile libiberty without -fomit-frame-pointer and
fails.

I tried to set the variables before configure, to set the variables on make
command line, tried also setting LIBCFLAGS and BOOT_CFLAGS, but none helps.

The build scripts should be fixed to not lose CFLAGS and proper method for
setting the flags (before ./configure, like most packages? or make
CFLAGS=flags?) should be documented. The build stdout should be grepped for
lines containing the compiler and not containing CFLAGS to check that CFLAGS
are not lost in any part of compilation.


-- 
   Summary: gcc can't be compiled in an environment that requires
CFLAGS
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
 GCC build triplet: sparc64-unknown-linux-gnu
  GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu


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

[Bug other/36781] gcc can't be compiled in an environment that requires CFLAGS

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2008-07-10 02:51 ---
Subject: Re:   New: gcc can't be compiled in an environment
 that requires CFLAGS

On Thu, 10 Jul 2008, mikulas at artax dot karlin dot mff dot cuni dot cz wrote:

> If you have an environment where special CFLAGS are needed for compilation, 
> gcc
> doesn't compile (in my example, it was Sparc that requires -m64). The
> configure/make scripts are so messed up that they will eventually drop CFLAGS
> and try to compile parts of gcc without them.

If special flags are required on all compilations they should be put in 
variables such as CC, not CFLAGS.


-- 


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

[Bug libstdc++/36130] Atomics regression test fail to compile when parallel mode is enabled

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2008-07-10 03:01 ---
fixed


-- 

bkoz 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=36130

[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says

[bangerth at dealii dot org]

--- Comment #15 from bangerth at dealii dot org  2008-07-10 03:38 ---
(In reply to comment #11)
> Subject: Re:  [4.3 regression] -Wreturn-type warns about more
>  than what the documentation says
> 
> 
> > I think this was done on purpose.
> 
> It is contrary to what the documentation says. I think it also doesn't
> make much sense in C++ if the return type results from a template
> substitution. For example, the following case is rather common:
> 
>   template  class Array {
> T& operator();
> T operator() const;
>   };
> 
> This class will trigger a warning if instantiated as Array
> because the return type of the second operator() is now 'const double'.

This issue has now been addressed with the most recent patch for PR 36760.


-- 


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

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

[bangerth at dealii dot org]

--- Comment #20 from bangerth at dealii dot org  2008-07-10 03:40 ---
(In reply to comment #19)
> Fixed for 4.4.0.

Thanks a lot!

Two questions:
1/ Is the text in the documentation that Dirk Mueller added in the last commit
   of PR 30601 now wrong/outdated?
2/ Does your patch also fix the testcase in PR 36052?

Thanks
 W.


-- 


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

[Bug c++/36633] [4.4 regression] warning "array subscript is below array bounds" on delete [] with -O2, -Wall

[mark at codesourcery dot com]

--- Comment #9 from mark at codesourcery dot com  2008-07-10 03:42 ---
Subject: Re:  [4.4 regression] warning "array subscript is
 below array bounds" on delete [] with -O2, -Wall

paolo dot carlini at oracle dot com wrote:

> Mark, could you possibly comment on this PR? With some good hints I could even
> try to work on it...

I don't see that the C++ front-end is doing anything obviously wrong 
here.  The cast to (long unsigned int *) is coming from the presence of 
the array "cookie".  When we allocate an array, we allocate a few extra 
bytes and scribble the length of the array into that extra space.  Then, 
when the user does "delete[]" we know how many array elements there are, 
so we can run all the destructors.  See:

  http://www.codesourcery.com/public/cxx-abi/abi.html#array-cookies

Thanks,


-- 


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

[Bug other/28322] GCC new warnings and compatibility

[doko at gcc dot gnu dot org]

--- Comment #21 from doko at gcc dot gnu dot org  2008-07-10 03:51 ---
Subject: Bug 28322

Author: doko
Date: Thu Jul 10 03:51:04 2008
New Revision: 137687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137687
Log:
2008-07-10  Peter Maydell  <[EMAIL PROTECTED]>

PR other/28322
* opts.c (print_ignored_options): report postponed diagnostics for
unknown -Wno-* options as warnings, not errors.
(postpone_unknown_option_error): renamed to
postpone_unknown_option_warning.
* gcc.dg/pr28322-2.c: check that emitted diagnostic for -Wno-foobar
is a warning and not an error.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/testsuite/gcc.dg/pr28322-2.c


-- 


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

[Bug c++/35201] libdemangle no longer distinguishes constructor/destructor variants

[ian at airs dot com]

--- Comment #1 from ian at airs dot com  2008-07-10 05:49 ---
Yes, the old demangler printed additional text in some cases when DMGL_VERBOSE
was passed as a flag.  c++filt passes that flag.  The new demangler doesn't
print that additional text.  There are several FIXME comments in
libiberty/cp-demangle.c which marks the places which could or should be
changed.


-- 

ian at airs dot com changed:

   What|Removed |Added

 CC|ian at gcc dot gnu dot org  |ian at airs dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-10 05:49:25
   date||


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