[Bug c++/21675] New: -fvisibility : misleading documentation and low QoI

[ofv at wanadoo dot es]

The -fvisibility documentation talks about declarations when explaining where 
to 
put __attribute__ ((visibility("default"))). However, compiling this code:

class __attribute__ ((visibility("default"))) Foo;
class Foo {};

produces a warning:

warning: type attributes are honored only at type definition

The mentions to Windows DLLs on the documentation and the web pages it refers 
to 
are misleading: Windows compilers allows dll-exporting by putting 
__declspec(dllexport) on the declarations. Lots of dll-aware Windows and 
cross-platform code (ex. wxWindows) puts the __declspect(dllexport|dllimport) 
on 
declarations. By disallowing attributes on declarations, you difficult the use 
of the visibility feature for those libraries and break the builds on Windows 
with MinGW.

I suggest to allow (at least certain) attributes on declarations as it was the 
case for MinGW until recently or change the -fvisibility documentation for 
explicitly saying that __attribute__ ((visibility("default"))) should be used 
on 
definitions only.

-- 
   Summary: -fvisibility : misleading documentation and low QoI
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ofv at wanadoo dot es
CC: gcc-bugs at gcc dot gnu dot org
 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=21675

[Bug libgcj/19877] sometimes reconfiguring leads to incorrect config.h

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-20 
03:30 ---
I'm testing a fix.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug libstdc++/21674] New: basic_string vs debug_mode

[pcarlini at suse dot de]

Just to keep track of this tough issue, discussed in:

  http://gcc.gnu.org/ml/libstdc++/2005-05/msg00192.html

In a nutshell, this testcase doesn't assert and should:

#define _GLIBCXX_DEBUG
#include 
int main()
{
std::string s;
s[1];
}

(change std::string to std::basic_string and it does)

-- 
   Summary: basic_string vs debug_mode
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug other/21669] [4.1 Regression] unwind.h uses gcc_unreachable

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-20 
01:06 ---
Fixed by:

 2005-05-19  Richard Henderson  <[EMAIL PROTECTED]>
 
* unwind.h, unwind-pe.h: Revert gcc_unreachable change of 05-17.



-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/21673] gfortran binary file format

[blime at cox dot net]

--- Additional Comments From blime at cox dot net  2005-05-20 00:58 ---
Subject: Re:  gfortran binary file format

Thanks for pointing me to the background. I searched, but used the wrong 
words.
I also recall something about 32 bit initial implementation for gfortran 
in  gcc-4.0, and
a record size of 64bit for all targets is counter to that idea.
What about compatability between gcc-4.0 - c++ and gfortran ? Are not 
c++ targets 32 bit?

blime

pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
>23:55 ---
>Try looking at: .
>The record size is 64bit on all targets now unlike in g77 so it is binary 
>compatiable to g77 on 64bit 
>targets.
>
>  
>


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-20 00:15 ---
Subject: Re:  Loses temporary in complex expression

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| (In reply to comment #9)
| > And we can construct more.  But it does not rule out the fact that we
| > should handle the simple cases.
| 
| What assuming |= returns *this, that is just wrong and you know it,

I can't parse that.

| if the compiler assumes that, then we will get false warnings for
| places which don't return a reference to a temporary variable. 

Since you're crediting me of knowing something (I don't know exactly
what :-)) you must also credit me of not wanting false warnings.

-- Gaby


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-20 00:12 ---
Subject: Re:  Loses temporary in complex expression

"igodard at pacbell dot net" <[EMAIL PROTECTED]> writes:

| In particular, once you get all the template armwaving out of it:
| 
| int& foo(int i) { return i; }
| 
| should warn and does not.

It does with my compiler:
% cat a.C && g++ -c -Wall a.C 

int& f(int i)
{
   return i;
}
a.C: In function 'int& f(int)':
a.C:2: warning: reference to local variable 'i' returned

-- Gaby


-- 


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

[Bug fortran/21673] gfortran binary file format

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:55 ---
Try looking at: .
The record size is 64bit on all targets now unlike in g77 so it is binary 
compatiable to g77 on 64bit 
targets.

-- 
   What|Removed |Added

   Severity|critical|normal
   Priority|P1  |P2


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

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 23:54 
---
So the bug should be changed to "valid, verified, already fixed, won't back 
port"?

