[Bug rtl-optimization/20249] [4.0/4.1 Regression] ICE with -fprofile-arcs on ppc

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
08:05 ---
Subject: Bug 20249

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 08:05:21

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: 20050325-1.c 

Log message:
PR rtl-optimization/20249
* gcc.dg/20050325-1.c: New test.

Patches:
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.78&r2=1.5084.2.79
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050325-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.2.2.1



-- 


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

[Bug ada/15102] Building shared libgnat may fail linking non-PIC object files

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
08:49 ---
Closing, fixed on mainline as far as I can see.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug ada/19959] [4.0/4.1 Regression] Can't compile gnattools for the cross targets

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
08:56 ---
Confirmed, due to incorrect dependency in gnattools/Makefile.in

Fixing...

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 08:56:36
   date||


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

[Bug ada/19959] [4.0/4.1 Regression] Can't compile gnattools for the cross targets

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
08:57 ---
Subject: Bug 19959

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 08:56:57

Modified files:
gnattools  : Makefile.in 

Log message:
PR ada/19959
* Makefile.in (gnattools-cross): Remove incorrect dependency on gnatlib

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gnattools/Makefile.in.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug ada/19959] [4.0/4.1 Regression] Can't compile gnattools for the cross targets

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
08:59 ---
Should be fixed now.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug ada/14997] ncurses build fails with Ada

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
09:12 ---
Here is a further simplification of the test case:

procedure PQ is

   subtype C_ULongis Interfaces.C.unsigned_long;
   typeC_Chtype   is new C_ULong;

   type Character_Attribute_Set is array (0 .. 47) of Boolean;
   pragma Pack (Character_Attribute_Set);
   
   type Attributed_Character is record
  Attr  : Character_Attribute_Set;
  Color : Character;
  Ch: Character;
   end record;
   pragma Convention (C, Attributed_Character);
   --  This is the counterpart for the chtype in C.
   
   for Attributed_Character use record
  Attr  at 0 range  0 .. 47;
  Color at 0 range 48 .. 55;
  Chat 0 range 56 .. 63;
   end record;
   for Attributed_Character'Size use 64;
   
   function Chtype_To_AttrChar is new
 Ada.Unchecked_Conversion (C_Chtype, Attributed_Character);
   
   X : constant C_Chtype := 0;
   Y : Character_Attribute_Set;
begin
   Y := Chtype_To_AttrChar (X).Attr;
end PQ;

The expected output of the compilation is:
gcc -c pq.adb
pq.adb:27:04: warning: types for unchecked conversion have different sizes

I assume the incorrect code in the ncurses Ada binding has been fixed in
the mean time. Anyway, GNAT should not ICE here.

Arno

-- 


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

[Bug ada/18860] ACATS ICE cd30001 at -O0: in expand_expr_addr_expr_1, at expr.c:6229

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
09:32 ---
Is the bug still present on mainline ?

Arno

-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-03-30 09:43 ---
It does work for me too.
Thank you for quick fix.

-- 


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

[Bug ada/18860] ACATS ICE cd30001 at -O0: in expand_expr_addr_expr_1, at expr.c:6229

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-03-30 09:56 
---
Works on x86 at -O0 as of 4.1.0 20050329 (experimental)

-- 


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

[Bug c/20689] New: strict aliasing with temporary variable never gives warnings

[varun0005 at gmail dot com]

int i;
void *p=(void *)&i;
gives strict-aliasing warning
 but
int i,*o;
o=&i;
void *p= o;
doesn't give any warning

-- 
   Summary: strict aliasing with temporary variable never gives
warnings
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: varun0005 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:00 ---
I confirm the analysis in comment #2
Nathanael, could you please have a look and fix this regression ?

Also, having the TOOLS_TARGET_PAIRS being now set in configure.ac is
more painful to maintain than having the list in Makefile.in, what about
reverting this change ? It would make life simpler when adding support
for a new target (no need to worry about rerunning configure, configure
version, configure syntax errors, etc...)

Thanks in advance,

Arno

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 10:00:18
   date||


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

[Bug ada/18860] ACATS ICE cd30001 at -O0: in expand_expr_addr_expr_1, at expr.c:6229

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:02 ---
OK, so closing then.

Arno

-- 
   What|Removed |Added

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


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

[Bug ada/19380] ACATS c3a0004 SEGV at runtime on s390-linux, probably access to subprogram problem

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:04 ---
Is this still failing on mainline ?

-- 


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

[Bug ada/19381] ACATS c954a03 raises storage error at runtime on s390-linux

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:06 ---
Suspending, pending user feedback.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-30 10:06 
---
I don't understand what you mean. Please provide a *complete* test case,
with the command line you use and the output you get, and an explanation
of why you want a warning.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug ada/19383] ACATS c954020 (1,2,3,4,6) do not terminate on ppc-linux, s390-linux

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:12 ---
As far as I can see, this is likely a glibc bug (in unwinding), now fixed, so
closing this PR as "invalid".

Arno

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug ada/19456] [4.0/4.1 regression] ada bootstrap failure on alpha-linux

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:16 ---
Original issue fixed, as well as the issue of building xnmake on 64
bit platforms.

Closing this PR.

Please open a new one with additional info if the mainline has some
new issue, thanks.

Arno

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug ada/20530] gnatlink does not respect -mno-cygwin

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-30 
10:27 ---
Right, gnatmake has never supported -mno-cygwin. Instead, I'd suggest
configuring gcc for mingw to start with.

According to
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Option-Index.html#Option-Index

-mno-cygwin is not a FSF option, so closing this PR.

Arno

-- 
   What|Removed |Added

   Severity|minor   |enhancement
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-30 
10:53 ---
Hum... type-punning simply doesn't work in this case with the C++ compiler, but
does work with the C compiler.  The problem is that:

union u {
x_uint64_t first;
x_uint32_t second;
};
union u conv;
conv.first = arg1;
result = conv.second;

is translated into:

  *(&conv.first) = *(&arg1);
  *(&result) = *(&conv.second);

and type-punning cannot work in this case (that's the counter-example provided
in the manual).  I guess the problem comes the fields being of aggregate types.

Mark, is that fixable or should we document the limitation?


-- 
   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|mark at codesourcery dot com
   |org |


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

[Bug target/16871] missing vector support

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-30 
11:21 ---
Is anyone going to work on these intrinsics?  Is there a list somewhere
of what intrinsics we are talking about here?


-- 


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

[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-30 
11:38 ---
Waiting for a test case...

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/20584] [4.0/4.1 Regression] inline function used but never defined

[nerijus at users dot sourceforge dot net]

