[Bug c++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #9 from ivranos at freemail dot gr  2008-10-03 08:38 ---
I am sorry but you are not right/specific.

At first there is no struct in the code, only class. Second, the copy
constructor does not copy the passed argument, it ignores it. But it
initialises its data member the same way as the main constructor.

So, there isn't any bug.


-- 

ivranos at freemail dot gr changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
  Component|libstdc++   |c++
 Resolution|INVALID |


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

[Bug libstdc++/37721] Segmentation fault

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2008-10-03 08:41 
---
To be clear: in general PRs are not meant to be re-opened by submitter at will,
unless he provides at the same time additional, detailed evidence going beyond
the initial report. Debug-mode cannot be wrong. Please spend your time on
something else. 


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution||INVALID


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

[Bug libstdc++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #11 from ivranos at freemail dot gr  2008-10-03 08:48 ---
I posted the code to c.l.c++ with the subject "Segmentation fault". If noone
finds any bug, I will reopen the bug here.


-- 


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

[Bug libstdc++/37721] Segmentation fault

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2008-10-03 08:52 
---
Good. In general, please don't try to force the GCC maintainers to debug user
code, this is not going to work. And, by the way, Andrew is right, your class
SomeClass appears badly broken in many different ways.


-- 


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

[Bug middle-end/29609] [4.2/4.3/4.4 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg00017.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-07 17:40:51 |2008-10-03 08:54:37
   date||


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

[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg00017.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-07-01 15:52:34 |2008-10-03 08:55:03
   date||


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

[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg00017.html
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 08:55:35
   date||


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

[Bug libstdc++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #13 from ivranos at freemail dot gr  2008-10-03 09:09 ---
The prurpose of the code is to benchmark the sorting of a vector and of a list
with complex objects as their elements (SomeClass).

SomeClass itself doesn't make any other sense, its purpose is to be complex.

I think there is no source code bug on it, that accesses inaccessible memory.

Noone here spotted such a bug, noone in c.l.c++ spotted a bug too, since I had
posted the code there previously.

But in any case, I posted the code in a new thread with subject "Segmentation
fault".

If noone finds any source code bug, I will reopen the GCC bug report here.


-- 


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

[Bug libstdc++/37721] Segmentation fault

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2008-10-03 09:20 
---
You can re-open it, unfortunately we cannot avoid it, at the moment, but given
that you are doing it against the judgement of the maintainers, nobody will pay
any further attention to it, ever. Be warned.


-- 


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

[Bug libstdc++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #15 from ivranos at freemail dot gr  2008-10-03 09:54 ---
So, if there isn't any source code bug at my side, and it is a compiler bug,
you mean "the maintainers" don't care to fix it?


-- 


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

[Bug c/37725] New: wrong struct initialization with non-constant expressions

[disinbox at gmail dot com]

test case:

#include 

typedef struct {
  unsigned int a;
  unsigned int b;
  unsigned int c;
  unsigned int d;
} Head;

void f()
{
  unsigned int offsetVar=sizeof(Head);

  Head h={
1,
2,
offsetVar, 
offsetVar+=sizeof(unsigned int)
  };

  printf("%d\t%d\t%d\t%d\n", h.a, h.b, h.c, h.d);
}

int main()
{
  f();
  return 0;
}

expected results:
1   2   16  20

actual results:
1   2   20  20

declaring offsetVar as volatile hides the problem


-- 
   Summary: wrong struct initialization with non-constant
expressions
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: disinbox at gmail dot com


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

[Bug libstdc++/37718] Demangling of variadic functions

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-10-03 10:51 
---
Then, I guess we can just assign to Jason.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|jason at gcc dot gnu dot org|
 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 |2008-10-03 10:51:58
   date||


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

[Bug inline-asm/37711] Incorrect code generated for mips inline assembly

[andy-gcc at ultra-premium dot com]

--- Comment #3 from andy-gcc at ultra-premium dot com  2008-10-03 10:52 
---
Gah. You are absolutely correct. Thanks for your help, and I'm glad I included
this sentence:

"And sorry if my understanding of the extended assembly is wrong and this is a
bug in my own code."


-- 


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

[Bug libstdc++/37391] examples not accessible online (non existing URLs)

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-10-03 10:53 
---
This is now fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/34419] Weirdness with numeric_limits in special functions

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-10-03 10:54 
---
Any news Ed?


-- 


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

[Bug c/37725] wrong struct initialization with non-constant expressions

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-03 10:56 ---
Please read the standard, particularly ISO C99 in 6.7.8/23 says:
"The order in which any side effects occur among the initialization list
expressions is unspecified." 130)

"130) In particular, the evaluation order need not be the same as the order of
subobject initialization."


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2008-10-03 12:12 ---
(In reply to comment #11)
Happily, I have come to the conclusion that the code is invalid no matter which
order the declarations come in;

In a restricted expression... (7.1.6.2):

(7) A reference to an intrinsic function that is
(a) an array inquiry function (13.11.15) other than ALLOCATED,
   SIZE in this case

and where each argument of the function is
(a) a restricted expression or
(b) a variable whose properties inquired about are not
the TRANSFER (x, [1]) argument is manifestly not consistent with (b) and should
fail by (a) with exactly the g95 message.

I will make it so.

In fact the ICE is precisely due to the argument not being a restricted
expression, since the size of x and its kind are unavailable to the caller and
the interfacing cannot be made to work.  This is why restricted expressions
only permit dummy, host- or use-associated or common variables and why my
attempts to evaluate the transfer are failing.

Paul


-- 


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

[Bug libstdc++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #16 from ivranos at freemail dot gr  2008-10-03 11:52 ---
I managed to replicate the bug in simple code:


#include 
#include 
#include 
#include 


int main()
{
using namespace std;

vector intVector(1000*1000);

srand(time(0));


for(size_t i= 0; i< RAND_MAX; ++i)
{
for (vector::size_type j= 0; i< intVector.size(); ++j)
intVector[j]= rand();

sort(intVector.begin(), intVector.end());
}
}


-- 

ivranos at freemail dot gr changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libstdc++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #17 from ivranos at freemail dot gr  2008-10-03 11:55 ---
The bug occurs in this simpler code too:


#include 
#include 
#include 
#include 
#include 


int main()
{
using namespace std;

vector intVector(1000*1000);

srand(time(0));


for(size_t i= 0; i< numeric_limits::max()/2; ++i)
{
for (vector::size_type j= 0; i< intVector.size(); ++j)
intVector[j]= rand();
}
}


-- 


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

[Bug libstdc++/37721] Segmentation fault

[ivranos at freemail dot gr]

--- Comment #18 from ivranos at freemail dot gr  2008-10-03 11:59 ---
The last two code snippers had errors.


-- 

ivranos at freemail dot gr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/37724] "initialization from incompatible pointer type" does not say which field is being initialized

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-03 12:51 ---
patches welcome ;))  Indeed, this would be nice to fix.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

[pdemarco at ppg dot com]

--- Comment #10 from pdemarco at ppg dot com  2008-10-03 12:53 ---
(In reply to comment #9)
> Subject: Re:  Spurious 'might be used uninitialized' 
>  warnings in STL headers with -O2
> You are confusing the state of the Cygwin port of gcc with gcc in
> general.

Possibly, but I cannot find the download for 4.x.x.
Why does it have to be so confusing ?

http://sourceforge.net/project/showfiles.php?group_id=2435

This is the location that I got ALPHA from.
It appears that the best 4.x.x download is: Testing:
gcc-4.3.0-20080502-mingw32-alpha

I see no other reasonable downloads.


-- 


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

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2008-10-03 13:00 
---
Brian is right:

  http://gcc.gnu.org/mirrors.html


-- 


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

[Bug libstdc++/37721] Segmentation fault

[paolo dot carlini at oracle dot com]

--- Comment #19 from paolo dot carlini at oracle dot com  2008-10-03 13:21 
---
Before anything else, you should realize that, per 23.1/3, the type of objects
stored in a std::vector must meet the requirements of CopyConstructible types
(20.1.3), which, in turn, include semantic requirements: the copy constructor
of SomeClass doesn't meet the requirements in Table 30, in short does not
really copy construct.


-- 


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

[Bug debug/37726] New: [4.4 Regression] Even at -O0 -g debuginfo for vars mentioned in nested fns is not emitted

[jakub at gcc dot gnu dot org]

int foo (int parm)
{
  int var = 0;
  int bar (void)
  {
return parm + var;
  }
  parm++;
  var++;
  return bar ();
}

int
main (void)
{
  return foo (4) - 6;
}

at -O0 -g this was perfectly debuggable in 4.3, but doesn't know anything about
parm or var, neither in the outer nor inner function.


-- 
   Summary: [4.4 Regression] Even at -O0 -g debuginfo for vars
mentioned in nested fns is not emitted
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug debug/37726] [4.4 Regression] Even at -O0 -g debuginfo for vars mentioned in nested fns is not emitted

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 13:29:37
   date||
   Target Milestone|--- |4.4.0


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

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

[James dot W dot Mckelvey at jpl dot nasa dot gov]

--- Comment #8 from James dot W dot Mckelvey at jpl dot nasa dot gov  
2008-10-03 14:16 ---
Last night I tried to bootstrap with Windows in safe mode. It got past the
"cannot create executables" and went on to fail with a different error.


-- 


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

[Bug ada/37309] Ada tasking is not implemented on NetBSD

[aran at 100acres dot us]

--- Comment #6 from aran at 100acres dot us  2008-10-03 14:53 ---
There is a typo in the last path.  Apply this after the above.

--- orig/gcc/ada/s-osinte-netbsd.adb2008-10-03 07:50:29.0 -0700
+++ netbsd/gcc/ada/s-osinte-netbsd.adb  2008-10-02 19:35:38.0 -0700
@@ -46,7 +46,7 @@ package body System.OS_Interface is
   type int_ptr is access all int;

   function internal_errno return int_ptr;
-  pragma Import (C, internal_errno, "__error");
+  pragma Import (C, internal_errno, "__errno");

begin
   return (internal_errno.all);


-- 


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

[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

[spop at gcc dot gnu dot org]

--- Comment #18 from spop at gcc dot gnu dot org  2008-10-03 15:49 ---
Mine.

We should do exactly what graphite is doing: register loops belonging
to the loop nest in a VEC, then iterate over the loop nest to find the
index in the Access Matrix.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-10-01 21:55:56 |2008-10-03 15:49:06
   date||


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

[Bug target/37727] New: NO_IMPLICIT_EXTERN_C for newlib

[jifl-bugzilla at jifvik dot org]

Is there any reason that NO_IMPLICIT_EXTERN_C can't be automatically defined,
if --with-newlib is used? newlib's headers are C++-safe.


-- 
   Summary: NO_IMPLICIT_EXTERN_C for newlib
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org


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

[Bug c++/37719] incorrect type on warning of mismatched exception specification with templates

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2008-10-03 16:30 ---
Subject: Bug 37719

Author: paolo
Date: Fri Oct  3 16:29:07 2008
New Revision: 140855

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

PR c++/37719
* error.c (dump_function_decl): Save the exceptions in case of
error about incompatible specifications in a specialization.

/testsuite
2008-10-03  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/37719
* g++.dg/template/error36.C: New.

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


-- 


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

[Bug c++/37719] incorrect type on warning of mismatched exception specification with templates

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-10-03 16:31 
---
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=37719

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #28 from nickc at redhat dot com  2008-10-03 16:52 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

Hi Danny,

> This test case:
> t1.c:(.text+0x5): undefined reference to `_i' 

Hmm, I cannot reproduce this, however...

> .comm   _i, 0 < size of i[0]

I did drop the code to handle (size == 0) because I was not sure why it 
was there.

> I suspect we need to add this bit, or similar, back in
> -  rounded = size ? size : 1;

How about this third revision of the patch ?

Cheers
   Nick


-- 


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #29 from nickc at redhat dot com  2008-10-03 16:54 ---
Created an attachment (id=16458)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16458&action=view)
Revised patch which handles (size == 0)


-- 

nickc at redhat dot com changed:

   What|Removed |Added

  Attachment #16425|0   |1
is obsolete||


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[sherpya at netfarm dot it]

--- Comment #30 from sherpya at netfarm dot it  2008-10-03 17:06 ---
the patch looks ok but unfortunately does not always solves the problem,
something in the chain misalignes the symbol
This does not happen always but in some circumstances :(


-- 


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

[Bug target/37727] NO_IMPLICIT_EXTERN_C for newlib

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2008-10-03 17:00 ---
Subject: Re:   New: NO_IMPLICIT_EXTERN_C for newlib

I've argued before and will argue again that NO_IMPLICIT_EXTERN_C should 
be the default with a macro IMPLICIT_EXTERN_C defined for only those 
targets known to need it.

http://gcc.gnu.org/ml/gcc/2005-05/msg00377.html

That list of targets is of course out of date and many have been 
deprecated.  I did establish the principle in the fixproto deprecation 
that generic *-elf targets can be presumed to have good headers, so I 
think it should only be targets for specific OSes that should define 
IMPLICIT_EXTERN_C.


-- 


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

Re: [Bug c++/37721] Segmentation fault

[Andrew Thomas Pinski]

Sent from my iPhone

On Oct 3, 2008, at 1:38 AM, "ivranos at freemail dot gr" <[EMAIL PROTECTED] 
> wrote:





--- Comment #9 from ivranos at freemail dot gr  2008-10-03 08:38  
---

I am sorry but you are not right/specific.

At first there is no struct in the code, only class.


In C++ structs/classes are the same thing except if it is private or  
public by defaut.



Second, the copy
constructor does not copy the passed argument, it ignores it.


And that is the bug really. Sort uses the copy construct to swap two  
elements of the vector. So you will generate random data again and  
again and the sort becomes confused.


Note std::sort uses std::swap which is defined this way.

Sorry but there is no bug in the library or GCC.


But it
initialises its data member the same way as the main constructor.

So, there isn't any bug.


--

ivranos at freemail dot gr changed:

  What|Removed |Added
--- 
--- 
--

Status|RESOLVED|UNCONFIRMED
 Component|libstdc++   |c++
Resolution|INVALID |


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

[Bug c/37724] "initialization from incompatible pointer type" does not say which field is being initialized

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2008-10-03 17:33 ---
Subject: Re:  "initialization from incompatible pointer type" does not say
which field is being initialized



Sent from my iPhone

On Oct 3, 2008, at 5:51 AM, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-03  
> 12:51 ---
> patches welcome ;))  Indeed, this would be nice to fix.

I will be testing the patch today. :).

>
>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
>   Severity|normal  |enhancement
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37724
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug libstdc++/37721] Segmentation fault

[pinskia at gmail dot com]

--- Comment #20 from pinskia at gmail dot com  2008-10-03 17:34 ---
Subject: Re:  Segmentation fault



Sent from my iPhone

On Oct 3, 2008, at 1:38 AM, "ivranos at freemail dot gr"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #9 from ivranos at freemail dot gr  2008-10-03 08:38  
> ---
> I am sorry but you are not right/specific.
>
> At first there is no struct in the code, only class.

In C++ structs/classes are the same thing except if it is private or  
public by defaut.

> Second, the copy
> constructor does not copy the passed argument, it ignores it.

And that is the bug really. Sort uses the copy construct to swap two  
elements of the vector. So you will generate random data again and  
again and the sort becomes confused.

Note std::sort uses std::swap which is defined this way.

Sorry but there is no bug in the library or GCC.

> But it
> initialises its data member the same way as the main constructor.
>
> So, there isn't any bug.
>
>
> -- 
>
> ivranos at freemail dot gr changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
> Status|RESOLVED|UNCONFIRMED
>  Component|libstdc++   |c++
> Resolution|INVALID |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37721
>


-- 


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

[Bug middle-end/37689] [4.4 Regression] ICE compiling newlib

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-10-03 17:54 ---
Should be fixed now.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

Re: [Bug c++/37728] New: if scoping for declarations

[Andrew Thomas Pinski]

Sent from my iPhone

On Oct 3, 2008, at 11:10 AM, "mrs at apple dot com" <[EMAIL PROTECTED] 
> wrote:



In:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017449.html

we were discussing possible bugs in g++ scoping for if statements.

$ cat t.cc
void foo() {
 if (int x = 0) {
   int x;
 }
}


This is invalid C++ but it is valid C99. There is already a duplicated  
bug filed for this too but I am too lazy right now to find it.




$ ./xgcc -B./ -c t.cc
$

they expected this to produce a redeclaration error on the inner  
declaration

for X.

Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision  
140855]

(GCC)

There were other concerns about for, but, others seem to think gcc  
does the

right thing with them.


--
  Summary: if scoping for declarations
  Product: gcc
  Version: 4.4.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: mrs at apple dot com


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

[Bug c++/37728] if scoping for declarations

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2008-10-03 18:23 ---
Subject: Re:   New: if scoping for declarations



Sent from my iPhone

On Oct 3, 2008, at 11:10 AM, "mrs at apple dot com" <[EMAIL PROTECTED] 
 > wrote:

> In:
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017449.html
>
> we were discussing possible bugs in g++ scoping for if statements.
>
> $ cat t.cc
> void foo() {
>  if (int x = 0) {
>int x;
>  }
> }

This is invalid C++ but it is valid C99. There is already a duplicated  
bug filed for this too but I am too lazy right now to find it.

>
> $ ./xgcc -B./ -c t.cc
> $
>
> they expected this to produce a redeclaration error on the inner  
> declaration
> for X.
>
> Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision  
> 140855]
> (GCC)
>
> There were other concerns about for, but, others seem to think gcc  
> does the
> right thing with them.
>
>
> -- 
>   Summary: if scoping for declarations
>   Product: gcc
>   Version: 4.4.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: mrs at apple dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37728
>


-- 


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

[Bug c++/37728] New: if scoping for declarations

[mrs at apple dot com]

In:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017449.html

we were discussing possible bugs in g++ scoping for if statements.

$ cat t.cc
void foo() {
  if (int x = 0) {
int x;
  }
}
$ ./xgcc -B./ -c t.cc 
$ 

they expected this to produce a redeclaration error on the inner declaration
for X.

Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision 140855]
(GCC)

There were other concerns about for, but, others seem to think gcc does the
right thing with them.


-- 
   Summary: if scoping for declarations
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c++/18770] g++ accepts invalid code with scopes on ifs

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-03 18:46 ---
*** Bug 37728 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mrs at apple dot com


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

[Bug c++/37728] if scoping for declarations

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-03 18:46 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/37729] New: function parameter pack expansion doesn't work in late-specified return type

[jason at gcc dot gnu dot org]

In this testcase:

int f(int,int);

template 
auto g(T... parms) -> decltype (f(parms...));

int main()
{
  return g(1,2);
}

We deduce the template argument types properly, but substituting them into the
return type fails because retrieve_local_specialization doesn't find a function
argument pack to use in the call to f.  I ran into the same issue with normal
parameters and just fudged around it by replacing the parameter with *(T*)NULL;
I would expect the same thing to work here, but so far I have failed to come up
with the right incantation to turn parms... into *(T*)NULL...


-- 
   Summary: function parameter pack expansion doesn't work in late-
specified return type
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org


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

[Bug c/37725] wrong struct initialization with non-constant expressions

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-03 18:56 ---
I thought there was a defect report (against the C standard) about this but I
can't find the bug which was referencing that one.

-- Pinski


-- 


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

[Bug debug/37726] [4.4 Regression] Even at -O0 -g debuginfo for vars mentioned in nested fns is not emitted

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-03 18:57 ---
Subject: Bug 37726

Author: jakub
Date: Fri Oct  3 18:55:39 2008
New Revision: 140857

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140857
Log:
PR debug/37726
* gimplify.c (declare_vars): Use gimple_bind_block instead of
gimple_block.

* gcc.dg/debug/dwarf2/pr37726.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr37726.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/37726] [4.4 Regression] Even at -O0 -g debuginfo for vars mentioned in nested fns is not emitted

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-10-03 19:35 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

Re: [Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

[Sebastian Pop]

Here is a patch that should fix this bug.  Can somebody test that it fixes it?

Thanks,
Sebastian
Index: tree-loop-linear.c
===
--- tree-loop-linear.c	(revision 140668)
+++ tree-loop-linear.c	(working copy)
@@ -333,11 +333,16 @@ linear_transform_loops (void)
   lambda_loopnest before, after;
   lambda_trans_matrix trans;
   struct obstack lambda_obstack;
+  struct loop *loop;
+  VEC(loop_p,heap) *nest = VEC_alloc (loop_p, heap, 3);
 
   depth = perfect_loop_nest_depth (loop_nest);
   if (depth == 0)
 	continue;
 
+  for (loop = loop_nest; loop; loop = loop->inner)
+	VEC_safe_push (loop_p, heap, nest, loop);
+
   gcc_obstack_init (&lambda_obstack);
   VEC_truncate (tree, oldivs, 0);
   VEC_truncate (tree, invariants, 0);
@@ -350,8 +355,7 @@ linear_transform_loops (void)
 	goto free_and_continue;
   
   lambda_collect_parameters (datarefs, &lambda_parameters);
-  if (!lambda_compute_access_matrices (datarefs, lambda_parameters,
-	   loop_nest->num))
+  if (!lambda_compute_access_matrices (datarefs, lambda_parameters, nest))
 	goto free_and_continue;
 
   if (dump_file && (dump_flags & TDF_DETAILS))
@@ -410,6 +414,7 @@ linear_transform_loops (void)
   obstack_free (&lambda_obstack, NULL);
   free_dependence_relations (dependence_relations);
   free_data_refs (datarefs);
+  VEC_free (loop_p, heap, nest);
 }
 
   for (i = 0; VEC_iterate (gimple, remove_ivs, i, oldiv_stmt); i++)
Index: tree-data-ref.h
===
--- tree-data-ref.h	(revision 140668)
+++ tree-data-ref.h	(working copy)
@@ -128,13 +128,13 @@ typedef struct scop *scop_p;
 */
 struct access_matrix
 {
-  int loop_nest_num;
+  VEC (loop_p, heap) *loop_nest;
   int nb_induction_vars;
   VEC (tree, heap) *parameters;
   VEC (lambda_vector, heap) *matrix;
 };
 
-#define AM_LOOP_NEST_NUM(M) (M)->loop_nest_num
+#define AM_LOOP_NEST(M) (M)->loop_nest
 #define AM_NB_INDUCTION_VARS(M) (M)->nb_induction_vars
 #define AM_PARAMETERS(M) (M)->parameters
 #define AM_MATRIX(M) (M)->matrix
@@ -149,8 +149,14 @@ struct access_matrix
 static inline int
 am_vector_index_for_loop (struct access_matrix *access_matrix, int loop_num)
 {
-  gcc_assert (loop_num >= AM_LOOP_NEST_NUM (access_matrix));
-  return loop_num - AM_LOOP_NEST_NUM (access_matrix);
+  int i;
+  loop_p l;
+
+  for (i = 0; VEC_iterate (loop_p, AM_LOOP_NEST (access_matrix), i, l); i++)
+if (l->num == loop_num)
+  return i;
+
+  gcc_unreachable();
 }
 
 int access_matrix_get_index_for_parameter (tree, struct access_matrix *);
@@ -581,7 +587,7 @@ bool lambda_transform_legal_p (lambda_tr
 void lambda_collect_parameters (VEC (data_reference_p, heap) *,
 VEC (tree, heap) **);
 bool lambda_compute_access_matrices (VEC (data_reference_p, heap) *,
- VEC (tree, heap) *, int);
+ VEC (tree, heap) *, VEC (loop_p, heap) *);
 
 /* In tree-data-ref.c  */
 void split_constant_offset (tree , tree *, tree *);
Index: lambda-code.c
===
--- lambda-code.c	(revision 140668)
+++ lambda-code.c	(working copy)
@@ -2786,17 +2786,15 @@ av_for_af (tree access_fun, lambda_vecto
 
 static bool
 build_access_matrix (data_reference_p data_reference,
-		 VEC (tree, heap) *parameters, int loop_nest_num)
+		 VEC (tree, heap) *parameters, VEC (loop_p, heap) *nest)
 {
   struct access_matrix *am = GGC_NEW (struct access_matrix);
   unsigned i, ndim = DR_NUM_DIMENSIONS (data_reference);
-  struct loop *loop = gimple_bb (DR_STMT (data_reference))->loop_father;
-  struct loop *loop_nest = get_loop (loop_nest_num);
-  unsigned nivs = loop_depth (loop) - loop_depth (loop_nest) + 1;
+  unsigned nivs = VEC_length (loop_p, nest);
   unsigned lambda_nb_columns;
   lambda_vector_vec_p matrix;
 
-  AM_LOOP_NEST_NUM (am) = loop_nest_num;
+  AM_LOOP_NEST (am) = nest;
   AM_NB_INDUCTION_VARS (am) = nivs;
   AM_PARAMETERS (am) = parameters;
 
@@ -2824,13 +2822,13 @@ build_access_matrix (data_reference_p da
 bool
 lambda_compute_access_matrices (VEC (data_reference_p, heap) *datarefs,
 VEC (tree, heap) *parameters,
-int loop_nest_num)
+VEC (loop_p, heap) *nest)
 {
   data_reference_p dataref;
   unsigned ix;
 
   for (ix = 0; VEC_iterate (data_reference_p, datarefs, ix, dataref); ix++)
-if (!build_access_matrix (dataref, parameters, loop_nest_num))
+if (!build_access_matrix (dataref, parameters, nest))
   return false;
 
   return true;

[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

[sebpop at gmail dot com]

--- Comment #19 from sebpop at gmail dot com  2008-10-03 20:15 ---
Subject: Re:  [4.4 Regression] Building of CPU2000's bzip2 with peak flags with
-mcpu=power4 fails with an ICE.

Here is a patch that should fix this bug.  Can somebody test that it fixes it?

Thanks,
Sebastian


--- Comment #20 from sebpop at gmail dot com  2008-10-03 20:15 ---
Created an attachment (id=16459)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16459&action=view)


-- 


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

[Bug middle-end/37730] New: [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2

[pinskia at gcc dot gnu dot org]

Since on x86-darwin, SSE2 is enabled by default, I see a failure with this
testcase:
output
is:/Users/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/pr37713.c:
In function 'add_opush':^M
/Users/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/pr37713.c:8:
internal compiler error: in set_mem_alias_set, at emit-rtl.c:1784^M Please
submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

--- CUT ---
void add_opush(void)
{
unsigned char formats[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0xff };
void *dtds[sizeof(formats)];
unsigned int i;
unsigned char dtd = 0x08;
for (i = 0; i < sizeof(formats); i++)
dtds[i] = &dtd;
sdp_seq_alloc(dtds);
}
--- CUT ---


-- 
   Summary: [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at
-O3 -msse2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-*-*


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

[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.4.0


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

[Bug c++/37657] static template member definition fails when parameter is another template

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug middle-end/37587] ICE when use graphite

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2008-10-03 20:28 ---
This bug will be fixed when the patches for PR37485 will be in trunk.
The bug is fixed in the graphite branch.

Sebastian


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


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||37485
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2008-10-03 20:28 ---
*** Bug 37587 has been marked as a duplicate of this bug. ***


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||37587
  nThis||
 CC||linuxl4 at sohu dot com


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

[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-03 20:29 ---
Confirmed.  At first sight this looks like an expansion problem of the
initializer.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 20:29:59
   date||


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

[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ra, wrong-code
Summary|Bootstrap failure due to|[4.4 Regression] Bootstrap
   |miscompilation of genattrtab|failure due to
   ||miscompilation of genattrtab
   Target Milestone|--- |4.4.0


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

[Bug middle-end/37678] Failure to generate post-increment addressing

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-03 20:30 ---
Most likely a dup of bug 31849.


-- 


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

[Bug tree-optimization/37708] ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2008-10-03 20:38 ---
This bug is different than PR37485.  It still fails in the graphite branch.
Mine.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|37485   |
 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 20:38:36
   date||


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

[Bug c/37724] "initialization from incompatible pointer type" does not say which field is being initialized

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-10-03 20:41 ---
I have a patch which I am testing right now:
Index: c-typeck.c
===
--- c-typeck.c  (revision 140850)
+++ c-typeck.c  (working copy)
@@ -3994,7 +3994,7 @@ convert_for_assignment (tree type, tree 
 pedwarn (LOCATION, OPT, AS); \
 break;   \
   case ic_init:  \
-pedwarn (LOCATION, OPT, IN); \
+pedwarn_init (LOCATION, OPT, IN);\
 break;   \
   case ic_return:\
 pedwarn (LOCATION, OPT, RE); \

--- CUT ---
This does not fix C++ though, that is going to be harder.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 20:41:52
   date||


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

[Bug c++/37715] Different class sizes with public/private and alignments

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-03 20:46 ---
In the private case, A is a non-POD so _c can fit tail part of A.  So the
sizeof(M) is 16 bytes.
In the public case, A is a POD so _c is not allowed to be in the tail part of A
(as required by the C++ standard), so the sizeof(M) is 2 * 16.  The sizeof (_c)
is 1 as required by the C++ standard.

For the non aligned case, there is no tail part of A for the non POD case as
the alignment and size are equal.


-- 

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

[Bug c++/37653] Duplicate messages and warnings depending on the program

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-03 20:56 ---
(In reply to comment #1)
> Works correctly on the trunk, that is it does not warn at all.

Well with -pedantic it does warn.


-- 


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

[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

[luisgpm at linux dot vnet dot ibm dot com]

--- Comment #21 from luisgpm at linux dot vnet dot ibm dot com  2008-10-03 
20:59 ---
It fixes the bzip2 ICE.

Thanks,
Luis


-- 


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

[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2008-10-03 21:10 ---
Subject: Bug 37684

Author: spop
Date: Fri Oct  3 21:09:37 2008
New Revision: 140861

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140861
Log:
2008-10-03  Harsha Jagasia  <[EMAIL PROTECTED]>

PR tree-optimization/37684
* gcc.dg/graphite/pr37684.c: New.
* graphite.c (exclude_component_ref): New.
(is_simple_operand): Call exclude_component_ref.


Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr37684.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite.c


-- 


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

[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2008-10-03 21:11 ---
Bug is fixed in graphite branch.  Waiting review for trunk.

Sebastian


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|hjagasia at gcc dot gnu dot |spop at gcc dot gnu dot org
   |org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 21:11:19
   date||


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

[Bug middle-end/37731] New: unsigned long long may not work correctly on 32bit host

[hjl dot tools at gmail dot com]

On Linux/ia32, gcc 4.4 gave:

[EMAIL PROTECTED] longlong-2]$ cat y.c
#include 

extern void abort ();

unsigned long long xh = 1ull;

int
main ()
{
  unsigned long long yh = 0xull;
  unsigned long long z = xh * yh;
  unsigned long long i = 1ull * yh;

  printf ("%llx\n", i);
  printf ("%llx\n", z);
  if (z != i)
abort ();
}
[EMAIL PROTECTED] longlong-2]$ gcc -m32 -O y.c
[EMAIL PROTECTED] longlong-2]$ ./a.out 


Aborted
[EMAIL PROTECTED] longlong-2]$ 

On Linux/Intel64, I got

[EMAIL PROTECTED] longlong-2]$ gcc -m32 -O y.c
[EMAIL PROTECTED] longlong-2]$ ./a.out 


[EMAIL PROTECTED] longlong-2]$ 

On 32bit hosts, we didn't handle unsigned long long properly.


-- 
   Summary: unsigned long long may not work correctly on 32bit host
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=37731

[Bug middle-end/37731] unsigned long long may not work correctly on 32bit host

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-03 21:39 ---
One more reason to use HWI as 64bits on x86-linux-gnu :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||HWI == 32bits


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

[Bug middle-end/37731] unsigned long long may not work correctly on 32bit host

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-03 21:40 ---
Oh this works fine on x86-darwin because HWI is 64bits.


-- 


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

[Bug middle-end/37731] unsigned long long may not work correctly on 32bit host

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-10-03 21:43 ---
Confirmed.  HWI32 issue.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet||i?86-*-*
 GCC target triplet|HWI == 32bits   |
   Keywords||wrong-code
  Known to fail||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 21:43:00
   date||
   Target Milestone|--- |4.4.0


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

[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-10-03 21:47 ---
2.95 and 3.3.6 work.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||2.95.4 3.3.6
Summary|unsigned long long may not  |[4.2/4.3/4.4 Regression]
   |work correctly on 32bit host|unsigned long long may not
   ||work correctly on 32bit host
   Target Milestone|4.4.0   |4.2.5


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

[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-10-03 22:00 ---
Gcc 3.4.6 works.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to work|2.95.4 3.3.6|2.95.4 3.3.6 3.4.6
   Target Milestone|4.2.5   |---


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

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2008-10-03 22:23 ---
> Happily, I have come to the conclusion that the code is invalid no matter 
> which
> order the declarations come in;
> 
> (a) a restricted expression or
> (b) a variable whose properties inquired about are not
> the TRANSFER (x, [1]) argument is manifestly not consistent with (b) and 
> should
> fail by (a) with exactly the g95 message.

After having knotted my neurones, I agree with that: size(transfer(x, [1])) is
not a "restricted expression".

> I will make it so.

Good!

> In fact the ICE is precisely due to the argument not being a restricted
> expression, since the size of x and its kind are unavailable to the caller and
> the interfacing cannot be made to work.  This is why restricted expressions
> only permit dummy, host- or use-associated or common variables and why my
> attempts to evaluate the transfer are failing.

However I disagree with this part of the analysis:

size(transfer(real(1.0,kind(x)), [1_1])) is a "restricted expression" (happily
accepted by gfortran) that uses exactly the same information as
size(transfer(x, [1])) as shown by the following code:

program main
  print *, foo()
  print *, size(transfer(real(1.0,kind(x)), [1_1])),&
   size(transfer(x, [1_1]))
  if (size(foo()) /= kind(x)) call abort()
contains
  function foo()
integer foo(size(transfer(real(1.0,kind(x)), [1_1])))
real x
foo=transfer(real(1.0,kind(x)), [1_1])
  end function
end program

giving on intel machines (without the patch in comment #6)

   0   0-128  63
   4   4

(with the patch the second line is 4 1) or

   0   0   0   0   0   0   
 -16  63
   8   8

when compiled with -fdefault-real-8. On ppc I get

  63-128   0   0
   4   4

and

  63 -16   0   0   0   0   
   0   0
   8   8


-- 


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

[Bug tree-optimization/37732] New: [4.2/4.3/4.4 Regression] 40% slower numeric sort

[wbrana at gmail dot com]

nbench 2.2.3 numeric sort test executes 40% less iterations per second
when compiled with 4.4 snapshot than with 3.4.6

iterations/s - version
2439 - 3.4.6
1530 - 4.4.0 20080926 (experimental)
1526 - 4.3.2 
1580 - 4.2.4

CFLAGS = -s -static -Wall -O3 -g0 -march=nocona -fomit-frame-pointer
-funroll-loops -ffast-math

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST: Iterations/sec.  : Old Index   : New Index
:  : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT:  2439.1  :  62.55  :  20.54
STRING SORT :  373.28  : 166.79  :  25.82
BITFIELD:  5.9879e+08  : 102.71  :  21.45
FP EMULATION:  267.84  : 128.52  :  29.66
FOURIER :   43702  :  49.70  :  27.92
ASSIGNMENT  :  56.657  : 215.59  :  55.92
IDEA:  5407.7  :  82.71  :  24.56
HUFFMAN :  3204.3  :  88.86  :  28.37
NEURAL NET  :  57.485  :  92.35  :  38.84
LU DECOMPOSITION:  2363.5  : 122.44  :  88.41
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX   : 111.792
FLOATING-POINT INDEX: 82.519
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW===
CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750  @
2.66GHz 3200MHz
L2 Cache: 4096 KB
OS  : Linux 2.6.26.5
C compiler  : gcc version 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0,
pie-8.7.10)
libc: libc-2.8.so
MEMORY INDEX: 31.404
INTEGER INDEX   : 25.525
FLOATING-POINT INDEX: 45.768
Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST: Iterations/sec.  : Old Index   : New Index
:  : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT:  1530.9  :  39.26  :  12.89
STRING SORT :  372.64  : 166.51  :  25.77
BITFIELD:  6.0348e+08  : 103.52  :  21.62
FP EMULATION:   310.4  : 148.94  :  34.37
FOURIER :   31760  :  36.12  :  20.29
ASSIGNMENT  :  48.361  : 184.02  :  47.73
IDEA:9204  : 140.77  :  41.80
HUFFMAN :  3554.3  :  98.56  :  31.47
NEURAL NET  :  73.882  : 118.69  :  49.92
LU DECOMPOSITION:  2322.2  : 120.30  :  86.87
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX   : 114.457
FLOATING-POINT INDEX: 80.190
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW===
CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750  @
2.66GHz 3200MHz
L2 Cache: 4096 KB
OS  : Linux 2.6.26.5
C compiler  : gcc version 4.4.0 20080926 (experimental) (GCC)
libc: libc-2.8.so
MEMORY INDEX: 29.851
INTEGER INDEX   : 27.632
FLOATING-POINT INDEX: 44.477
Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST: Iterations/sec.  : Old Index   : New Index
:  : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT:  1526.2  :  39.14  :  12.85
STRING SORT :  374.28  : 167.24  :  25.89
BITFIELD:  6.0262e+08  : 103.37  :  21.59
FP EMULATION:  320.64  : 153.86  :  35.50
FOURIER :   33352  :  37.93  :  21.30
ASSIGNMENT  :  57.834  : 220.07  :  57.08
IDEA:9288  : 142.06  :  42.18
HUFFMAN :3211  :  89.04  :  28.43
NEURAL NET  :   74.69  : 119.98  :  50.47
LU DECOMPOSITION:  2655.7  : 137.58  :  99.35
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX   : 116.415
FLOATING-POINT INDEX: 

[Bug bootstrap/37733] New: GCC Bootstrap fails in Stage 2 AIX 5.2

[JFTrudeau at cvty dot com]

build/genattr /mtg/arc/gcc-4.3.2/gcc/config/rs6000/rs6000.md \
  insn-conditions.md > tmp-attr.h
/mtg/TOOL/powerpc-AIX5.2/bin/bash /mtg/arc/gcc-4.3.2/gcc/../move-if-change
tmp-attr.h insn-attr.h
echo timestamp > s-attr
/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/xgcc
-B/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/
-B/mtg/TOOL/gcc-4.3.2/powerpc-AIX5.2/powerpc-ibm-aix5.2.0.0/bin/ -c   -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros  -Wno-overlength-strings  
 -DHAVE_CONFIG_H -I. -I. -I/mtg/arc/gcc-4.3.2/gcc -I/mtg/arc/gcc-4.3.2/gcc/.
-I/mtg/arc/gcc-4.3.2/gcc/../include -I./../intl
-I/mtg/arc/gcc-4.3.2/gcc/../libcpp/include -I/mtg/TOOL/powerpc-AIX5.2/include
-I/mtg/TOOL/include -I/mtg/arc/gcc-4.3.2/gcc/../libdecnumber
-I/mtg/arc/gcc-4.3.2/gcc/../libdecnumber/dpd -I../libdecnumber   
insn-attrtab.c -o insn-attrtab.o
/mtg/arc/gcc-4.3.2/gcc/config/rs6000/rs6000.md: In function
'internal_dfa_insn_code':
/mtg/arc/gcc-4.3.2/gcc/config/rs6000/rs6000.md:148: internal compiler error:
Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [insn-attrtab.o] Error 1
make[4]: Leaving directory `/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/gcc'
make[3]: *** [all-stage2-gcc] Error 2
make[3]: Leaving directory `/mtg/arc/gcc-4.3.2-powerpc-AIX5.2'
make[2]: *** [stage2-bubble] Error 2
make[2]: Leaving directory `/mtg/arc/gcc-4.3.2-powerpc-AIX5.2'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/mtg/arc/gcc-4.3.2-powerpc-AIX5.2'

cd gcc-4.3.2-powerpc-AIX5.2
/mtg/TOOL/powerpc-AIX5.2/bin/bash /mtg/arc/gcc-4.3.2/configure
--prefix=/mtg/TOOL/gcc-4.3.2 --exec-prefix=/mtg/TOOL/gcc-4.3.2/powerpc-AIX5.2
--with-gmp=/mtg/TOOL/powerpc-AIX5.2 --with-mpfr=/mtg/TOOL

After researching the problem on the internet I found some reports that
indicated that this file was too large in some environments.  
  -rw-rw-r--  1 trudeajo fhaf6278 2008-10-03 14:07 insn-attr.h
  -rw-rw-r--  1 trudeajo fhaf 1393534 2008-10-03 14:07 insn-attrtab.c
I attempted to reduce the size by removing some includes from rs6000.md:

--- gcc/config/rs6000/rs6000.md.~1~ 2008-07-03 19:32:23.0 -0700
+++ gcc/config/rs6000/rs6000.md 2008-10-02 16:56:12.0 -0700
@@ -159,10 +159,6 @@
 (include "rios2.md")
 (include "rs64.md")
 (include "mpc.md")
-(include "40x.md")
-(include "440.md")
-(include "603.md")
-(include "6xx.md")
 (include "7xx.md")
 (include "7450.md")
 (include "8540.md")

This allowed insn-attrtab.c to compile, however the build failed on the very
next compile:

build/genattr /mtg/arc/gcc-4.3.2/gcc/config/rs6000/rs6000.md \
  insn-conditions.md > tmp-attr.h
/mtg/TOOL/powerpc-AIX5.2/bin/bash /mtg/arc/gcc-4.3.2/gcc/../move-if-change
tmp-attr.h insn-attr.h
echo timestamp > s-attr
/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/xgcc
-B/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/
-B/mtg/TOOL/gcc-4.3.2/powerpc-AIX5.2/powerpc-ibm-aix5.2.0.0/bin/ -c   -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros  -Wno-overlength-strings  
 -DHAVE_CONFIG_H -I. -I. -I/mtg/arc/gcc-4.3.2/gcc -I/mtg/arc/gcc-4.3.2/gcc/.
-I/mtg/arc/gcc-4.3.2/gcc/../include -I./../intl
-I/mtg/arc/gcc-4.3.2/gcc/../libcpp/include -I/mtg/TOOL/powerpc-AIX5.2/include
-I/mtg/TOOL/include -I/mtg/arc/gcc-4.3.2/gcc/../libdecnumber
-I/mtg/arc/gcc-4.3.2/gcc/../libdecnumber/dpd -I../libdecnumber   
insn-attrtab.c -o insn-attrtab.o
/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/xgcc
-B/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/
-B/mtg/TOOL/gcc-4.3.2/powerpc-AIX5.2/powerpc-ibm-aix5.2.0.0/bin/ -c   -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros  -Wno-overlength-strings  
 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/mtg/arc/gcc-4.3.2/gcc
-I/mtg/arc/gcc-4.3.2/gcc/build -I/mtg/arc/gcc-4.3.2/gcc/../include -I./../intl
-I/mtg/arc/gcc-4.3.2/gcc/../libcpp/include -I/mtg/TOOL/powerpc-AIX5.2/include
-I/mtg/TOOL/include -I/mtg/arc/gcc-4.3.2/gcc/../libdecnumber
-I/mtg/arc/gcc-4.3.2/gcc/../libdecnumber/dpd -I../libdecnumber-o
build/genautomata.o /mtg/arc/gcc-4.3.2/gcc/genautomata.c
/mtg/arc/gcc-4.3.2/gcc/genautomata.c: In function 'create_automata':
/mtg/arc/gcc-4.3.2/gcc/genautomata.c:6534: internal compiler error: Illegal
instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [build/genautomata.o] Error 1
make[4]: Leaving directory `/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/gcc'
make[3]: *** [all-stage2-gcc] Error 2
m

[Bug bootstrap/37733] GCC Bootstrap fails in Stage 2 AIX 5.2

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-03 22:30 ---
What is your stack size limit set to?


-- 


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

[Bug bootstrap/37733] GCC Bootstrap fails in Stage 2 AIX 5.2

[JFTrudeau at cvty dot com]

--- Comment #2 from JFTrudeau at cvty dot com  2008-10-03 22:34 ---
Created an attachment (id=16460)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16460&action=view)
Complete transcript of failed bootstrap


-- 


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

[Bug tree-optimization/37732] [4.2/4.3/4.4 Regression] 40% slower numeric sort

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-03 22:36 ---
Dup of PR21485?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||21485


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

[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-10-03 22:42 
---
Benjamin, any feedback on this? Thanks!


-- 


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

[Bug tree-optimization/37732] [4.2/4.3/4.4 Regression] 40% slower numeric sort

[wbrana at gmail dot com]

--- Comment #2 from wbrana at gmail dot com  2008-10-03 22:47 ---
(In reply to comment #1)
> Dup of PR21485?
> 

PR21485 is ignored by reporter and doesn't have updated summary.


-- 


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

[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-10-03 22:47 ---
Gcc 4.0.4 works.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to work|2.95.4 3.3.6 3.4.6  |2.95.4 3.3.6 3.4.6 4.0.4


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

[Bug c++/37554] [4.3/4.4 regression] ICE with invalid cast

[simartin at gcc dot gnu dot org]

--- Comment #2 from simartin at gcc dot gnu dot org  2008-10-03 22:53 
---
Introduced by a new gcc_assert (wrapped in ENABLE_CHECKING) in the fix for
PR35056 (this assert was discussed starting from
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00181.html)


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||simartin at gcc dot gnu dot
   ||org


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

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

[paolo dot carlini at oracle dot com]

--- Comment #15 from paolo dot carlini at oracle dot com  2008-10-03 22:56 
---
*** Bug 36893 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug libstdc++/36893] iterator copying doesn't work for debug mode unordered_multimap

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-10-03 22:56 
---
Fixed.

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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/37733] GCC Bootstrap fails in Stage 2 AIX 5.2

[JFTrudeau at cvty dot com]

--- Comment #3 from JFTrudeau at cvty dot com  2008-10-03 22:36 ---
(In reply to comment #1)
> What is your stack size limit set to?
> 

/mtg/arc$ /usr/bin/ulimit -a
time(seconds)unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes)4194304
memory(kbytes)   unlimited
coredump(blocks) unlimited
nofiles(descriptors) 8192
/mtg/arc$ 


-- 


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

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-10-03 23:06 
---
Ralf, any feedback on this issue? Thanks!


-- 


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

[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] codegen regression due to PRE increasing register pressure (missing load PRE really)

[rguenth at gcc dot gnu dot org]

--- Comment #28 from rguenth at gcc dot gnu dot org  2008-10-03 23:18 
---
nbench 2.2.3 numeric sort test executes 40% less iterations per second
when compiled with 4.4 snapshot than with 3.4.6

iterations/s - version
2439 - 3.4.6
1530 - 4.4.0 20080926 (experimental)
1526 - 4.3.2 
1580 - 4.2.4

CFLAGS = -s -static -Wall -O3 -g0 -march=nocona -fomit-frame-pointer
-funroll-loops -ffast-math

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST: Iterations/sec.  : Old Index   : New Index
:  : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT:  2439.1  :  62.55  :  20.54
STRING SORT :  373.28  : 166.79  :  25.82
BITFIELD:  5.9879e+08  : 102.71  :  21.45
FP EMULATION:  267.84  : 128.52  :  29.66
FOURIER :   43702  :  49.70  :  27.92
ASSIGNMENT  :  56.657  : 215.59  :  55.92
IDEA:  5407.7  :  82.71  :  24.56
HUFFMAN :  3204.3  :  88.86  :  28.37
NEURAL NET  :  57.485  :  92.35  :  38.84
LU DECOMPOSITION:  2363.5  : 122.44  :  88.41
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX   : 111.792
FLOATING-POINT INDEX: 82.519
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW===
CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750  @
2.66GHz 3200MHz
L2 Cache: 4096 KB
OS  : Linux 2.6.26.5
C compiler  : gcc version 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0,
pie-8.7.10)
libc: libc-2.8.so
MEMORY INDEX: 31.404
INTEGER INDEX   : 25.525
FLOATING-POINT INDEX: 45.768
Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST: Iterations/sec.  : Old Index   : New Index
:  : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT:  1530.9  :  39.26  :  12.89
STRING SORT :  372.64  : 166.51  :  25.77
BITFIELD:  6.0348e+08  : 103.52  :  21.62
FP EMULATION:   310.4  : 148.94  :  34.37
FOURIER :   31760  :  36.12  :  20.29
ASSIGNMENT  :  48.361  : 184.02  :  47.73
IDEA:9204  : 140.77  :  41.80
HUFFMAN :  3554.3  :  98.56  :  31.47
NEURAL NET  :  73.882  : 118.69  :  49.92
LU DECOMPOSITION:  2322.2  : 120.30  :  86.87
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX   : 114.457
FLOATING-POINT INDEX: 80.190
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW===
CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E6750  @
2.66GHz 3200MHz
L2 Cache: 4096 KB
OS  : Linux 2.6.26.5
C compiler  : gcc version 4.4.0 20080926 (experimental) (GCC)
libc: libc-2.8.so
MEMORY INDEX: 29.851
INTEGER INDEX   : 27.632
FLOATING-POINT INDEX: 44.477
Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST: Iterations/sec.  : Old Index   : New Index
:  : Pentium 90* : AMD K6/233*
:--:-:
NUMERIC SORT:  1526.2  :  39.14  :  12.85
STRING SORT :  374.28  : 167.24  :  25.89
BITFIELD:  6.0262e+08  : 103.37  :  21.59
FP EMULATION:  320.64  : 153.86  :  35.50
FOURIER :   33352  :  37.93  :  21.30
ASSIGNMENT  :  57.834  : 220.07  :  57.08
IDEA:9288  : 142.06  :  42.18
HUFFMAN :3211  :  89.04  :  28.43
NEURAL NET  :   74.69  : 119.98  :  50.47
LU DECOMPOSITION:  2655.7  : 137.58  :  99.35
==ORIGINAL BYTEMARK R

[Bug tree-optimization/37732] [4.2/4.3/4.4 Regression] 40% slower numeric sort

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-10-03 23:18 ---


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


-- 

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

[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] codegen regression due to PRE increasing register pressure (missing load PRE really)

[rguenth at gcc dot gnu dot org]

--- Comment #29 from rguenth at gcc dot gnu dot org  2008-10-03 23:18 
---
*** Bug 37732 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE

[rguenth at gcc dot gnu dot org]

--- Comment #30 from rguenth at gcc dot gnu dot org  2008-10-03 23:54 
---
Comment #6 still applies.  On the trunk we do not fully exploit the partial
redundant load of array[k] in

  if (k < j) 
if (array[k] < array[k + 1L]) 
  ++k; 
  if (array[i] < array[k]) 

but we transform the above to

  if (k < j)
{
  tmp1 = array[k];
  tmp2 = array[k+1];
  if (tmp1 < tmp2)
++k;
  else
tmp1 = array[k+1];
}
  if (array[i] < tmp1)

missing the full redundancy of array[k+1].

Reduced testcase:

long
NumSift (long *array, unsigned long k)
{
  if (array[k] < array[k + 1L])
++k;
  return array[k];
}

with integer k it gets somewhat more complicated even.

The question is whether this explains the slowdown compared to GCC 3.4.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-07-05 09:23:46 |2008-10-03 23:54:40
   date||
Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression]
   |codegen regression due to   |missed load PRE
   |PRE increasing register |
   |pressure (missing load PRE  |
   |really) |


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

[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE

[pinskia at gcc dot gnu dot org]

--- Comment #31 from pinskia at gcc dot gnu dot org  2008-10-04 00:13 
---
the reduced testcase in comment #30 is optimized by DOM3 though not by PRE.
Running PRE again right after the first PRE still founds more PREable
expressions for this testcase ...


-- 


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

[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck

[rguenth at gcc dot gnu dot org]

--- Comment #32 from rguenth at gcc dot gnu dot org  2008-10-04 00:57 
---
As we PHI-translate k_1 * 4 we are not able to find D.1237_7 * 4 in the
SCCVN tables.  So we allocate a new value-id for it.  Oops.  This is because
once we say its type is unsigned int and once it's unsigned long.  And
we require types to be pointer-equal in the hash comparison fn.

I have a patch to fix this which makes this run even more slow.  -fno-tree-pre
fixes the speed regression.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression]
   |missed load PRE |missed load PRE, PRE makes
   ||i?86 suck


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

[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2008-10-04 01:06 ---
This regression was introduced between 2005-03-11 and 2005-03-13.
This patch:

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01296.html

may be the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu dot org


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

[Bug middle-end/37731] [4.2/4.3/4.4 Regression] unsigned long long may not work correctly on 32bit host

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-10-04 01:33 ---
(In reply to comment #7)
> This regression was introduced between 2005-03-11 and 2005-03-13.
> This patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01296.html
> 
> may be the cause.
> 

It is the cause. This patch seems to work:

Index: expmed.c
===
--- expmed.c(revision 140780)
+++ expmed.c(working copy)
@@ -3092,7 +3092,7 @@
 produce a smaller program when -O is not used.  But this causes
 such a terrible slowdown sometimes that it seems better to always
 use synth_mult.  */
-  if (coeff != 0)
+  if (coeff > 0 || (coeff != 0 && !unsignedp))
{
  /* Special case powers of two.  */
  if (EXACT_POWER_OF_2_OR_ZERO_P (coeff))


-- 


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

[Bug target/37734] New: Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero

[siarhei dot siamashka at gmail dot com]

For the following source:
//
extern void a();

int unrolled_loop_fn(int count)
{
while ((count -= 2) >= 0) {
a();
a();
}
if (count & 1) {
a();
}
}
//

'gcc -O2 -c test.c' produces the following quite suboptimal code:

 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   56  push   %esi
   4:   8b 75 08mov0x8(%ebp),%esi
   7:   53  push   %ebx
   8:   83 ee 02sub$0x2,%esi
   b:   85 f6   test   %esi,%esi
   d:   89 f0   mov%esi,%eax
   f:   78 1c   js 2d 
  11:   89 f3   mov%esi,%ebx
  13:   90  nop
  14:   8d 74 26 00 lea0x0(%esi),%esi
  18:   e8 fc ff ff ff  call   19 
  1d:   e8 fc ff ff ff  call   1e 
  22:   83 eb 02sub$0x2,%ebx
  25:   79 f1   jns18 
  27:   83 e6 01and$0x1,%esi
  2a:   8d 46 felea-0x2(%esi),%eax
  2d:   a8 01   test   $0x1,%al
  2f:   74 05   je 36 
  31:   e8 fc ff ff ff  call   32 
  36:   5b  pop%ebx
  37:   5e  pop%esi
  38:   5d  pop%ebp
  39:   c3  ret


-- 
   Summary: Missing optimization: gcc fails to reuse flags from
already calculated expression for condition check with
zero
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: siarhei dot siamashka at gmail dot com
 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=37734

[Bug target/37734] Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero

[siarhei dot siamashka at gmail dot com]

--- Comment #1 from siarhei dot siamashka at gmail dot com  2008-10-04 
02:48 ---
For -Os optimization, the generated code is much better:

 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   53  push   %ebx
   4:   83 ec 04sub$0x4,%esp
   7:   8b 5d 08mov0x8(%ebp),%ebx
   a:   eb 0a   jmp16 
   c:   e8 fc ff ff ff  call   d 
  11:   e8 fc ff ff ff  call   12 
  16:   83 eb 02sub$0x2,%ebx
  19:   79 f1   jnsc 
  1b:   80 e3 01and$0x1,%bl
  1e:   74 05   je 25 
  20:   e8 fc ff ff ff  call   21 
  25:   5a  pop%edx
  26:   5b  pop%ebx
  27:   5d  pop%ebp
  28:   c3  ret


-- 


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

[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering

[jifl-bugzilla at jifvik dot org]

--- Comment #7 from jifl-bugzilla at jifvik dot org  2008-10-04 02:54 
---
To avoid any uncertainty, I arranged a copyright assignment. Unfortunately the
FSF's copyright clerk left and there was a gap before the replacement started,
but it just so happens that today he confirmed the assignment has been
completed. I note that /home/g/gnuorg/copyright.list on fencepost.gnu.org has
not yet been updated, but I can mail the PDF (privately) if you wish, or you
can contact [EMAIL PROTECTED] for confirmation.

The upshot is that the copyright of this patch is not something to worry about
anyway.


-- 


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

[Bug fortran/37605] Remarks on user manual for Gfortran

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-10-04 06:45 ---
Created an attachment (id=16461)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16461&action=view)
Patch addressing most of the "specific" remarks

This patch (posted to the list some time ago) addresses most of the specific
remarks; I'm not sure what we should do about it, but in my opinion at least
most of them are really improvements nice to have.


-- 


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