-- 


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

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:46 ---
(In reply to comment #12)
> In particular, once you get all the template armwaving out of it:
> 
> int& foo(int i) { return i; }
> 
> should warn and does not.

The following example does not warn before 4.0.0:
template
int& foo(int i) { return i; }
int &g = foo<1>(1);

So that problem was already fixed.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 23:42 
---
In particular, once you get all the template armwaving out of it:

int& foo(int i) { return i; }

should warn and does not.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:42 ---
(In reply to comment #9)
> And we can construct more.  But it does not rule out the fact that we
> should handle the simple cases.

Also if you read comment #4, the simple cases are already handled.

-- 


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

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:40 ---
(In reply to comment #9)
> And we can construct more.  But it does not rule out the fact that we
> should handle the simple cases.

What assuming |= returns *this, that is just wrong and you know it, if the 
compiler assumes that, then 
we will get false warnings for places which don't return a reference to a 
temporary variable.

Also I copied the code from his example so the example in comment #5 is just a 
reduced testcase for 
his example.

-- 


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

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-19 23:35 ---
Subject: Re:  Loses temporary in complex expression

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| Here is another example where we don't know for sure it shows how the 
compiler uses operators in 
| C++:
| template const
|  T& g(T t1, const T& t2) { return t1.h(t2); }
| 
| struct f{ f &h(const f&);};
| f i;
| f j;
| 
| f h = g(i , j);
| 
| h is the operator for |= and g is the operator for |.

And we can construct more.  But it does not rule out the fact that we
should handle the simple cases.

-- Gaby


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-19 23:31 ---
Subject: Re:  Loses temporary in complex expression

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| --- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:19 ---
| (In reply to comment #4)
| > but apparently the warning logic overlooks the same problem when returning
| > arguments.
| 
| Actually it cannot know and here is why,

Andrew --

  Please, be less hastly when analyzing PRs.  If you look through the
claims, some of them are valid.  

| take the following example:
| template const
|  T& operator |(T t1, const T& t2) { return t1 |= t2; }
| 
| struct f{ f &operator|=(const f&);};
| f i;
| f j;
| 
| f h = i | j;
| 
| We call |= which it self returns a reference so there is no way to
| the compiler to know it is actually returning a local variable or
| not.

Yes, but not all cases fall under that complication.  Simple cases
should be handled.  Please reopen this PR.

-- Gaby


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-19 23:27 ---
Subject: Re:  Loses temporary in complex expression

"igodard at pacbell dot net" <[EMAIL PROTECTED]> writes:

| Yes, the friend function is returning a reference to its own argument, though
| that seems to disappear as the body gets inlined in *most* cases :-)
| 
| So please reopen this as a "missing warning" bug. In most cases of returning
| a reference to a function local, like:
| 
| int& foo() { int i; return i; }
| 
| you get:
| ~/ootbc/members$ g++ foo.cc
| foo.cc: In function `int& foo()':
| foo.cc:1: warning: reference to local variable `i' returned
| 
| but apparently the warning logic overlooks the same problem when returning
| arguments.

agreed.

-- Gaby


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:21 ---
Here is another example where we don't know for sure it shows how the compiler 
uses operators in 
C++:
template const
 T& g(T t1, const T& t2) { return t1.h(t2); }

struct f{ f &h(const f&);};
f i;
f j;

f h = g(i , j);

h is the operator for |= and g is the operator for |.


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
23:19 ---
(In reply to comment #4)
> but apparently the warning logic overlooks the same problem when returning
> arguments.

Actually it cannot know and here is why,
take the following example:
template const
 T& operator |(T t1, const T& t2) { return t1 |= t2; }

struct f{ f &operator|=(const f&);};
f i;
f j;

f h = i | j;

We call |= which it self returns a reference so there is no way to the compiler 
to know it is actually 
returning a local variable or not.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 23:11 
---
Yes, the friend function is returning a reference to its own argument, though
that seems to disappear as the body gets inlined in *most* cases :-)

So please reopen this as a "missing warning" bug. In most cases of returning
a reference to a function local, like:

int& foo() { int i; return i; }

you get:
~/ootbc/members$ g++ foo.cc
foo.cc: In function `int& foo()':
foo.cc:1: warning: reference to local variable `i' returned

but apparently the warning logic overlooks the same problem when returning
arguments.

Ivan

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-05-19 23:10 ---
Subject: Re:  FAIL: gfortran.dg/eoshift.f90  -O0  execution test

> > I have no idea why it would only fail at -O0 though, the .original dump on
> > i586-linux looks fine, and there's nothing strongly system specific in it.
> 
> This may be due to an uninitialized variable.

As of last night, it failed on hppa-linux:

May 19 01:37:57 gsyprf11 kernel: do_page_fault() pid=29787 command='eoshift.exe'
 type=15 address=0x

Failure is caused by dereferencing a null pointer.

(gdb) r
Starting program: /home/dave/gcc-4.1/objdir/gcc/testsuite/eoshift.xg

Program received signal SIGSEGV, Segmentation fault.
0x000109a8 in MAIN__ ()
at /home/dave/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/eoshift.f90:5
5 write (line,'(I4)') eoshift((/1, 3/), 3)
Current language:  auto; currently fortran
(gdb) bt
#0  0x000109a8 in MAIN__ ()
at /home/dave/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/eoshift.f90:5
#1  0x00010a00 in main (argc=Variable "argc" is not available.
) at ../../../gcc/libgfortran/fmain.c:18

Dave


-- 


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

[Bug fortran/21673] New: gfortran binary file format

[blime at cox dot net]

The way the binary record length is encoded appears to be changed
from g77 to gfortran.

  1.  Compatibility between gcc-3.x.x -  g77  and gcc-4.0 - gfortran
  -- not compatible and not a big problem, but don't know why it
  should change
  2.  Compatibility between gcc-3.x.x - cpp and g77 -- compatible.
  3.  Compatibility between gcc-4.0 - cpp and gfortran -- the problem

-- 
   Summary: gfortran binary file format
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: blime at cox dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug java/19870] gcj -C doesn't generate accessors for private members in inner class

[rmathew at gcc dot gnu dot org]

--- Additional Comments From rmathew at gcc dot gnu dot org  2005-05-19 
22:57 ---
I note that GCJ already seems to have the infrastructure in place to do this and
possibly used to work properly for this case. For example, see the
build_outer_field_access(), outer_field_access_p(), etc. methods in parse.y. The
patch to turn this on seems to have been:

2000-02-03  Alexandre Petit-Bianco  <[EMAIL PROTECTED]>

* java-tree.h (FIELD_THISN): New macro.
* jcf-write.c (append_synthetic_attribute): New function.
(generate_classfile): Set "Synthetic" attribute on this$,
val$ fields, access$ and $finit$ methods. Fixed indentation.
* parse.y (add_inner_class_fields): Set FIELD_THISN for created
this$ fields.
(build_outer_field_access): Turned on access functions usage and
generation when compiling to bytecode.
(maybe_use_access_method): Likewise.

As with other such things in GCJ, this seems to have bitrotted over time. :-(

-- 


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

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
22:56 ---
Not a bug because:
 friend
 const
 T& operator |(T t1, const T& t2) { return t1 |= t2; }
is being invoked, this comes from:
template
class logicalMixin {

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/21671] Returning result of long long multiply from function clobbers lower 32 bits

[schwab at suse dot de]

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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

[Bug libfortran/21127] reshape of complex broken

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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

[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
22:28 ---
(In reply to comment #4)
> Does this also fail on 4.1 (which has the initialization fixes in)?

Yes as of last night at least.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-19 
22:22 ---
(In reply to comment #3)

> I have no idea why it would only fail at -O0 though, the .original dump on
> i586-linux looks fine, and there's nothing strongly system specific in it.

This may be due to an uninitialized variable.

Does this also fail on 4.1 (which has the initialization fixes in)?


-- 


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

[Bug fortran/20923] Compile time is high for the following code

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 22:19 
---
One more thing I forgot to mention: for n = 100 the .original dump looks like 
this:
int4 offset.1;
struct array1_int4 atmp.0;

atmp.0.dtype = 265;
atmp.0.dim[0].stride = 1;
atmp.0.dim[0].lbound = 0;
atmp.0.dim[0].ubound = ;
atmp.0.data = (int4[0:] *) _gfortran_internal_malloc (4);
atmp.0.offset = 0;
offset.1 = 0;
j = 1;
while (1)
  {
if (j > 100) goto L.1; else (void) 0;
(*atmp.0.data)[offset.1] = j + 4;
offset.1 = offset.1 + 1;
(*atmp.0.data)[offset.1] = j + 5;
offset.1 = offset.1 + 1;
(*atmp.0.data)[offset.1] = j + 6;
offset.1 = offset.1 + 1;
(*atmp.0.data)[offset.1] = j + 7;
...
offset.1 = offset.1 + 1;
(*atmp.0.data)[offset.1] = j + 102;
offset.1 = offset.1 + 1;
(*atmp.0.data)[offset.1] = j + 103;
offset.1 = offset.1 + 1;
j = j + 1;
 etc.

which is probably not what we want.  The optimizers can't reduce this to the
original form either.

-- 


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

[Bug fortran/20923] Compile time is high for the following code

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 22:14 
---
ugh, it is quadratic, only the inner array constructor gets expanded. And this
is where the <= 100 restriction I alluded to above comes in.  For n = 100 the
relevant line from the -fdump-parse-tree output looks like:
  ASSIGN vect(:) __convert_i4_r4[[(((/ ((/ (+ (+ 1 j) 3) , (+ (+ 2 j) 3) ,
(+ (+ 3 j) 3) , (+ (+ 4 j) 3) , (+ (+ 5 j) 3) , (+ (+ 6 j) 3) , (+ (+ 7 j) 3) ,
(+ (+ 8 j) 3) , (+ (+ 9 j) 3) , (+ (+ 10 j) 3) , (+ (+ 11 j) 3) , (+ (+ 12 j)
3), (+ (+ 13 j) 3) , (+ (+ 14 j) 3) , (+ (+ 15 j) 3) , (+ (+ 16 j) 3) , (+ (+ 17
j) 3) , (+ (+ 18 j) 3) , (+ (+ 19 j) 3) , (+ (+ 20 j) 3) , (+ (+ 21 j) 3) , (+
(+ 22 j) 3) , (+ (+ 23 j) 3) , (+ (+ 24 j) 3) , (+ (+ 25 j) 3) , (+ (+ 26 j) 3)
,(+ (+ 27 j) 3) , (+ (+ 28 j) 3) , (+ (+ 29 j) 3) , (+ (+ 30 j) 3) , (+ (+ 31
j)3) , (+ (+ 32 j) 3) , (+ (+ 33 j) 3) , (+ (+ 34 j) 3) , (+ (+ 35 j) 3) , (+ (+
36 j) 3) , (+ (+ 37 j) 3) , (+ (+ 38 j) 3) , (+ (+ 39 j) 3) , (+ (+ 40 j) 3) ,
(+ (+ 41 j) 3) , (+ (+ 42 j) 3) , (+ (+ 43 j) 3) , (+ (+ 44 j) 3) , (+ (+ 45 j)
3) , (+ (+ 46 j) 3) , (+ (+ 47 j) 3) , (+ (+ 48 j) 3) , (+ (+ 49 j) 3) , (+ (+
50j) 3) , (+ (+ 51 j) 3) , (+ (+ 52 j) 3) , (+ (+ 53 j) 3) , (+ (+ 54 j) 3) , (+
(+ 55 j) 3) , (+ (+ 56 j) 3) , (+ (+ 57 j) 3) , (+ (+ 58 j) 3) , (+ (+ 59 j) 3)
, (+ (+ 60 j) 3) , (+ (+ 61 j) 3) , (+ (+ 62 j) 3) , (+ (+ 63 j) 3) , (+ (+ 64
j) 3) , (+ (+ 65 j) 3) , (+ (+ 66 j) 3) , (+ (+ 67 j) 3) , (+ (+ 68 j) 3) , (+
(+69 j) 3) , (+ (+ 70 j) 3) , (+ (+ 71 j) 3) , (+ (+ 72 j) 3) , (+ (+ 73 j) 3) ,
(+ (+ 74 j) 3) , (+ (+ 75 j) 3) , (+ (+ 76 j) 3) , (+ (+ 77 j) 3) , (+ (+ 78 j)
3) , (+ (+ 79 j) 3) , (+ (+ 80 j) 3) , (+ (+ 81 j) 3) , (+ (+ 82 j) 3) , (+ (+
83 j) 3) , (+ (+ 84 j) 3) , (+ (+ 85 j) 3) , (+ (+ 86 j) 3) , (+ (+ 87 j) 3) ,
(+(+ 88 j) 3) , (+ (+ 89 j) 3) , (+ (+ 90 j) 3) , (+ (+ 91 j) 3) , (+ (+ 92 j)
3), (+ (+ 93 j) 3) , (+ (+ 94 j) 3) , (+ (+ 95 j) 3) , (+ (+ 96 j) 3) , (+ (+ 97
j) 3) , (+ (+ 98 j) 3) , (+ (+ 99 j) 3) , (+ (+ 100 j) 3) /) j=1,100,1) /)))]]

while for n = 101 it loks like:
 ASSIGN vect(:) __convert_i4_r4[[(((/ ((/ ((/ (+ (+ i j) 3) /) i=1,101,1) /)
j=1,101,1) /)))]]

IOW the array constructor is not expanded any longer, but still the compilation
takes longer :-(

-- 


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

[Bug libfortran/21127] reshape of complex broken

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-19 
22:10 ---
Fixed on mainline and 4.0.

There are still some reshape bugs in 4.0 which are not specific to
complex numbers, and whose fixes need to be backported.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/20923] Compile time is high for the following code

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 22:09 
---
The time behavior is strictly linear BTW:
n = 100:
real0m0.604s
user0m0.485s
sys 0m0.021s
n = 1000:
real1m0.860s
user0m49.055s
sys 0m0.078s

(the array grows quadratically with n)

One thing that's interesting is that in the -fdump-parse-tree output the array
constructor is only expanded in the first case but not in the second, so it
looks like in the latter case we explicitly calculate the array and then throw
it away.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


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

[Bug libfortran/21127] reshape of complex broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-19 
22:07 ---
Subject: Bug 21127

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-19 22:07:07

Modified files:
libgfortran: Makefile.am Makefile.in ChangeLog 
gcc/fortran: ChangeLog iresolve.c 
gcc/testsuite  : ChangeLog 
libgfortran/m4 : iparm.m4 reshape.m4 
Added files:
libgfortran/generated: reshape_c4.c reshape_c8.c 
gcc/testsuite/gfortran.dg: reshape-complex.f90 

Log message:
2005-05-18  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/21127
* Makefile.am:  Add generated/reshape_c4.c and
generated/reshape_c8.c.
* Makefile.in:  Regenerated.
* m4/iparm.m4:  Define rtype_ccode to be c4 or c8 for
complex types, 4 or 8 otherwise.
* m4/reshape.m4:  Use rtype_ccode instead of rtype_kind
in function name.
* generated/reshape_c4.c: New file.
* generated/reshape_c8.c: New file.

2005-05-18  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/21127
* fortran/iresolve.c (gfc_resolve_reshape): Add
gfc_type_letter (BT_COMPLEX) for complex to
to resolved function name.

2005-05-18  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/21127
* gfortran.dg/reshape-complex.f90:  New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.am.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.29.10.3&r2=1.29.10.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.30.10.3&r2=1.30.10.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.32&r2=1.163.2.33
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.52&r2=1.335.2.53
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/iresolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.1&r2=1.32.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.188&r2=1.5084.2.189
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/reshape-complex.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/iparm.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4&r2=1.4.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.12.1



-- 


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

[Bug target/21671] Returning result of long long multiply from function clobbers lower 32 bits

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||wrong-code


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

[Bug c/21666] Optimization level -O2 breaks float (double) conversion

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
21:34 ---
(In reply to comment #2)
> Subject: Re:  Optimization level -O2 breaks float (double) conversion
> 
> Dear Pinski and Co.,
> As a former compiler developer myself I was just trying to help, and I'm 
> sorry to tell you that your answer was not to the point.

The code is undefined by the C standard so we could compile it to make your 
hardware unusable after 
you execute that code (yes I am joking but that is what the C standard allows 
us to do).  read http://
gcc.gnu.org/bugs.html and the explication on that page about this commonly 
reported bug.

You can either workaround it by using -fno-strict-aliasing or using an union.  
And yes the compiler 
does generate a warning with -Wstrict-aliasing (which is included with -Wall).

-- 


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

[Bug other/21669] [4.1 Regression] unwind.h uses gcc_unreachable

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||nathan at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.1.0


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

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 21:22 
---
Created an attachment (id=8932)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8932&action=view)
source code (compressed)


-- 


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

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 21:22 
---
Created an attachment (id=8931)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8931&action=view)
compiler output


-- 


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

[Bug c++/21672] New: Loses temporary in complex expression

[igodard at pacbell dot net]

The attached source (and compiler output) produces the "testBitset" executable, 
which when run (no command line arguments) prints to std::cerr:

~/ootbc/common/test/src$ testBitset
p is: bitset{a, c, e, g, k}
q is: bitset{b:c, h, j:k}
r is: bitset{a:c, e, g:h, j:k}
but (p|q) is: bitset{d, f, h, j:k}

"bitset" is a class that is similar to std::bitset except that it has one bit 
for each member of the enumeration that is a template argument to bitset. It is 
built on top of std::bitset and all bitset operations ultimately reflect to 
std::bitset.

Stream operator<< is overloaded to display bitsets as shown above. Bitset 
defines operator| to produce a new bitset (of the same type) that is the 
bitwise 
"or" of the two arguments; this reflects ultimately to std::bitset::operator|=.

The test case "main" contains "bitset r = (p|q);", where "p|q" produces a 
temporary that is immediately used to initialize r. When printed out by 
"std::cerr << r" this prints the correct value for the result of the "|" 
operation.

However, if the "|" result is not stored into a variable but instead the 
temporary is passed directly to the streaming operator<< by "std::cerr << 
(p|q)" 
then the printed value is garbage. Exploration with the debugger shows that the 
temporary is being overwritten. The temporary should live to the end of the 
largest surrounding expression, which is the whole print statement, but it is 
not.

-- 
   Summary: Loses temporary in complex expression
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21671] New: Returning result of long long multiply from function clobbers lower 32 bits

[j33433 at gmail dot com]

m68k-unknown-elf-gcc (GCC) 3.4.4

Bug: long long multiply is broken when returning the result from a
subroutine. When using -O3 or higher, the lower half of the 64 bit
result is set to zero. This example works correctly with -O2.

Do not compile ll.c and ll_test.c as one file. Test case 2
fails (2LL * 2LL), the variable 'res' is zero.

m68k-unknown-elf-gcc -Wall -mcpu32 -c -O3 ll.c

/*
 * ll.c
 */

long long
mul_ll (long long a, long long b)
{
return a * b;
}

/*
 * ll_test.c
 */

long long mul_ll (long long a, long long b);

typedef struct
{
long long a;
long long b;
long long result;
}
ll_test;

int
main (void)
{
ll_test cases[] =
{
{
1073741824LL, /* 2 ^ 30 */
1000LL,
1073741824000LL
},
{
536870912LL,  /* 2 ^ 29 */
2LL,
1073741824LL,
},
{
2LL,
2LL,
4LL,
}
};
int i;
long long res;

for (i = 0; i < (sizeof (cases) / sizeof (cases[0])); i++)
{
res = mul_ll (cases[i].a, cases[i].b);

if (res != cases[i].result)
{
printf ("case %d failed\n", i);
}
}

return 0;
}

mul_ll:
link.w %a6,#0
movm.l #0x3f00,-(%sp)
clr.l %d0
clr.l %d1
move.l 8(%a6),%d4
move.l 12(%a6),%d5
move.l 16(%a6),%d2
move.l 20(%a6),%d3
move.l %d5,%d7
mulu.l %d3,%d0:%d7  *** %d7 should be %d1 ***
move.l %d5,%d6
muls.l %d2,%d6
add.l %d0,%d6
move.l %d3,%d2
muls.l %d4,%d2
move.l %d6,%d0
add.l %d2,%d0
movm.l (%sp)+,#0xfc
unlk %a6
rts

-- 
   Summary: Returning result of long long multiply from function
clobbers lower 32 bits
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j33433 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-unknown-elf


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

[Bug c++/21670] segv after error

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 20:50 
---
Created an attachment (id=8930)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8930&action=view)
source code (compressed)


-- 


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

[Bug c++/21670] segv after error

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-19 20:49 
---
Created an attachment (id=8929)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8929&action=view)
compiler output


-- 


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

[Bug c++/21670] New: segv after error

[igodard at pacbell dot net]

 

-- 
   Summary: segv after error
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21666] Optimization level -O2 breaks float (double) conversion

[jbeitaharon at intrusic dot com]

--- Additional Comments From jbeitaharon at intrusic dot com  2005-05-19 
20:43 ---
Subject: Re:  Optimization level -O2 breaks float (double) conversion

Dear Pinskia and Co.,
As a former compiler developer myself I was just trying to help, and I'm 
sorry to tell you that your answer was not to the point.

In order to transmit this double-precision-float we have to reformat it 
into/from "Network Byte Ordering".  The compiler generated no warnings, 
and the generated code works fine when un-optimized or when optimized 
with -O1.

The problem reproduction program reformats X into Y and then reformats Y 
into X with the inverse operation.  It then verifies that the original X 
has the same value as the final X.

There is absolutely no reason why the -O2 optimization should break the 
code, and hence this bug is valid as a regression in -O2 relative to -O1.

Regards,
Jonathan

pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
>19:15 ---
>You are violating C aliasing rules:
>((long *) &s)[0] = __extension__ ({ register u_long __X = (nt.li[1]); __asm
>("xchgb %h1, %b1\n\trorl $16, %1\n\txchgb %h1, %b1" : "=q" (__X) : "0" (__X));
>__X; });
>
>s is a double but you are accessing it as a long.
>
>  
>



-- 


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

[Bug other/21669] New: [4.1 Regression] unwind.h uses gcc_unreachable

[jsm28 at gcc dot gnu dot org]

Between 20050517 and 20050519 the following failures appeared on ia64-hpux on
mainline.

FAIL: g++.dg/eh/forced1.C (test for excess errors)
FAIL: g++.dg/eh/forced2.C (test for excess errors)
FAIL: g++.dg/eh/forced3.C (test for excess errors)
FAIL: g++.dg/eh/forced4.C (test for excess errors)

/scratch/gcc/nightly-2005-05-19-mainline/ia64-hp-hpux11.23/build_gcc/install/lib/gcc/ia64-hp-hpux11.23/4.1.0/include/unwind.h:
In function '_Unwind_Ptr _Unwind_GetTextRelBase(_Unwind_Context*)':
/scratch/gcc/nightly-2005-05-19-mainline/ia64-hp-hpux11.23/build_gcc/install/lib/gcc/ia64-hp-hpux11.23/4.1.0/include/unwind.h:217:
error: 'gcc_unreachable' was not declared in this scope

As an installed header I don't think the name gcc_unreachable is part of its
proper interface.

-- 
   Summary: [4.1 Regression] unwind.h uses gcc_unreachable
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug java/17255] [meta-bug] Fixes should be back-ported to 3.4 branch

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-05-19 20:30 
---
Yeah, its probably pointless backporting anything else this late in the 3.4
cycle, especially now that 4.0 is out. I'm closing the PR.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/21653] [4.1 Regression] gcc.dg/vect failures

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-19 20:27 
---
The following failures appeared on ia64-hpux between 20050517 and 20050519 (on
20050518 there was a bootstrap failure) and appear to be the same bug.

FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors)
FAIL: gcc.dg/vect/vect-2.c (test for excess errors)
FAIL: gcc.dg/vect/vect-34.c (test for excess errors)
FAIL: gcc.dg/vect/vect-66.c (test for excess errors)
FAIL: gcc.dg/vect/vect-all.c (test for excess errors)


-- 


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

[Bug c/21664] array-of-empty-structure extension not properly defined

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-05-19 
20:20 ---
None.  But I have to deal with the possibilities of these during folding
of &a[2] == &a[1].  At least until the middle-end makes a promise that
they cannot exist (which they do), or the C frontend rejects this.  It's
really a question for advice on details of our own extension to the C language.

Richard.

-- 


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

[Bug tree-optimization/21653] [4.1 Regression] gcc.dg/vect failures

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-19 20:18 ---
Subject: Re:  [4.1 Regression] gcc.dg/vect failures

> --- Additional Comments From janis at gcc dot gnu dot org  2005-05-19 
> 19:06 ---
> The ICE shows up on powerpc-linux with this patch from rakdver:
> 
>   http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00814.html

yes, see http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00342.html and
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00803.html.

Zdenek


-- 


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

[Bug c/21668] New: gratuitous warning about "extern const" with initializer

[gdr at gcc dot gnu dot org]

gcc spits a warning on the following snippet:

% cat const-extern.c && gcc -c const-extern.c  
extern const int foo = 200;

const-extern.c:1: warning: 'foo' initialized and declared 'extern'

Notice that the code snippet is a well-defined construct at the
intersection of both C and C++, and actually is the way of
properly initializing a const object (in C++) with external
linkage -- if you remove the "extern" then, it gets an internal
linkage.  So it is not helpful for the C front-end to emit
unconditional warning on that construct -- even a pedwarn
is not helpful.

-- Gaby

-- 
   Summary: gratuitous warning about "extern const" with initializer
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: plateform independent


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

[Bug c++/21667] New: misleading warning about array subscription

[gdr at gcc dot gnu dot org]

GCC (g++) emits a warning (-Wall) for the following code

% cat ary.C && g++ -Wall ary.C
int main()
{
   int ary[256] = { 0 };
   return ary['a'];
}
ary.C: In function 'int main()':
ary.C:4: warning: array subscript has type 'char'

The diagnostic is not helpful because the index is positive 
(all character constants from the basic character set have 
nonnegative values).  
The warning should be emitted only if the index is unkonwn (at
compile time) and has type 'char'.

-- Gaby

-- 
   Summary: misleading warning about array subscription
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: plateform independent


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

[Bug c/21664] array-of-empty-structure extension not properly defined

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-19 19:45 ---
Subject: Re:  New: array-of-empty-structure extension not properly defined