--- Additional Comments From nerijus at users dot sourceforge dot net  
2005-03-30 11:59 ---
It seems I get these warnings only when precompiled headers are not used.

-- 


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[varun0005 at gmail dot com]

--- Additional Comments From varun0005 at gmail dot com  2005-03-30 12:02 
---
I mean that since in case where you are doing "void *p=(void *)&i" then
according to strict-aliasing rules we get " warning: dereferencing type-punned
pointer will break strict-aliasing rules" , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space(in out case void pointer pointing to int address
space) then it is violating  strict aliasing rule. So in second case also void
pointer is pointing to the int address space then why strict aliasing rules are
not violated. If ther is some error in my understanding of strict aliasing then
please inform .

-- 


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-30 12:23 
---
(In reply to comment #2)
> I mean that since in case where you are doing "void *p=(void *)&i" then
> according to strict-aliasing rules we get " warning: dereferencing type-punned
> pointer will break strict-aliasing rules" 

No, you don't. Please provide a *complete* test case, with the command line
you use and the output you get.



-- 


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

[Bug c++/19203] [3.4/4.0/4.1 Regression] Partial ordering failure between function reference and generic const reference

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2005-03-30 
13:10 ---
We don't implement DR214 but edg does. 

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214

I shall see how tricky it is to implement ...

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
13:14 ---
Subject: Bug 20177

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 13:13:40

Modified files:
gcc: ChangeLog ddg.c modulo-sched.c passes.c 
Added files:
gcc/testsuite/gcc.dg: 20050321-1.c 20050330-1.c 

Log message:
Fix PR middle-end/20177 and two new test cases.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.95&r2=2.7592.2.96
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ddg.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.11&r2=1.11.14.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/modulo-sched.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.72.2.1&r2=2.72.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050321-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050330-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/20690] New: Bug in std::vector

[michael at xter dot net]

There is no allocator rebinding for some STL containers i.e. std::vector, so the
following code dose not compiled:

#include 
#include 

using namespace std;

typedef std::vector > Vec;

Vec v;

-- 
   Summary: Bug in std::vector
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at xter dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.

[canqun at nudt dot edu dot cn]

--- Additional Comments From canqun at nudt dot edu dot cn  2005-03-30 
14:42 ---
(In reply to comment #7)
> Waiting for a test case...

Part 1
! Test sase for address giv (general induction variable) optimization.
subroutine dot_product (sum, a, b, n)
   real*8 a(n), b(n), sum
   sum = 0
   do i = 1, n
 sum = sum + a (i) * b(i)
   end do
end

Part 2
// IA-64 Assembly code generated by GCC without address giv splitting
mov ar.lc = r14
.L4:
// Loop is unrolled, but the address givs are not splitted.
// Register r17, r19 is used to calculate all the addresses
// of the array elements.
.mmb
ldfd f7 = [r17]
ldfd f6 = [r19]
nop 0
.mmi
add r17 = r15, r33
add r19 = r15, r34
shladd r15 = r18, 3, r0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f9
.mmi
ldfd f7 = [r17]
ldfd f6 = [r19]
add r17 = r15, r33
.mfi
 nop 0
shladd r15 = r16, 3, r0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f8
.mmi
ldfd f7 = [r17]
ldfd f6 = [r19]
add r17 = r15, r33
.mmb
nop 0
add r19 = r15, r34
nop 0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f8
.mmb
ldfd f7 = [r17]
ldfd f6 = [r19]
nop 0
;;
.mmf
nop 0
nop 0
fma.d f8 = f7, f6, f8
;;
.mfb
nop 0
mov f9 = f8
br.cloop.sptk.few .L4
...
.endp dot_product__#
.ident  "GCC: (GNU) 4.1.0 20050302 (experimental)"

Part 3
// IA-64 assembly code generated by GCC with address giv splitting
mov ar.lc = r16
.L28:
[.L3:]
[.L2:]
...
// The loop is unrolled, and the address givs are splitted.
// Register r14, r8, r3, r35, r33, r31,r28, r29 is used to
// caculate the address of each array element respectively.
.mmi
ldfd f38 = [r14]
ldfd f39 = [r8]
add r31 = r34, r23
.mmi
ldfd f35 = [r3]
ldfd f37 = [r35]
add r33 = r34, r24
;;
.mmb
ldfd f33 = [r33]
ldfd f34 = [r31]
nop 0
.mmi
add r28 = r30, r23
add r29 = r30, r24
adds r22 = 4, r22
;;
.mmf
ldfd f32 = [r29]
ldfd f15 = [r28]
fma.d f36 = f38, f39, f14
;;
.mmf
nop 0
nop 0
fma.d f13 = f35, f37, f36
;;
.mmf
nop 0
nop 0
fma.d f12 = f33, f34, f13
;;
.mfb
nop 0
fma.d f14 = f32, f15, f12
br.cloop.sptk.few .L28
;;
.L9:
.mfb
stfd [r32] = f14
nop 0
nop 0
...
.endp dot_product__#
.ident  "GCC: (GNU) 3.5-tree-ssa 20031221 (CCRG)"

-- 


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

[Bug c++/20687] namespace bug

[jozef at syncad dot com]

--- Additional Comments From jozef at syncad dot com  2005-03-30 14:56 
---
Subject: Re:  namespace bug

Hi,

This is not about the same :
7.3.4.5
d1++; // shows that there is a conflict  between a symbol in  your
   // namespace and a symbol imported using using namespace
f(1); // shows that there is a conflict between two symbols;
   // both imported from two namespaces; one directly,
   // the second transitively

None of the errors indicated show that there is a conflict
between a symbol imported from a namespace and a symbol
from a higher level namespace.

But the example in the first paragraph clearly states that
the imported names hide names from the higher levels:
7.3.4.1
i = 5; // OK, C::i visible in B and hides A::i

7.3.4.5 does not conflict with 7.3.4.1. It still looks
  to me reasonable that the names imported using namespace have higher
  precedence than names inherited from a higher level namespace
  (this would be similar to the fact that the names defined
  in a namespace have higher precedence to the names inherited
  from a higher level namespaces).

One more argument is that this feature is required to compile correctly STLport.

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
> 19:51 ---
> The reduced testcase:
> namespace dd {
> struct t1 {};
> }
> namespace ff {
>   using namespace dd;
> }
> struct t1 { };
> namespace ff
> {
>  typedef t1 t2;
> }
> 
> 
> But the use of t1 is ambiguous really as "using namespace" is not as strong 
> as defining the t1 in the 
> namespace ff or doing a "using dd::t1" in the namespace ff.
> 
Can you provide some reference to the standard for this claim, please?

Regards,
Jozef


-- 


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

[Bug c++/20690] Bug in std::vector

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-30 15:09 
---
Irrespective of the fact that the code compiles or doesn't, I believe it's
*invalid*, because, according to 23.1/8, "All other constructors for these
container types take an Allocator& argument, an allocator whose value type is 
the
same as the container's value type", where Allocator is the type of the second
template parameter of the class, and your snippet violates this requirement; in
other terms, the standard does *not* mandate that the containers do rebinding.
 

-- 


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

[Bug c++/20687] namespace bug

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-30 15:15 
---
> One more argument is that this feature is required to compile correctly 
> STLport.

*Assuming* this is true, it's a serious problem for STLPort ;) because the 
other 
widespread C++ front-end, used by many commercial compilers, also rejects your
code...

-- 


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

[Bug libstdc++/20690] Bug in std::vector

[pcarlini at suse dot de]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|c++ |libstdc++


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
15:39 ---
Fixed in 4.0.0.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug c/20689] strict aliasing with temporary variable never gives warnings

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
15:45 ---
Also this is not done because void* cannot be dereferenced.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/20691] New: accept-invalid template template argument