"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| For
| 
| struct {} a[4]; int main() { return &a[2] - &a[1]; }
| 
| the C frontend emits
| 
|   return 0 /[ex] 0;
| 
| which will, at -O0 fault at runtime, at -O not due to RTL CSE.
| 
| Is this even well-defined?

No, as you noted below.

|  Should the C-frontend rather emit
| 
|  return 0;
| 
| ?  Of course this contradicts the C standard, but that does not
| allow empty structures anyway.

If you go back to the GCC mailing list (circa 2001, 2002), you'll see
heavy and hot debates about what the answer should be.
For that matter, the C++ standards allow empty structures but do not
allow "return 0".  I suppose the real question is what use do you have
for an array of empty structures.

-- Gaby


-- 


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

Re: [Bug c/21664] New: array-of-empty-structure extension not properly defined

[Gabriel Dos Reis]

"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| For
| 
| struct {} a[4]; int main() { return &a[2] - &a[1]; }
| 
| the C frontend emits
| 
|   return 0 /[ex] 0;
| 
| which will, at -O0 fault at runtime, at -O not due to RTL CSE.
| 
| Is this even well-defined?

No, as you noted below.

|  Should the C-frontend rather emit
| 
|  return 0;
| 
| ?  Of course this contradicts the C standard, but that does not
| allow empty structures anyway.

If you go back to the GCC mailing list (circa 2001, 2002), you'll see
heavy and hot debates about what the answer should be.
For that matter, the C++ standards allow empty structures but do not
allow "return 0".  I suppose the real question is what use do you have
for an array of empty structures.

-- Gaby

[Bug fortran/20900] use-associated variable may not be equivalenced

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2005-05-19 19:22 ---
Subject: Re:  use-associated variable may not be equivalenced

jv244 at cam dot ac dot uk wrote:
> --- Additional Comments From jv244 at cam dot ac dot uk  2005-05-19 17:54 
> ---
> (In reply to comment #1)
> 
>>There's no 11.7 neither in the F95 nor the F2K drafts I'm having.  This is
>>invalid by the constraints in 5.5.1 in the F95 draft.  Is there any other
>>constraint you were aiming at?
> 
>  
> No, off-by-one, refering to 'note 11.8' in 11.3.2 which mentions the same
> constraint.

Thanks, I had only checked note 11.7 :-)



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-05-19 19:21 
---
Subject: Re:  libstdc++ headers should have pop/push
 of the visibility around the declarations

bernie at develer dot com wrote:

> It's not a regresion, but it causes KDE to miscompile
> with GCC 4.0.0.  Could we apply it for 4.0 anyway?

No; we confine ourselves to regressions.  If it wasn't a regression, 
there must be some workaround that KDE is using for previous releases 
that it can continue to use here.



-- 


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