[sstrasser at systemhaus-gruppe dot de]

>"Ioannis Vranos" <[EMAIL PROTECTED]> wrote...
>
>> #include 
>>
>>
>> template< template class ContainerTemplate, class ValueType>
>> inline void test(const ValueType &val)
>> {
>> ContainerTemplate container(val);
>> }
>>
>>
>>
>> int main()
>> {
>> using namespace std;
>>
>> test(10);
>> }
>
>
>No, this is not valid for a simple reason that std::vector is a template
>that has more than one argument.  Your 'ContainerTemplate' template
>template argument has only one argument itself.
>
>

-- 
   Summary: accept-invalid template template argument
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20691] accept-invalid template template argument

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
16:00 ---
This is PR 9737 and C++ DR report 150 (which was closed as an extension which 
means that it might 
become part of the standard in the future).

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
16:00 ---
*** Bug 20691 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||sstrasser at systemhaus-
   ||gruppe dot de


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 16:21 
---
Are you sure the bug is fixed?  The testcase is failing for me with today's
mainline compiler on i686-pc-linux-gnu, ia64-hp-hpux11.23 and
hppa64-hp-hpux11.{11,23}.

Failure on i686-pc-linux-gnu is that quoted in the bug report (at -O2; not at
-O0 or -O1).  Same failure on ia64-hpux.  On hppa64-hpux get instead, at -O1 and
above,

/home/gcc/nightlies/gcc-mainline-2005-03-30/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:
In function 'evas_common_convert_yuv_420p_601_rgba':
/home/gcc/nightlies/gcc-mainline-2005-03-30/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:12:
error: 'asm' operand requires impossible reload

gcc-testresults shows failures on other platforms, including on 4.0 branch.


-- 
   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org, jsm28 at gcc dot gnu
   ||dot org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/20692] New: configuring libgfortan infinite loop

[pfelecan at acm dot org]

- bootstraping gcc-4.0-20050326
- system type: SUN LX50: Sol8 x86 server 2 x 1404MHz
- head and tail of the objdir/i386-pc-solaris2.8/libgfortran/config.log:
[...]
It was created by GNU Fortran Runtime Library configure 0.2, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $
/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/sources/gcc-4.0-20050326/libgfortran/configure
--cache-file=./config.cache --host=i386-pc-solaris2.8 --build=i386-pc-solaris2.8
--prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --without-gnu-as
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--enable-threads=posix --enable-shared --enable-multilib --enable-nls
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib
--with-gcc-version-trigger=/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/sources/gcc-4.0-20050326/gcc/version.c
--enable-languages=c,ada,c++,f95,java,objc --program-transform-name=s,y,y,
--srcdir=../../../sources/gcc-4.0-20050326/libgfortran
--with-target-subdir=i386-pc-solaris2.8

## - ##
## Platform. ##
## - ##

hostname = daedal
uname -m = i86pc
uname -r = 5.8
uname -s = SunOS
uname -v = Generic_117351-16

/usr/bin/uname -p = i386
/bin/uname -X = System = SunOS
Node = daedal
Release = 5.8
KernelID = Generic_117351-16
Machine = i86pc
BusType = 
Serial = 
Users = 
OEM# = 0
Origin# = 1
NumCPU = 2

/bin/arch  = i86pc
/usr/bin/arch -k   = i86pc
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

[...]

configure:4487: checking whether we are using the GNU Fortran compiler
configure:4501:
/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/objdir/gcc/gfortran
-B/export/nfs/workarea/pfelecan/CSW/ports/gcc4core-4.0.0REV2005.03.26-SunOS5.8-i386-CSW.pkg/objdir/gcc/
-B/opt/csw/gcc4/i386-pc-solaris2.8/bin/ -B/opt/csw/gcc4/i386-pc-solaris2.8/lib/
-isystem /opt/csw/gcc4/i386-pc-solaris2.8/include -isystem
/opt/csw/gcc4/i386-pc-solaris2.8/sys-include -c   conftest.F >&5

This never ends.

-- 
   Summary: configuring libgfortan infinite loop
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pfelecan at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.8
  GCC host triplet: i386-pc-solaris2.8
GCC target triplet: i386-pc-solaris2.8


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 16:54 
---
Forgot the content of the conftest.F:

  program main
#ifndef __GNUC__
   choke me
#endif

  end


-- 


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 17:37 
---
Created an attachment (id=8494)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8494&action=view)
back trace tentative

I tried to isolate the bug and run in gdb. The issue appears as reported. After
terminating the process I executed a back-trace. Hope that it is helpful.

-- 


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

[Bug libgcj/20693] New: javax-imageio.lo failed to build

[hjl at lucon dot org]

As of Wed Mar 30 00:24:21 UTC 2005, I got

/bin/sh ./libtool --mode=compile
/export/build/gnu/gcc/build-i686-linux/./gcc/gcj
-B/export/build/gnu/gcc/build-i686-linux/./gcc/
-B/usr/gcc-4.1/i686-pc-linux-gnu/bin/ -B/usr/gcc-4.1/i686-pc-linux-gnu/lib/
-isystem /usr/gcc-4.1/i686-pc-linux-gnu/include -isystem
/usr/gcc-4.1/i686-pc-linux-gnu/sys-include -ffloat-store -fno-omit-frame-pointer
-fclasspath=
-fbootclasspath=/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava':'/net/gnu/export/gnu/src/gcc/gcc/libjava':'/net/gnu/export/gnu/src/gcc/gcc/libjava/external/w3c_dom':'/net/gnu/export/gnu/src/gcc/gcc/libjava/external/sax
--encoding=UTF-8 -Wno-deprecated -g -O2 -findirect-dispatch -c -o 
javax-imageio.lo \
`find javax/imageio -name '*.class' -print`
/export/build/gnu/gcc/build-i686-linux/./gcc/gcj
-B/export/build/gnu/gcc/build-i686-linux/./gcc/
-B/usr/gcc-4.1/i686-pc-linux-gnu/bin/ -B/usr/gcc-4.1/i686-pc-linux-gnu/lib/
-isystem /usr/gcc-4.1/i686-pc-linux-gnu/include -isystem
/usr/gcc-4.1/i686-pc-linux-gnu/sys-include -ffloat-store -fno-omit-frame-pointer
-fclasspath=
-fbootclasspath=/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava:/net/gnu/export/gnu/src/gcc/gcc/libjava:/net/gnu/export/gnu/src/gcc/gcc/libjava/external/w3c_dom:/net/gnu/export/gnu/src/gcc/gcc/libjava/external/sax
--encoding=UTF-8 -Wno-deprecated -g -O2 -findirect-dispatch -c
javax/imageio/metadata/IIOMetadataFormat.class
javax/imageio/metadata/IIOMetadataController.class
javax/imageio/metadata/IIONodeList.class
javax/imageio/metadata/IIOInvalidTreeException.class
javax/imageio/metadata/IIOMetadataFormatImpl.class
javax/imageio/metadata/IIOAttr.class
javax/imageio/metadata/IIONamedNodeMap.class
javax/imageio/metadata/IIOMetadataNode.class
javax/imageio/metadata/IIOMetadata.class javax/imageio/IIOImage.class
javax/imageio/ImageWriter.class javax/imageio/stream/IIOByteBuffer.class
javax/imageio/stream/ImageOutputStream.class
javax/imageio/stream/FileImageInputStream.class
javax/imageio/stream/MemoryCacheImageInputStream.class
javax/imageio/stream/FileCacheImageOutputStream.class
javax/imageio/stream/ImageInputStream.class
javax/imageio/stream/MemoryCacheImageOutputStream.class
javax/imageio/stream/ImageInputStreamImpl.class
javax/imageio/stream/ImageOutputStreamImpl.class
javax/imageio/stream/FileImageOutputStream.class
javax/imageio/stream/FileCacheImageInputStream.class
javax/imageio/ImageReadParam.class javax/imageio/ImageTranscoder.class
javax/imageio/ImageWriteParam.class javax/imageio/ImageReader.class
javax/imageio/IIOParamController.class
javax/imageio/ImageIO\$WriterFormatFilter.class
javax/imageio/ImageIO\$ImageWriterIterator.class
javax/imageio/ImageIO\$ReaderFormatFilter.class
javax/imageio/ImageIO\$ReaderSuffixFilter.class javax/imageio/ImageIO.class
javax/imageio/ImageTypeSpecifier.class
javax/imageio/ImageIO\$ReaderMIMETypeFilter.class
javax/imageio/ImageIO\$ImageReaderIterator.class javax/imageio/IIOParam.class
javax/imageio/ImageIO\$WriterMIMETypeFilter.class
javax/imageio/ImageIO\$WriterSuffixFilter.class
javax/imageio/event/IIOWriteWarningListener.class
javax/imageio/event/IIOReadUpdateListener.class
javax/imageio/event/IIOReadProgressListener.class
javax/imageio/event/IIOReadWarningListener.class
javax/imageio/event/IIOWriteProgressListener.class
javax/imageio/IIOException.class javax/imageio/spi/ImageReaderWriterSpi.class
javax/imageio/spi/ImageOutputStreamSpi.class
javax/imageio/spi/ImageInputStreamSpi.class
javax/imageio/spi/ServiceRegistry\$2.class
javax/imageio/spi/ServiceRegistry\$Filter.class
javax/imageio/spi/ImageTranscoderSpi.class javax/imageio/spi/IIORegistry.class
javax/imageio/spi/ImageWriterSpi.class
javax/imageio/spi/RegisterableService.class
javax/imageio/spi/ImageReaderSpi.class javax/imageio/spi/ServiceRegistry.class
javax/imageio/spi/IIOServiceProvider.class
javax/imageio/spi/ServiceRegistry$1.class -fPIC -o .libs/javax-imageio.o
javax/imageio/spi/IIOServiceProvider.java:0: fatal error: can't open
javax/imageio/spi/ServiceRegistry-B/export/build/gnu/gcc/build-i686-linux/./gcc/.class:
No such file or directory