[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 19:16 
---
It has never worked on HP-UX at least, see here, e.g.:
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00134.html

I have no idea why it would only fail at -O0 though, the .original dump on
i586-linux looks fine, and there's nothing strongly system specific in it.

Also, it's not a 32bit vs. 64bit issue, as can be seen from these testresults:
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01228.html -- here the test
fails at -O0 for 32bits, but passes for 64bit.

-- 


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

[Bug c/21666] Optimization level -O2 breaks float (double) conversion

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 
19:15 ---
You are violating C aliasing rules:
((long *) &s)[0] = __extension__ ({ register u_long __X = (nt.li[1]); __asm
("xchgb %h1, %b1\n\trorl $16, %1\n\txchgb %h1, %b1" : "=q" (__X) : "0" (__X));
__X; });

s is a double but you are accessing it as a long.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/21653] [4.1 Regression] gcc.dg/vect failures

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-19 19:06 
---
The ICE shows up on powerpc-linux with this patch from rakdver:

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

-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug c/21666] New: Optimization level -O2 breaks float (double) conversion

[jbeitaharon at intrusic dot com]

the exact version of GCC:
gcc34 (GCC) 3.4.4 20050114 (prerelease) [FreeBSD]
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(also tested with: gcc33 (GCC) 3.3.1 [FreeBSD]
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.)


the system type:
FreeBSD jb.intrusic.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Tue Jan 18 08:31:50
EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JB  i386


the options given when GCC was configured/built:
cd /usr/ports/lang/gcc34; make; make install


the complete command line that triggers the bug:
gcc34 --verbose -O2 -pthread -D_THREAD_SAFE -DPCAP_DONT_INCLUDE_PCAP_BPF_H -fpic
-I/usr/local/include/postgresql/server/ -lz -o pg_timestamptz2 pg_timestamptz2.c

(also did it with the gcc33, and otherwise the same line)


the compiler output (error messages, warnings, etc.):
Reading specs from /usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/specs
Configured with: ./..//gcc-3.4-20050114/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=34
--with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/c++/
--disable-shared --prefix=/usr/local i386-portbld-freebsd4.9
Thread model: posix
gcc version 3.4.4 20050114 (prerelease) [FreeBSD]
 /usr/local/libexec/gcc/i386-portbld-freebsd4.9/3.4.4/cc1 -quiet -v
-I/usr/local/include/postgresql/server/ -D__PIC__ -D__pic__ -D_THREAD_SAFE
-DPCAP_DONT_INCLUDE_PCAP_BPF_H pg_timestamptz2.c -quiet -dumpbase
pg_timestamptz2.c -auxbase pg_timestamptz2 -O2 -version -fpic -o
/var/tmp//ccpuIIQW.s
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/../../../../i386-portbld-freebsd4.9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/postgresql/server/
 /usr/local/include
 /usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include
 /usr/include
End of search list.
GNU C version 3.4.4 20050114 (prerelease) [FreeBSD] (i386-portbld-freebsd4.9)
compiled by GNU C version 3.4.4 20050114 (prerelease) [FreeBSD].
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31958
 as -o /var/tmp//cckWDfD6.o /var/tmp//ccpuIIQW.s
 /usr/local/libexec/gcc/i386-portbld-freebsd4.9/3.4.4/collect2 -V
-dynamic-linker /usr/libexec/ld-elf.so.1 -o pg_timestamptz2 /usr/lib/crt1.o
/usr/lib/crti.o /usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/crtbegin.o
-L/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4
-L/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/../../.. -lz
/var/tmp//cckWDfD6.o -lgcc -lc_r -lgcc
/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/crtend.o /usr/lib/crtn.o
GNU ld version 2.12.1 [FreeBSD] 2002-07-20
  Supported emulations:
   elf_i386



the preprocessed file (*.i*) that triggers the bug, generated by adding
--save-temps to the complete compilation command:
It is (1921 lines according to wc -l):

# 1 "pg_timestamptz2.c"
# 1 ""
# 1 ""
# 1 "pg_timestamptz2.c"
# 13 "pg_timestamptz2.c"
# 1 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/stdio.h" 1 3 4
# 52 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/stdio.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 53 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/stdio.h" 2 3 4
# 1 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/machine/ansi.h" 1 
3 4
# 127 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/machine/ansi.h" 
3 4
typedef int __attribute__((__mode__(__DI__))) __int64_t;
typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t;
# 139 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/machine/ansi.h" 
3 4
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short __int16_t;
typedef unsigned short __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;

typedef int __intptr_t;
typedef unsigned int __uintptr_t;





typedef union {
 char __mbstate8[128];
 __int64_t _mbstateL;
} __mbstate_t;
# 54 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/stdio.h" 2 3 4


typedef unsigned int size_t;







typedef __int64_t fpos_t;
# 75 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/stdio.h" 3 4
struct __sbuf {
 unsigned char *_base;
 int _size;
};
# 106 "/usr/local/lib/gcc/i386-portbld-freebsd4.9/3.4.4/include/stdio.h" 3 4
typedef struct __sFILE {
 unsigned char *_p;
 int _r;
 int _w;
 short _flags;
 short _file;
 struct __sbuf _bf;
 int _lbfsize;


 void *_cookie;
 int (*_close) (void *);
 int (*_read) (void *, char *, int);
 fpos_t (*_seek) (void *, fpos_t, int);
 int (*_write) (void *, const char *, int);


 struct __sbuf _ub;
 unsigned char *_up;
 int _ur;


 unsigned char _ubuf[3];
 unsigned char _nbuf[1];


 struct __sbuf _lb;


 int _blksize;
 fpos_t _offset;
} 

[Bug java/17255] [meta-bug] Fixes should be back-ported to 3.4 branch

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-19 
18:00 ---
Bryce, are you planning to put any more fixes into 3.4.x?
I know I'm not.  I think we should just close this PR.


-- 


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

[Bug fortran/20904] optional argument in specification expression

[jv244 at cam dot ac dot uk]