It looks like libtool failed to add `\' before $ for
javax/imageio/spi/ServiceRegistry$1.class.

-- 
   Summary: javax-imageio.lo failed to build
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs 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=20693

[Bug libstdc++/20694] New: make install failure building abi_check with leftover libv3test

[janis at gcc dot gnu dot org]

Nightly mainline bootstraps for powerpc64-linux have been failing
intermittently since changes went in last week to allow running
libstc++ tests on installed tools.  For "make bootstrap", abi_check
is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float.
"make install" tries to build it again, but a 32-bit build of
abi_float tries to use the existing libv3test, and the link fails if
the type of the leftover library (e.g. 64-bit) doesn't match the type
of the new abi_check.  All of the abi_check builds appear to be done
in the same directory.

-- 
   Summary: make install failure building abi_check with leftover
libv3test
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:04 ---
#0  0xdfa2b0e0 in _waitid () from /usr/lib/libc.so.1
#1  0xdfa43aeb in _waitpid () from /usr/lib/libc.so.1
#2  0xdfa79957 in waitpid () from /usr/lib/libc.so.1
#3  0x08057a42 in execute () at ../../sources/gcc-4.0-20050326/gcc/gcc.c:2835


Can you try adding -v to see which program we are waiting on?
And then run that program with gdb?

-- 
   What|Removed |Added

   Keywords||build


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |critical
   Keywords||build
Summary|make install failure|[4.1 Regression] make
   |building abi_check with |install failure building
   |leftover libv3test  |abi_check with leftover
   ||libv3test
   Target Milestone|--- |4.1.0


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

[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:05 
---
Testing a fix.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-12-05 04:32:03 |2005-03-30 18:05:58
   date||


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

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:08 
---
Patch at  addresses
the issue for C and noncomputed gotos by disallowing such jumps; awaiting
any comments on the proposed statement expression semantics.  Does not address
the issue for C++ which needs similar changes, and the possibility of computed
gotos means that something like
 but adjusted as
described in that message is needed as well.


-- 


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

[Bug c/18715] [4.0/4.1 Regression] warning: "enumeration value not handled in switch" for '...' ranges

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:09 
---
Is there a more recent patch version than that referred to in comment #4,
taking account of Mark's comments on that patch version?


-- 


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

[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:10 
---
Testing a fix.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-03-19 13:13:11 |2005-03-30 18:10:15
   date||


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 18:22 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

janis at gcc dot gnu dot org wrote:
> Nightly mainline bootstraps for powerpc64-linux have been failing
> intermittently since changes went in last week to allow running
> libstc++ tests on installed tools.  For "make bootstrap", abi_check
> is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float.
> "make install" tries to build it again, but a 32-bit build of
> abi_float tries to use the existing libv3test, and the link fails if
> the type of the leftover library (e.g. 64-bit) doesn't match the type
> of the new abi_check.  All of the abi_check builds appear to be done
> in the same directory.

I will look into this today.

Is it considered desirable behavior to build abi_check at "make install" 
time?



-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[bkoz at redhat dot com]

--- Additional Comments From bkoz at redhat dot com  2005-03-30 18:31 
---
Subject: Re:  New: make install failure building
 abi_check with leftover libv3test


> Is it considered desirable behavior to build abi_check at "make install" 
> time?

No, this doesn't make any sense, as abi_check is not installed.

It was/is built at "make all" time. I believe you wanted to build this
as part of "make check" or "make check-abi" either of which is fine for
me.

-benjamin


-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 18:32 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

Benjamin Kosnik wrote:
>>Is it considered desirable behavior to build abi_check at "make install" 
>>time?
> 
> 
> No, this doesn't make any sense, as abi_check is not installed.
> 
> It was/is built at "make all" time. I believe you wanted to build this
> as part of "make check" or "make check-abi" either of which is fine for
> me.

OK, that makes sense.

(I didn't actually change this particularly thing; it was probably 
getting built at make install time all along.  But, my changes are 
causing the make install rebuild not to work.)

I'll see what I can do.



-- 


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

Important m$6h?3p

[tom]

This is a multi-part message in MIME format.
Norman Virus Control a supprimé le message original qui contenait le virus 
[EMAIL PROTECTED]  

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 18:48 
---
Created an attachment (id=8495)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8495&action=view)
verbose output of gfortran

This is the output of gfortran -v as requested. The binary on which we wait is
f951. I will run this in gdb and attach the output in another attachement.

-- 


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pfelecan at acm dot org]

--- Additional Comments From pfelecan at acm dot org  2005-03-30 18:49 
---
Created an attachment (id=8496)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8496&action=view)
gdb session, with backtrace, for f951

gdb session running the command f951 for which the wait is done in gfortran.

-- 


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:51 ---
I still can reproduce it also on x86.

-- 
   What|Removed |Added

 Status|REOPENED|ASSIGNED


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

[Bug bootstrap/20692] configuring libgfortan infinite loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:54 ---
Looks like not a gfortran bug but a gmp one:
#0  0xdfb7bdac in __gmpn_mul_basecase () from /opt/csw/lib/libgmp.so.3
#1  0xdfb97840 in ?? () from /opt/csw/lib/libgmp.so.3
#2  0x0006 in ?? ()
#3  0x0804759c in ?? ()
#4  0x080475c0 in ?? ()
#5  0x0005 in ?? ()
#6  0xa0cba75d in ?? ()
#7  0xdfb7870d in __gmpn_mul () from /opt/csw/lib/libgmp.so.3

Could you make sure that the installed version of gmp is the correct one and is 
working?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
18:57 ---
Why does this work for me and other people on i686-pc-linux-gnu?
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg02051.html

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug fortran/20460] Nasty extensions that should always warn

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-03-30 18:57 ---
Subject: Re: [PR tree-optimization/20460] add phi args to dests of
dce-redirected edges

On Wed, 2005-03-30 at 02:56 -0300, Alexandre Oliva wrote:
> When remove_dead_stmt() redirects a control stmt, the edge redirection
> reserves space for the phi arg for the new incoming edge in all phi
> nodes, but, instead of filling them in with information obtained from
> the edge redirection, we simply discard this information.  This leaves
> NULL in the phi args, which may cause crashes later on.
> 
> This patch fixes the problem by filling in the phi args using the
> PENDING_STMT list created during edge redirection.  This appears to be
> the intended use for this information, and it is used similarly in
> e.g. loop unrolling.
> 
> Bootstrapping mainline and 4.0 branch on amd64-linux-gnu, and mainline
> on i686-pc-linux-gnu.  Ok to install if bootstrap and regtesting pass?
> 
> The patch below is for the 4.0 branch, but it applies cleanly and
> correctly in mainline as well, since it's just a few lines off.


   /* Redirect the first edge out of BB to reach POST_DOM_BB.  */
   redirect_edge_and_branch (EDGE_SUCC (bb, 0), post_dom_bb);
-  PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
+  flush_pending_stmts (EDGE_SUCC (bb, 0));



I'm having trouble seeing how this can be correct.

AFAICT this assumes that EDGE_SUCC (bb, 0)->dest before the redirection
has similar PHI as post_dom_bb and that the PHIs appear in the same
order in both blocks.  I'm not sure you can make that assumption.


This code is triggered rarely, I would expect it to be even rarer still
for POST_DOM_BB to have PHI nodes.  You could probably just ignore dead
control statements where the post dominator has PHI nodes and I doubt
it would ever be noticed.

Jeff



-- 


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[aoliva at gcc dot gnu dot org]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-30 
19:00 ---
I'm now sure it wasn't fixed.  Somehow I forgot the problem didn't occur on
x86_64-linux-gnu, not even with -m32, even though it did on i686-pc-linux-gnu. 
I I had only one i686-only bug, and I knew it was a different one.  Sorry about
that, I'll try to come up with a reasonable fix.

-- 


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

[Bug target/20695] New: sh64-*-* port deos not handle 32 / 64 bit conversions properly

[amylaar at gcc dot gnu dot org]

The sh64-*-* port plays fast and loos with the distinction between 32 and 64 bit
values.  In particular, it pretends a truncation from 64 to 32 bit is a no-op,
while a sign extension is needed, and that the sh5-32media and sh-compact
subtargets can expose the indexed addressing mode directly to the compiler,
which is wrong, too, since this addressing mode uses 64 bit arithmetic and
traps on all existing hardware if the result is not a valid 64 bit address.
On the other hand, sign extensions are usually no-ops.
Moreover, the target address of a branch should not be hardwired to DImode,
but always be Pmode.

The merge I am working on addresses all these issues, but it depends on all
LABEL_REFS to have Pmode; VOIDmode LABEL_REFs cause reload failures.

-- 
   Summary: sh64-*-* port deos not handle 32 / 64 bit conversions
properly
   Product: gcc
   Version: 3.0.4
Status: UNCONFIRMED
  Keywords: wrong-code, missed-optimization
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sh64-*-*
 BugsThisDependsOn: 20413


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

[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||20695
  nThis||


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-30 
19:28 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs

On Mar 29, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> On Mar 28, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote:
>>> * combine.c (subst): Make sure we don't create invalid subregs.

>> Ok.

> As it turned out, the bug seems to have been fixed by some other
> patch, because I no longer get the error in mainline or in the 4.0
> branch.

Or perhaps it never actually failed on x86_64-linux-gnu, which is
where I was trying to trigger it again.  Not even with -m32.  A build
on i686-pc-linux-gnu was enough to trigger it.  Yay me! :-)

So, the patch posted in my previous e-mail still stands, but if you,
like me, find that it's working too hard to avoid such subregs, here's
an alternative patch that also fixes the problem, at least as long as
the X-constrained asm operand is not actually used in the asm output
pattern.

Index: gcc/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR middle-end/20491
* final.c (alter_subreg): Don't call subreg_regno for a non-REG.

Index: gcc/final.c
===
RCS file: /cvs/gcc/gcc/gcc/final.c,v
retrieving revision 1.344.12.1
diff -u -p -r1.344.12.1 final.c
--- gcc/final.c 22 Mar 2005 13:39:12 - 1.344.12.1
+++ gcc/final.c 30 Mar 2005 19:21:02 -
@@ -1,6 +1,7 @@
 /* Convert RTL to assembler code and output it, for GNU compiler.
Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997,
-   1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+   1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
+ Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -2638,7 +2639,7 @@ alter_subreg (rtx *xp)
 
   if (new != 0)
*xp = new;
-  else
+  else if (REG_P (y))
{
  /* Simplify_subreg can't handle some REG cases, but we have to.  */
  unsigned int regno = subreg_regno (x);

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}


-- 


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

[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:35 ---
Subject: Bug 20368

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 19:35:49

Modified files:
gcc: ChangeLog c-decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20368-1.c pr20368-2.c pr20368-3.c 

Log message:
PR c/20368
* c-decl.c (start_function): Check for old_decl being
error_mark_node.

testsuite:
* gcc.dg/pr20368-1.c, gcc.dg/pr20368-2.c, gcc.dg/pr20368-3.c: New
tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8035&r2=2.8036
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.641&r2=1.642
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5236&r2=1.5237
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:39 ---
Subject: Bug 20368

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 19:39:35

Modified files:
gcc: ChangeLog c-decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20368-1.c pr20368-2.c pr20368-3.c 

Log message:
PR c/20368
* c-decl.c (start_function): Check for old_decl being
error_mark_node.

testsuite:
* gcc.dg/pr20368-1.c, gcc.dg/pr20368-2.c, gcc.dg/pr20368-3.c: New
tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.96&r2=2.7592.2.97
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.2&r2=1.630.6.3
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.79&r2=1.5084.2.80
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20368-1.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/testsuite/gcc.dg/pr20368-2.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/testsuite/gcc.dg/pr20368-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[bkoz at redhat dot com]

--- Additional Comments From bkoz at redhat dot com  2005-03-30 19:48 
---
Subject: Re:  New: make install failure building
 abi_check with leftover libv3test


> (I didn't actually change this particularly thing; it was probably 
> getting built at make install time all along.  But, my changes are 
> causing the make install rebuild not to work.)

Roger wilco. I did not mean to imply anything else.

-benjamin


-- 


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

[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 19:54:01
   date||


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

[Bug c/772] Statement expressions issues

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:56 ---
Subject: Bug 772

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 19:56:40

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8036&r2=2.8037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.642&r2=1.643
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&r1=1.198&r2=1.199
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.428&r2=1.429
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.246&r2=1.247
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&r1=1.31&r2=1.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.267&r2=1.268
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5237&r2=1.5238
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:56 ---
Subject: Bug 17913

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 19:56:40

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8036&r2=2.8037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.642&r2=1.643
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&r1=1.198&r2=1.199
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.428&r2=1.429
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.246&r2=1.247
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&r1=1.31&r2=1.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.267&r2=1.268
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5237&r2=1.5238
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/772] Statement expressions issues

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:59 ---
Subject: Bug 772

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 19:59:21

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.97&r2=2.7592.2.98
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.3&r2=1.630.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193.4.1&r2=1.193.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419&r2=1.419.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.240.2.5&r2=1.240.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.29&r2=1.29.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.266&r2=1.266.6.1
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.80&r2=1.5084.2.81
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.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/testsuite/gcc.dg/stmt-expr-label-2.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/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
19:59 ---
Subject: Bug 17913

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-30 19:59:21

Modified files:
gcc: ChangeLog c-decl.c c-tree.h c-typeck.c 
gcc/doc: extend.texi 
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
  stmt-expr-label-3.c 
Removed files:
gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
PR c/772
PR c/17913
* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
c_label_context, label_context_stack): New.
* c-decl.c (define_label): Check for jumps into statement
expressions.  Add label to list of defined labels.
(start_function): Push context on label_context_stack.
(finish_function): Pop context from label_context_stack.
* c-typeck.c (label_context_stack): New.
(c_finish_goto_label): Check for jumps into statement
expressions.  Add label to list of jumped to labels.
(struct c_switch): Add blocked_stmt_expr.
(c_start_case): Initialize it.
(do_case): Check it.
(c_finish_case): Verify !blocked_stmt_expr.
(c_begin_stmt_expr):  Push context on label_context_stack.
Increment blocked_stmt_expr.  Mark labels jumped to from outside
as undefinable.
(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
defined in the statement expression and no longer jumpable to.
Mark labels jumped to from just outside the statement expression
as again definable.  Pop context from label_context_stack.
* doc/extend.texi (Statement Exprs): Update.

objc:
* objc-act.c (objc_start_function): Push context on
label_context_stack.

testsuite:
* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
gcc.dg/stmt-expr-label-3.c : New tests.
* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.97&r2=2.7592.2.98
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.3&r2=1.630.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193.4.1&r2=1.193.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419&r2=1.419.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.240.2.5&r2=1.240.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.29&r2=1.29.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.266&r2=1.266.6.1
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.80&r2=1.5084.2.81
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.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/testsuite/gcc.dg/stmt-expr-label-2.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/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-03-30 20:06 ---
It is a libtool bug, which depends on the order of the output from
"find -name '*.class" -print". On my Linux/i686:

[EMAIL PROTECTED] libjava]$ pwd
/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava
[EMAIL PROTECTED] libjava]$ find javax/imageio -name '*.class' -print
...
javax/imageio/spi/ServiceRegistry$1.class
[EMAIL PROTECTED] libjava]$

On my Linux/ia64:
[EMAIL PROTECTED] libjava]$ pwd
/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libjava
[EMAIL PROTECTED] libjava]$ find javax/imageio -name '*.class' -print
...
javax/imageio/ImageIO$ReaderFormatFilter.class
[EMAIL PROTECTED] libjava]$

On my Linux/x86_64:

[EMAIL PROTECTED] libjava]$ pwd
/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava
[EMAIL PROTECTED] libjava]$ find javax/imageio -name '*.class' -print
...
javax/imageio/ImageIO$ReaderFormatFilter.class
[EMAIL PROTECTED] libjava]$

For some reason, libtool failed to add a `/' before `$' for the last
one on the list.