--- Additional Comments From jv244 at cam dot ac dot uk  2005-05-19 17:58 
---
(In reply to comment #1)
> I get this error:
> [EMAIL PROTECTED] tests]$ ~/src/gcc-new/build/gcc/f951 pr20904.f90
>  In file pr20904.f90:3
> 
>character(len=arg) :: s
> 1
> Error: Dummy argument 'arg' at (1) cannot be OPTIONAL
> 
> 
Which is fine indeed. I might have been using a pre 4.0.0 version of gfortran..



-- 


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

[Bug fortran/20900] use-associated variable may not be equivalenced

[jv244 at cam dot ac dot uk]

--- Additional Comments From jv244 at cam dot ac dot uk  2005-05-19 17:54 
---
(In reply to comment #1)
> There's no 11.7 neither in the F95 nor the F2K drafts I'm having.  This is
> invalid by the constraints in 5.5.1 in the F95 draft.  Is there any other
> constraint you were aiming at?
 
No, off-by-one, refering to 'note 11.8' in 11.3.2 which mentions the same
constraint.

-- 


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

[Bug fortran/20923] Compile time is high for the following code

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 17:41 
---
Confirmed.  This is because the array constructor is expanded at compile-time. 
If the constructor were used in an initialization we would abort, IIRC.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-19 17:41:54
   date||


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

[Bug fortran/20904] optional argument in specification expression

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 17:38 
---
I get this error:
[EMAIL PROTECTED] tests]$ ~/src/gcc-new/build/gcc/f951 pr20904.f90
 In file pr20904.f90:3

   character(len=arg) :: s
1
Error: Dummy argument 'arg' at (1) cannot be OPTIONAL



-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
   Keywords||accepts-invalid
 Resolution||WORKSFORME
Summary|error needed|optional argument in
   ||specification expression


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

[Bug fortran/20901] different intrinsic types in equivalence not detected

[tobi at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||20405
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2005-05-19 17:35:56
   date||
Summary|error needed|different intrinsic types in
   ||equivalence not detected


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

[Bug fortran/20900] use-associated variable may not be equivalenced

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 17:34 
---
There's no 11.7 neither in the F95 nor the F2K drafts I'm having.  This is
invalid by the constraints in 5.5.1 in the F95 draft.  Is there any other
constraint you were aiming at?

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
OtherBugsDependingO||20405
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2005-05-19 17:34:35
   date||
Summary|error needed|use-associated variable may
   ||not be equivalenced


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

[Bug fortran/20899] pure function may not modify common variable through equivalence

[tobi at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||20405
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2005-05-19 17:28:57
   date||
Summary|error needed|pure function may not modify
   ||common variable through
   ||equivalence


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

[Bug fortran/20897] derived type name shall not be same as intrinsic type name

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-19 17:27 
---
second constraint in 4.4.1

-- 
   What|Removed |Added

   Keywords||accepts-invalid
Summary|error needed|derived type name shall not
   ||be same as intrinsic type
   ||name


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

[Bug target/15340] [3.3/3.4 Regression] GCC internal error in preprocessed C code

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug pch/14400] [pch] Cannot compile qt-x11-free-3.3.0

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug target/17279] [3.4 Regression] internal compiler error with 128 bit integers

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c/21420] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug tree-optimization/13000] [3.4 Regression] [unit-at-a-time] Using -O2 cannot detect missing return statement in a function

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug preprocessor/20077] [3.3/3.4/4.0/4.1 Regression] GCC accepts macro definitions that fail a constraint

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug target/15231] [3.4 only] constant pool entries referring to nonexistent labels

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/17655] [3.3/3.4 regression] ICE with using a C99 initializer in an if-condition

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug rtl-optimization/14944] [3.4 only] ICE when gcc reads *.gcda file of different version

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug other/15082] [3.4/4.0/4.1 regression] Minor compilation problem for cross to Solaris 8

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/18698] [3.4/4.0/4.1 regression] Error message using "using" for code not using "using" ;-)

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/16042] [3.3/3.4 regression] ICE with array assignment

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19253] [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/20209] [3.3/3.4/4.0/4.1 Regression] Missing warnings for "aggregate has a partly bracketed initializer"

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug preprocessor/19475] [3.3/3.4 Regression] missing whitespace after macro name in C90 or C++

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug libf2c/17725] [3.4 only] g77 libs installed in wrong directory

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/20427] [3.4 Regression] 'new int [2] ()' not default initialized

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19762] [3.4 regression] ICE in invalid explicit instantiation of a destructor

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug libobjc/11572] [3.4 regression]: GNU libobjc no longer compiled on Darwin

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug rtl-optimization/21464] [3.4 Regression] wassembler code is not generated for uint64_t comparison with -O

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug libstdc++/13583] [3.3/3.4/4.0/4.1 Regression] __use_cache not threadsafe

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19809] [3.4/4.0/4.1 Regression] Multiple definitions of friend functions in template classes

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19884] [3.3/3.4 regression] ICE on explicit instantiation of a non-template constructor

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug bootstrap/18532] [3.4 Regression] libgcc.mk isn't parallel build safe for multilib

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug middle-end/19183] [3.4 Regression] ICE with -fPIC

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug rtl-optimization/17810] [3.4 Regression] internal compiler error: in verify_local_live_at_start for arm-rtems, arm-linux

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug debug/20253] [3.4 regression]: Macro debug info broken due to lexer change

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug rtl-optimization/16613] [3.4/4.0 Regression] compile time regression, when adding cerr usage

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19764] [3.3/3.4 regression] ICE on explicit instantiation of a non-template destructor

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19441] [3.4 regression] Bad error message with invalid destructor declaration

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug rtl-optimization/17860] [3.4 only] Wrong generated code for loop with varying bound

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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

[Bug c++/19397] [3.4 regression] ICE with invalid typedef

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |3.4.5


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