-- 


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

[Bug target/20670] IA-64 exception mechanism erase $f29

[ochem at gnat dot com]

--- Additional Comments From ochem at gnat dot com  2005-03-30 20:13 ---
The test case is ok, I get an abort if I compile it with -O2 option on a 3.4 
compiler. 

-- 


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

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
20:21 ---
Subject: Bug 19225

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 20:21:39

Modified files:
gcc: ChangeLog calls.c 

Log message:
2005-03-30  Dale Johannesen  <[EMAIL PROTECTED]>

PR middle-end/19225
* calls.c (expand_call):  Flush pending deferrals before
throwing call.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8037&r2=2.8038
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&r1=1.384&r2=1.385



-- 


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

gcc rs6000 target without glibc

[lothar]

Hello,
Michael Meissner redirected me to this list, I contacted him because his 
emailaddress was in rs6000/linux.h. I don't know who currently maintains 
this file

I ran into trouble when trying to build a cross compiler for the RS6000 
(target=ppc-linux).

In gcc-3.4.0/gcc/config/rs6000/linux.h there is in line 100:
[--code--]
#include 
/* During the 2.5 kernel series the kernel ucontext was changed, but
the new layout is compatible with the old one, so we just define
and use the old one here for simplicity and compatibility.  */
struct kernel_old_ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
stack_t   uc_stack;
struct sigcontext_struct uc_mcontext;
sigset_t  uc_sigmask;
};
[--code--]
since there are several signal.h files (glibc, linux-headers) I tried to 
figure out wichone was needed, I tried to use asm/signal.h which, after 
a few changes to rs6000/linux.h is ok. It shouldn't be any signal.h from 
the glibc, because I configured with the option --without-headers. 
size_t wasn't defined (no glibc), so I added this on too. Maybe this 
should be defined somewhere else...

How I configured:
../gcc-3.4.0/configure --prefix=/home/cross/workspace/cross/out/ 
--target=ppc-linux --enable-languages=c  --disable-nls --disable-shared 
--disable-threads --without-headers --with-newlib

How my rs6000/linux.h looks now:
[--code--]
#ifdef IN_LIBGCC2
#include  /*defines size_t for asm/signal.h*/
#include 
#include  /*defines struct siginfo */
#ifndef sigcontext_struct
/* Kernel headers before 2.1.1 define a struct sigcontext_struct, but
*we need sigcontext.  */
# define sigcontext_struct sigcontext
#include 
#endif
#include 
/* During the 2.5 kernel series the kernel ucontext was changed, but
the new layout is compatible with the old one, so we just define
and use the old one here for simplicity and compatibility.  */
struct kernel_old_ucontext {
unsigned long uc_flags;
struct ucontext*  uc_link;
stack_t   uc_stack;
struct sigcontext_struct uc_mcontext;
sigset_t  uc_sigmask;
};
[--code--]
Maybe someone can take a look at it, I don't know too much about gcc.
Lothar

[Bug libgcj/20693] javax-imageio.lo failed to build

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-03-30 20:26 ---
A patch is posted at

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

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 20:26:24
   date||


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

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[dalej at gcc dot gnu dot org]

--- Additional Comments From dalej at gcc dot gnu dot org  2005-03-30 20:27 
---
Fixed (4.1 only)


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

Re: gcc rs6000 target without glibc

[Andrew Pinski]

On Mar 30, 2005, at 3:22 PM, lothar wrote:
Hello,
Michael Meissner redirected me to this list, I contacted him because 
his emailaddress was in rs6000/linux.h. I don't know who currently 
maintains this file

I ran into trouble when trying to build a cross compiler for the 
RS6000 (target=ppc-linux).

Try using cross tools, they help a lot with building a cross compiler 
for
powerpc-linux-gnu (and other linux-gnu targets).

-- Pinski

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |4.1.0


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

[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2005-03-30 
21:10 ---
Patch here: .


-- 
   What|Removed |Added

   Keywords||patch
   Last reconfirmed|2005-03-28 12:42:10 |2005-03-30 21:10:28
   date||


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

[Bug c++/20629] internal compiler error: in cp_tree_equal, at cp/tree.c:1552

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-30 
21:42 ---
(In reply to comment #4)
> I'm still seeing this, but some info...
> a) I'm only seeing this with LANG=C, export LANG=en_US.UTF-8 and there is no 
> crash
> b) compiling the dumped proprocessed code isn't crashing in either LANG

Hmm, that usually means some memory corruption somewhere in GCC or a 
miscompiling of GCC.
Does this happen with a build of GCC with BOOT_CFLAGS="-O0 -g"?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-30 22:45 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

janis at gcc dot gnu dot org wrote:
> Nightly mainline bootstraps for powerpc64-linux have been failing
> intermittently since changes went in last week to allow running
> libstc++ tests on installed tools.  For "make bootstrap", abi_check
> is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float.
> "make install" tries to build it again, but a 32-bit build of
> abi_float tries to use the existing libv3test, and the link fails if
> the type of the leftover library (e.g. 64-bit) doesn't match the type
> of the new abi_check.  All of the abi_check builds appear to be done
> in the same directory.

Janis, am I correct in assuming that you're running "make check" between 
"make bootstrap" and "make install"?  If so, I think I understand what's 
happenning, and I can work on fixing it.  Otherwise, I've got to dig a 
little deeper.

Thanks,



-- 


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

[Bug target/16871] missing vector support

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-03-30 
22:49 ---
Subject: Re:  missing vector support

steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2005-03-30 
> 11:21 ---
> Is anyone going to work on these intrinsics?  Is there a list somewhere
> of what intrinsics we are talking about here?

See comment #1, which points at patch written by HJ, which needs some 
more work, and probably also a formal review.

As far as I know, the intrinsics are only defined in the Intel compiler 
documentation.  That is the list HJ is working from.  As I understand 
it, there is an intrinsic defined for every IA-64 instruction.  Thus any 
gcc extended asm can be converted into intrinsic calls.  If you know the 
naming scheme, you can probably generate your own list from IA-64 
architecture documentation.

There was also two threads in the gcc list started by Jan Beulich here
 http://gcc.gnu.org/ml/gcc/2005-01/msg00204.html
 http://gcc.gnu.org/ml/gcc/2005-01/msg00276.html
I don't think he was volunteering to do the work, but he did point out 
some issues that need to be considered, such as how vectors should be 
treated as arguments and parameters.


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:45 
---
I should add that I think this is a target independent bug as it also fails for
a mipsel-linux target.

-- 
   What|Removed |Added

  Known to fail||3.4.3 4.0.0


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

[Bug bootstrap/20698] [4.0 Regression] configure broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
00:37 ---
hmm, what compiler are you using which don't understand -c -o?

-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:55 
---
If you modify the testcase file A.java so that the inner class A1 is no longer
static, the testcase converts to an ice-on-invalid-code.

-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:56 
---
Created an attachment (id=8502)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8502&action=view)
First part of smaller testcase.


-- 


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

[Bug java/20697] Invalid Can't find method error on call to super

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-03-30 23:58 
---
Created an attachment (id=8503)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8503&action=view)
Second part of smaller testcase.

New Testcase.  I think it is the same problem.

$ gcj A1.java B1.java
B1.java: In class `B1':
B1.java: In method `B1.n()':
B1.java:10: error: Can't find method `m()' in type `B1'. Candidates are:
  `B1.m()' in `B1'
  `A1$A2.m()' in `A1$A2'.
   m();
   ^
1 error


-- 


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

[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 23:07 
---
Patch posted , awaiting
review.


-- 


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

[Bug debug/20268] With optimization, generating incomplete debug information

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 
23:08 ---
Subject: Bug 20268

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-30 23:08:23

Modified files:
gcc: ChangeLog dwarf2out.c 

Log message:
Emit DW_AT_ranges for inlined subroutines that contain disjoint blocks.
PR debug/20268
* dwarf2out.c (add_high_low_attributes): New function, extracted from
gen_lexical_block_die.
(gen_lexical_block_die, gen_inlined_subroutine_die): Call it.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8043&r2=2.8044
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.575&r2=1.576



-- 


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

[Bug debug/20268] With optimization, generating incomplete debug information

[wilson at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |wilson at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-30 23:08:11
   date||


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-31 00:54 
---
Subject: Re:  [3.4 Regression] -fstrict-aliasing causes incorrect
 scheduling

ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-30 
> 10:53 ---
> Hum... type-punning simply doesn't work in this case with the C++ compiler, 
> but
> does work with the C compiler.  The problem is that:
> 
>   union u {
>   x_uint64_t first;
>   x_uint32_t second;
>   };
>   union u conv;
>   conv.first = arg1;
>   result = conv.second;
> 
> is translated into:
> 
>   *(&conv.first) = *(&arg1);
>   *(&result) = *(&conv.second);
> 
> and type-punning cannot work in this case (that's the counter-example provided
> in the manual).  I guess the problem comes the fields being of aggregate 
> types.
> 
> Mark, is that fixable or should we document the limitation?

I think it's fixable.  I'm not sure exactly why the C++ front-end is 
inserting the additional operations, but they're certainly not essential 
from a C++ semantics point of view.  Please reassign the bug to me; I'll 
try to take a look.

Thanks,



-- 


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

[Bug bootstrap/20698] [4.0 Regression] configure broken

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-03-31 00:59 ---
Subject: Re:  [4.0 Regression] configure broken

> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
> 00:37 ---
> hmm, what compiler are you using which don't understand -c -o?

The ultrix cc (pcc) doesn't understand -c -o.  I'm using gcc for the
build but:

checking whether gcc and cc understand -c and -o together... no

I'm not sure why the test checks both.

Dave


-- 


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

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-31 00:10 
---
Subject: Re:  New: make install failure building abi_check
 with leftover libv3test

janis at gcc dot gnu dot org wrote:
> Nightly mainline bootstraps for powerpc64-linux have been failing
> intermittently since changes went in last week to allow running
> libstc++ tests on installed tools. 

I would like to solve this problem by moving the compilation and 
execution of abi_check.cc into DejaGNU, and check having "make 
abi_check" invoke DejaGNU appropriate to run just that test.

Benjamin, any objections to that plan?



-- 


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

[Bug debug/20268] With optimization, generating incomplete debug information

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-03-30 
23:18 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug java/20697] Invalid Can't find method error on call to super

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-31 
00:24 ---
Confirmed, I think this is a dup of bug 18119.

-- 
   What|Removed |Added

  BugsThisDependsOn||18119
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-31 00:24:37
   date||


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

[Bug libmudflap/20696] New: all libmudflap tests fail on mips{,el}-linux

[debian-gcc at lists dot debian dot org]

all libmudflap tests fail on mips{,el}-linux.

/home/doko/gcc/gcc-4.0-4.0ds9/build/mipsel-linux/./libmudflap/.libs/libmudflap.so:
undefined reference to `_start'
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
/home/doko/gcc/gcc-4.0-4.0ds9/build/mipsel-linux/./libmudflap/.libs/libmudflap.so:
undefined reference to `_start'
collect2: ld returned 1 exit status

or these architectures, the symbol should be __start, not _start, suggested by
Thimo Seufer (one of our mipsel porters) ?

-- 
   Summary: all libmudflap tests fail on mips{,el}-linux
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: mipsel-linux


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

[Bug target/19139] data referenced as short misplaced in non-short linkonce section

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-03-30 23:26 
---
I think this defect is fixed with the patch:

http://gcc.gnu.org/ml/gcc/2005-01/msg00589.html

that was checked in back in January of 2005.

Jan, can you confirm that the defect is fixed?  It looks OK to me on a small
test case I created but since I don't have a specific included test case to
check I would like you to confirm that this is fixed and the defect can be 
closed.

-- 
   What|Removed |Added

 CC||sje at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug debug/20268] With optimization, generating incomplete debug information

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug java/20697] Invalid Can't find method error on call to super

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||18131
  nThis||


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