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

[loki at inf dot u-szeged dot hu]

--- Additional Comments From loki at inf dot u-szeged dot hu  2004-11-03 08:17 
---
I made some changes in the patch. I hope that it will be satisfying.
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00130.html


-- 


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

[Bug c++/7740] builtins, and functions marked as extern "C++" with incorrect "C" linkage

[joerg dot richter at pdv-fs dot de]

--- Additional Comments From joerg dot richter at pdv-fs dot de  2004-11-03 08:20 
---
In a recent discussion on comp.lang.c++.moderated was this example to give 
bar "C++" linkage and foo "C" linkage. But g++ gives them both "C" linkage. It 
might be anonther instance of this problem.


extern "C++" {
  typedef void (cpp_func)(int);
}
extern "C" void foo(int a){
   cpp_func bar;
   bar(a);
}

> nm x.o
 U bar
 T foo



-- 
   What|Removed |Added

 CC||joerg dot richter at pdv-fs
   ||dot de


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

[Bug c++/18285] New: [4.0 regression] multiple types in typedef not rejected

[reichelt at gcc dot gnu dot org]

The following invalid line of code is accepted by mainline's C++ frontend:

==
typedef void int char void double X;
==

The regression was introduced in June:
: Search converges between 2004-06-24-trunk (#471) and 2004-06-26-trunk (#472).

-- 
   Summary: [4.0 regression] multiple types in typedef not rejected
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug other/17108] Missed opportunity for strength reduction

[nathan at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug debug/18280] [3.4 regression] ICE in output_die, at dwarf2out.c:6702

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-03 11:07 
---
Confirmed. Reduced testcase (compile with "-g"):

=
namespace N
{
struct A {} a;
typedef A B;

void foo()
{
struct C
{
C(B) {}
} c(a);
}
}
=


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |debug
 Ever Confirmed||1
   Keywords||monitored
   Last reconfirmed|-00-00 00:00:00 |2004-11-03 11:07:13
   date||
Summary|ice in output_die, at   |[3.4 regression] ICE in
   |dwarf2out.c:6702|output_die, at
   ||dwarf2out.c:6702
   Target Milestone|--- |3.4.4


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

[Bug c++/18286] New: templates with multipile inheritence fail compile

[amir at spinux dot com]

There seems to be a problem with multipile inheritence and template
the attached code compile on gcc 3.2.2 and fail on gcc 3.4.2
the same code with only one inheritace (delete class c) pass compile

compiler version
c++ -v
Reading specs from /insightix/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ../configure --prefix=/insightix/local/
Thread model: posix
gcc version 3.4.2

gcc build configuration options
../configure --prefix=/usr/local/gcc_test

c++ test.cpp
In file included from test.cpp:2:
test.h: In constructor `c::c()':
test.h:23: error: `int_b' undeclared (first use this function)
test.h:23: error: (Each undeclared identifier is reported only once for each
function it appears in.)
test.h:23: error: `int_a' undeclared (first use this function)

test.cpp

#include "test.h"

int main(void){
c class_c;

return 0;
}


test.h
#ifndef __TEST_H
#define __TEST_H

class a{
public:
int int_a;

a() {int_a = 0;}
~a() {};
};

template class b: public a{
public:
int int_b;

b() {int_b = 0; int_a = 1;}
};

template class c: public b{
public:
int int_c;

c() {int_c = 0; int_b = 1; int_a = 2;}
};

#endif

-- 
   Summary: templates with multipile inheritence fail compile
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amir at spinux dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: x86
GCC target triplet: x86


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

[Bug rtl-optimization/16456] PowerPC - redundant subtract involving pointer types

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-03 11:20 
---
What is happening is that convert_to_integer, which is used to convert the
subtraction result to the type of 'x', reassociates the cast from
  (int)((long)ptr1 - (long)ptr2)
to
  (int)ptr1 - (int)ptr2
As it thinks that's a win.  Unfortunately this stops CSE noticing that
the later subtraction is actually the same.

This is another example of premature tree optimization, and it should be addressed
in the reworking of fold itself.  I don't think this should be attempted at stage 3

-- 


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

[Bug other/17108] Missed opportunity for strength reduction

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-03 11:25 
---
The situation has improved, as the biv has now been spotted, and the loop
turned into,
.foo:
li 0,8
mtctr 0
.align 4
.L2:
stfs 1,0(3)
addi 3,3,4
bdnz .L2
blr

Unfortunately this has placed the increment after the load, and so
cannot be merged into it.  If the loop optimizer knew the target had
pre-inc, it might be able to swap them round by biasing the pointer
before the loop. 

-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/16802] PowerPC - Unnecessary extsw

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-03 11:29 
---
I believe this is a problem with the tree optimizers being ABI blind. on 64bit
ppc integral parameters and return values are correctly extended to 64 bits.  This
sign extension is inserted during the tree->rtl translation, and therefore
cannot leverage any ssa-vrp information.  Unfortunately RTL does not have VRP
itself, but only condition-code propagation.  Combine does not track values
across basic blocks, so it too is blind in this case, as the register is
written in two blocks.

-- 


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

[Bug c++/18286] templates with multipile inheritence fail compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 12:17 
---
Read the release notes on why this is invalid C++ and why this changed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/18285] [4.0 regression] multiple types in typedef not rejected

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 12:18 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-03 12:18:14
   date||
   Target Milestone|--- |4.0.0


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

[Bug c++/18123] [3.4/4.0 regression] ICE on templated enum

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-11-03 12:22 
---
Patch submitted:
  http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00194.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug libstdc++/17664] [3.4 only] Crash in std::map when using _GLIBCXX_DEBUG with multithreading

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 12:24 
---
Fixed on the mainline, queued for 3.4.4.

-- 
   What|Removed |Added

  Known to work||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-11-03 12:24:25
   date||
Summary|Crash in std::map when using|[3.4 only] Crash in std::map
   |_GLIBCXX_DEBUG with |when using _GLIBCXX_DEBUG
   |multithreading  |with multithreading
   Target Milestone|--- |3.4.4


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

GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

[Lee-Thorp, Andrew]

GCC 3.4.2 selects an 'unavailable' function overload.
Platform is Cygwin on Windows 2000.

See the example below.

class A {};
class B : public A {};
class C : private A {};

void f(...);
void f(A*);
void error()
{
  f(static_cast(0));
  f(static_cast(0)); // <- Line 42
}

Conversion.cc: In function `void error()':
Conversion.cc:42: error: `A' is an inaccessible base of `C'
===
 Information contained in this email message is intended only for use of the 
individual or entity named above. If the reader of this message is not the intended 
recipient, or the employee or agent responsible to deliver it to the intended 
recipient, you are hereby notified that any dissemination, distribution or copying of 
this communication is strictly prohibited. If you have received this communication in 
error, please immediately notify us by email to [EMAIL PROTECTED] and destroy the 
original message.

[Bug target/18230] SPARC VIS instructions are not generated by GCC

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2004-11-03 14:28 
---
Re-running the libjava tests there are no new failures. I suspect the load on my
machine was higher was higher when those tests originally ran.

-- 


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

[Bug libfortran/18284] BACKSPACE broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 14:36 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-03 14:36:10
   date||


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

Re: GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

[Giovanni Bajo]

Lee-Thorp, Andrew wrote:

> GCC 3.4.2 selects an 'unavailable' function overload.
> Platform is Cygwin on Windows 2000.

Please, submit a bug report through our Bugzilla interface
(http://gcc.gnu.org/bugzilla).

Thanks.
Giovanni Bajo

[Bug tree-optimization/16797] Opportunity to remove unnecessary load instructions

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-03 14:40 
---
ug. This bug falls between a number of stools.
1) on ppc-64 ints are returned correctly sign extended to 64 bits
2) the tree-ssa optimizers are blind to parameter marshalling, so the necessary
sign extension is added at the tree->rtl conversion
3) When combine runs, there is still one common exit block containing
  i_64 = contents_of_i
  i_32 = (int)i_64
  result = sign_extend (i_32)
As the 'contents_of_i' are initialized in different blocks, combine has no
knowledge of its possible values.  So, it doesn't know the truncation and
extension is a nop.
4) The terminating bb gets duplicated by bbro right at the end of optimization.
No subsequent cse stage runs after that.

If tree-ssa was made ABI aware, we'd be in much better shape.
This is similar to 16802 but with bb-cloning to further expose the stupidity

-- 


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

[Bug libstdc++/10606] uncaught_exception() returns false too early

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-03 14:47 
---
If the issue is still under the C++ committee, this bug should be suspended. 
Unless there is something which is *surely* wrong with C++ and that can be 
fixed meanwhile.

-- 


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

[Bug libstdc++/10606] uncaught_exception() returns false too early

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-03 14:48 
---
(In reply to comment #10)

> If the issue is still under the C++ committee, this bug should be suspended. 
> Unless there is something which is *surely* wrong with C++ and that can be 
> fixed meanwhile.

I meant "wrong with G++" of course.


-- 


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

[Bug target/16457] PowerPC - Combine two rldicr instructions into a single rlwinm.

[nathan at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2004-11-03 15:08 
---
Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch statements 
with large # of cases


On Nov 3, 2004, at 10:03 AM, Jeffrey A Law wrote:

>
> With loop bounds recording no longer charged to the expander it's time
> to deal with the inefficiencies which are in the switch expander.
>
> Basically we have code which does
>
> for each case
>   for each case
> see if the label in the outer loop matches any of the cases in the
> inner loop (up to the current case in the outer loop).

We don't really need some of this code anyways because the gimplifier
now reorders the case statements so that you don't have to do the loop
at all.

Thanks,
Andrew Pinski



-- 


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

[Bug target/17108] Missed opportunity for strength reduction

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 15:33 
---
Corresponding code which gives what is wantted here is:
void foo(float *data, float d) {
   long i;

   data--;
   for (i = 0; i < 8; i++)
 {
  data[1] = d;
  data++;
 }
}

-- 
   What|Removed |Added

   Last reconfirmed|2004-08-19 15:25:53 |2004-11-03 15:33:17
   date||


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

[Bug target/16457] PowerPC - Combine two rldicr instructions into a single rlwinm.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 15:41 
---
What is happening is the following instruction is being split up:
(insn:HI 14 13 15 0 (parallel [
(set (reg:DI 123)
(and:DI (reg/v:DI 118 [ x ])
(const_int 4294967294 [0xfffe])))
(clobber (scratch:CC))
]) 273 {anddi3} (nil)
(expr_list:REG_DEAD (reg/v:DI 118 [ x ])
(expr_list:REG_UNUSED (scratch:CC)
(nil

It is being split up inefficently.

-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-03 15:43 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Wed, 2004-11-03 at 15:08 +, pinskia at physics dot uc dot edu
wrote:
> --- Additional Comments From pinskia at physics dot uc dot edu  2004-11-03 15:08 
> ---
> Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch 
> statements with large # of cases
> 
> 
> On Nov 3, 2004, at 10:03 AM, Jeffrey A Law wrote:
> 
> >
> > With loop bounds recording no longer charged to the expander it's time
> > to deal with the inefficiencies which are in the switch expander.
> >
> > Basically we have code which does
> >
> > for each case
> >   for each case
> > see if the label in the outer loop matches any of the cases in the
> > inner loop (up to the current case in the outer loop).
> 
> We don't really need some of this code anyways because the gimplifier
> now reorders the case statements so that you don't have to do the loop
> at all.
Note carefully we are looking at the destination labels for each
case within the switch.  Thus to be able to avoid this loop we would
have to know that even after the optimizers run that all cases which
transfer control to the same destination are grouped together.
jef





-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[richard dot guenther at gmail dot com]

--- Additional Comments From richard dot guenther at gmail dot com  2004-11-03 
15:44 ---
Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch statements 
with large # of cases

On Wed, 3 Nov 2004 10:07:58 -0500, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> 
> On Nov 3, 2004, at 10:03 AM, Jeffrey A Law wrote:
> 
> >
> > With loop bounds recording no longer charged to the expander it's time
> > to deal with the inefficiencies which are in the switch expander.
> >
> > Basically we have code which does
> >
> > for each case
> >   for each case
> > see if the label in the outer loop matches any of the cases in the
> > inner loop (up to the current case in the outer loop).
> 
> We don't really need some of this code anyways because the gimplifier
> now reorders the case statements so that you don't have to do the loop
> at all.

I believe I have seen patches from Kazu that address this.

Richard.


-- 


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

[Bug tree-optimization/18184] [4.0 Regression] Tree optimizers ignore pointer modes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 16:02 
---
New patch: .

-- 
   What|Removed |Added

   Last reconfirmed|2004-10-27 16:46:37 |2004-11-03 16:02:22
   date||


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-11-03 16:33 ---
Richard,

My patches to expand_case does not change its asymptotic behavior.

Jeff,

You might want to use SBITMAP instead of BITMAP in your patch to
expand_case because the bitmap you construct will be dense, and you know
its size in advance.


-- 


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

[Bug libstdc++/10606] uncaught_exception() returns false too early

[sebor at roguewave dot com]

--- Additional Comments From sebor at roguewave dot com  2004-11-03 16:42 ---
(In reply to comment #10)

I think it's clear that gcc is wrong in not returning true in the initializer
of the exception object in the catch handler (the second invocation of the copy
ctor in the test case). What's not so clear cut is whether it should also do so
during the creation of the temporary exception object (the first invocation of
the copy ctor).

-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-03 16:46 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Wed, 2004-11-03 at 16:33 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-11-03 16:33 
> ---
> Richard,
> 
> My patches to expand_case does not change its asymptotic behavior.
> 
> Jeff,
> 
> You might want to use SBITMAP instead of BITMAP in your patch to
> expand_case because the bitmap you construct will be dense, and you know
> its size in advance.
No you don't know it's size or density in advance.  We're not looking
at case values, but at the label where each case statement will jump to.

Jeff



-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-11-03 16:51 ---
Jeff,

Oops, you're right!

Kazu Hirata


-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[s dot bosscher at student dot tudelft dot nl]

--- Additional Comments From s dot bosscher at student dot tudelft dot nl  
2004-11-03 16:52 ---
Subject: RE:  [4.0 Regression] jump threading
 on trees is slow with switch statements with large # of cases

> No you don't know it's size or density in advance.  We're not looking
> at case values, but at the label where each case statement will jump to.

You could move the expand code for SWITCH_EXPRs out of
expand_expr, and call it from cfgexpand.c, passing the
number of outgoing edges.



-- 


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

[Bug c/18287] New: Unaligned access to fields inside packed records

[ebotcazou at gcc dot gnu dot org]

The testcase I'm about to attach generates a bug error at runtime on the SPARC
(and very likely on any other STRICT_ALIGNMENT target).  Verified with 2.95.3,
3.3.x, 3.4.x and 4.0pre.

I think the front-end wrongly turns ADDR_EXPR> into
PLUS_EXPR whatever the alignment of the field.  For reference, the Ada front-end
doesn't do the simplification and lets the middle-end generate the temporary if
required.

-- 
   Summary: Unaligned access to fields inside packed records
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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

[Bug c/18287] Unaligned access to fields inside packed records

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-11-03 17:53 
---
Created an attachment (id=7467)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7467&action=view)
Testcase.

To be compiled with -O0.


-- 


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

[Bug c/18287] Unaligned access to fields inside packed records

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 18:02 
---
Are you sure that 4.0.0 does not work, as it no longer does the transformation for 
&(a->b) into a + 
offsetof(a,b).
>From the last tree dump for 4.0.0:
;; Function Assign_Hour_Of (Assign_Hour_Of)

Assign_Hour_Of (t)
{
:
  t->Hour = 44;
  return;

}



;; Function Clobber_Hour_Of (Clobber_Hour_Of)

Clobber_Hour_Of (dt)
{
  struct Time_T * D.1128;

:
  D.1128 = &dt->Time;
  Assign_Hour_Of (D.1128);
  return;

}



;; Function main (main)

main ()
{
  struct Date_And_Time_T dt;
  int D.1135;

:
  dt.Time.Hour = 22;
  Clobber_Hour_Of (&dt);
  D.1135 = 0;
  return D.1135;

}


-- 


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

[Bug c/18287] Unaligned access to fields inside packed records

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 18:03 
---
  t->Hour = 44;  /* unaligned word access */
is unaligned word access if t is not word aligned in the first place, correct which is 
where the problem 
comes in right?

-- 


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

[Bug rtl-optimization/14237] suboptimal comparison between long and long long

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 18:14 
---
For PPC, we have:
cmplw cr7,r0,r9
cmpw cr6,r0,r9
bgtlr- cr7
beq- cr6,L6
equality test can be done logically or arthimaticly so we don't need both cmp*'s.

-- 
   What|Removed |Added

   Last reconfirmed|2004-05-30 03:50:25 |2004-11-03 18:14:14
   date||


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

[Bug c/18287] Unaligned access to fields inside packed records

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-11-03 18:17 
---
>   t->Hour = 44;  /* unaligned word access */
> is unaligned word access if t is not word aligned in the first place, correct
> which is where the problem comes in right?

I confirm that the bus error (not bug error!) happens with 4.0.0 20041103.  But,
you're right, probably another problem there.

The compiler should not pass the adress of &dt->Time to Assign_Hour_Of if it
can't prove that the field is at least as aligned as its type.


-- 


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

[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-03 18:56 
---
Subject: Bug 18270

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-03 18:56:36

Modified files:
gcc: ChangeLog tree-outof-ssa.c 

Log message:
2004-11-03  Andrew MacLeod  <[EMAIL PROTECTED]>

PR tree-optimization/18270
* tree-outof-ssa.c (analyze_edges_for_bb): If a block has any incoming
abnormal edges, simply commit any pending stmts on all incoming edges.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6150&r2=2.6151
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcc&r1=2.28&r2=2.29



-- 


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

[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 19:28 
---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/18231] [4.0 regression] Nested inline function not inlined

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-03 19:55 
---
Subject: Bug 18231

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-03 19:55:31

Modified files:
gcc: ChangeLog tree.c 

Log message:
2004-11-03  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/18231
* tree.c (staticp) : Nested functions are static
also.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6151&r2=2.6152
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.443&r2=1.444



-- 


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

[Bug middle-end/18231] [4.0 regression] Nested inline function not inlined

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 19:56 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/18287] Unaligned access to fields inside packed records

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 19:57 
---
There is another example of this in PR 17949 where the tree-optimizations cause 
something werid to 
happen only because the middle-end does not know that they are unaligned loads.

-- 


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

[Bug bootstrap/18288] New: remaking existing build after cvs update gives configure recheck problems

[mark at gcc dot gnu dot org]

When updating a source try (through contrib/gcc_update) and typing make in the
build directory configure recheck fails often for the runtime libraries
(libc++-v3, libjava, boehmgc, libffi, etc.) Here is an example for libmudflap:

make[1]: Entering directory `/home/mark/src/gcc-obj/i686-pc-linux-gnu/libmudflap'
/bin/sh ./config.status --recheck
running /bin/sh /home/mark/src/gcc/libmudflap/configure 
--cache-file=./config.cache --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--enable-multilib --enable-java-awt=gtk --prefix=/usr/local/gcc35
--with-gcc-version-trigger=/home/mark/src/gcc/gcc/version.c
--enable-languages=c,c++,java --program-transform-name=s,y,y,
--srcdir=../../../gcc/libmudflap --with-target-subdir=i686-pc-linux-gnu
CPPFLAGS=-O2 -g -O2 build_alias=i686-pc-linux-gnu host_alias=i686-pc-linux-gnu 
--no-create --no-recursion
configure: loading cache ./config.cache
configure: error: `target_alias' was not set in the previous run
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start
overmake[1]: *** [config.status] Error 1
make[1]: Leaving directory
`/home/mark/src/gcc-obj/i686-pc-linux-gnu/libmudflap'make: ***
[all-target-libmudflap] Error 2

A workaround is deleting that whole subdirectory and trying make from the
toplevel build directory again.

-- 
   Summary: remaking existing build after cvs update gives configure
recheck problems
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18289] New: GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

[aleethorp at hotmail dot com]

GCC 3.4.2 selects an overload that requires an inaccessible conversion when an
ellipsis function overload is available

Platform is Cygwin on Windows 2000.

See the example below.

class A {};
class B : public A {};
class C : private A {};

void f(...);
void f(A*);
void error()
{
  f(static_cast(0));
  f(static_cast(0)); // <- Line 42
}

Conversion.cc: In function `void error()':
Conversion.cc:42: error: `A' is an inaccessible base of `C'

-- 
   Summary: GCC3.4.2 selects incorrect function overload when an
ellipsis overload is available
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aleethorp at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug bootstrap/18288] remaking existing build after cvs update gives configure recheck problems

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2004-11-03 20:37 ---
Another workaround (just told to me on irc, and verified) is to rerun you
configure statement in the top level build directory before doing a make in the
top level build dir.

-- 


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

[Bug bootstrap/18288] remaking existing build after cvs update gives configure recheck problems

[fitzsim at redhat dot com]

-- 
   What|Removed |Added

 CC||fitzsim at redhat dot com


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

[Bug bootstrap/18290] New: Build failure: ansidecl.h not found (?)

[Thomas dot Koenig at online dot de]

This is for a Debian sid system.

The build compiler:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man
--infodir=/usr/share/info--with-gxx-include-dir=/usr/include/c++/3.3
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gci486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-2)

The CVS version is 4.0.0 20041103 (experimental).

$ ./configure --prefix=$HOME --enable-languages="c,f95"
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... yes
checking for MPFR... yes
*** This configuration is not supported in the following subdirectories:
 target-libada target-libstdc++-v3 target-libffi target-boehm-gc target-zlib
target-libjava zlib fastjar target-libobjc
(Any other directories should still work fine.)
checking for bison... bison
checking for bison... bison -y
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for i686-pc-linux-gnu-ar... no
checking for ar... ar
checking for i686-pc-linux-gnu-as... no
checking for as... as
checking for i686-pc-linux-gnu-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-linux-gnu-ld... no
checking for ld... ld
checking for i686-pc-linux-gnu-nm... no
checking for nm... nm
checking for i686-pc-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-linux-gnu-windres... no
checking for windres... windres
checking for i686-pc-linux-gnu-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-linux-gnu-objdump... no
checking for objdump... objdump
checking for i686-pc-linux-gnu-ar... no
checking for ar... ar
checking for i686-pc-linux-gnu-as... no
checking for as... as
checking for i686-pc-linux-gnu-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-linux-gnu-ld... no
checking for ld... ld
checking for i686-pc-linux-gnu-nm... no
checking for nm... nm
checking for i686-pc-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-linux-gnu-windres... no
checking for windres... windres
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
$ make

...
xhost-mkfrag..linked
xmalloc.c   ..linked
xmalloc.o   ..linked
xmemdup.c   ..linked
xmemdup.o   ..linked
xstrdup.c   ..linked
xstrdup.o   ..linked
xstrerror.c ..linked
xstrerror.o ..linked
make[1]: Entering directory `/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty'
make[2]: Entering directory
`/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty/testsuite'
rm -f test-demangle
rm -f Makefile
make[2]: Leaving directory
`/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty/testsuite'
make SUBDIRS="" clean
make[2]: Entering directory `/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty'
make SUBDIRS="" mostlyclean
make[3]: Entering directory `/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty'
rm -rf *.o pic core errs \#* *.E a.out
rm -f needed.awk needed2.awk errors dummy needed-list config.h stamp-*
rm -f   stamp-picdir
rm -f libiberty.aux libiberty.cp libiberty.cps libiberty.fn libiberty.ky
rm -f libiberty.log libiberty.tmp libiberty.tps libiberty.pg
rm -f libiberty.pgs libiberty.toc libiberty.tp libiberty.tpl libiberty.vr
rm -f libtexi.stamp
make[3]: Leaving directory `/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty'
rm -f *.a required-list tmpmulti.out
rm -f libiberty.dvi libiberty.info* libiberty.html
make[2]: Leaving directory `/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty'
rm -f *~ Makefile config.cache config.status xhost-mkfrag TAGS multilib.out
rm -f config.log
rmdir testsuite 2>/dev/null
make[1]: [distclean] Error 1 (ignored)
make[1]: Leaving directory `/home/ig25/gcc/build-i686-pc-linux-gnu/libiberty'
configure: creating cache ../config.c

[Bug tree-optimization/18291] New: 4.0: ICE in merge_alias_info

[gcc-bugzilla at gcc dot gnu dot org]

g++ 4.0 gives an ICE compiling the source below with -O1:

$ ./cc1plus -quiet -O1 x.cc
x.cc: In function 'void writeDigi()':
x.cc:10: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:217
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$

It's crashing at the abort() here:

212   if (new_ptr_info->name_mem_tag == NULL_TREE)
213 memcpy (new_ptr_info, orig_ptr_info, sizeof (*new_ptr_info));
214   else if (orig_ptr_info->name_mem_tag == NULL_TREE)
215 memcpy (orig_ptr_info, new_ptr_info, sizeof (*orig_ptr_info));
216   else if (orig_ptr_info->name_mem_tag != new_ptr_info->name_mem_tag)
217 abort ();

Here are the values that are being compared:

(gdb) p *orig_ptr_info
$5 = {pt_anything = 0, pt_malloc = 0, value_escapes_p = 0,
  is_dereferenced = 1, pt_global_mem = 0, pt_vars = 0x400b18a0,
  name_mem_tag = 0x400baef4}
(gdb) p *new_ptr_info
$6 = {pt_anything = 0, pt_malloc = 0, value_escapes_p = 0,
  is_dereferenced = 1, pt_global_mem = 0, pt_vars = 0x400b1880,
  name_mem_tag = 0x400bae80}
(gdb) call debug_tree( orig_ptr_info->name_mem_tag)
 
unit size 
align 32 symtab 0 alias set -1 precision 32 min  max 
pointer_to_this >
addressable used ignored SI file x.cc line 10 size  
unit size 
align 32 context >
(gdb) call debug_tree( new_ptr_info->name_mem_tag)
 
unit size 
align 32 symtab 0 alias set -1 precision 32 min  max 
pointer_to_this >
addressable used ignored SI file x.cc line 10 size  
unit size 
align 32 context >

Environment:
System: Linux karma 2.6.8.1 #20 Mon Sep 13 23:48:47 EDT 2004 i686 i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home/sss/gcc/gcc/configure --prefix=/usr/local/gcc 
--enable-threads=posix --enable-long-long --enable-languages=c,c++,f95

How-To-Repeat:


Compile with -O1:
-

struct C
{
  int size() const  { return 0;}
};

int foo (int);

void writeDigi()
{
  C strErgC;
  int  mcdigi ;
  int* pmcdigi = &mcdigi ;
  int  mcdigi_crosstalk ;
  if ( foo(0) )
pmcdigi = &mcdigi_crosstalk;

  int mcdigi_elec_noise ;
  if ( strErgC.size() > 0 )
  {
foo(*pmcdigi );
pmcdigi = &mcdigi_elec_noise;
  }
  foo(*pmcdigi);
}

-
--- Additional Comments From snyder at fnal dot gov  2004-11-03 20:43 ---
Fix:


-- 
   Summary: 4.0: ICE in merge_alias_info
   Product: gcc
   Version: 0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: snyder at fnal dot gov
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=18291

[Bug c/18292] New: Cannot use function name within function.

[deepak at despammed dot com]

Under the said version of gcc, I cannot say something like:

void foo(int bar)
{
extern void foo(int);

/* do_something. */

/* Reinstate handler. */
signal(SIGINT, foo);
}

Output is something like:
foo.c:750: error: called object is not a function
foo.c:751: error: called object is not a function
make[1]: *** [foo.o] Error 1

-- 
   Summary: Cannot use function name within function.
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deepak at despammed dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: Mandrake Linux 10.0 3.3.2-6mdk
  GCC host triplet: i586-mandrake-linux-gnu


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

[Bug c++/18289] GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 20:57 
---
Note ICC 8.0 also rejects this.

-- 


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

[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 21:02 
---
Confirmed.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org, dnovillo at gcc dot gnu
   ||dot org
   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2004-11-03 21:02:25
   date||
Summary|4.0: ICE in merge_alias_info|[4.0 Regression]: ICE in
   ||merge_alias_info
   Target Milestone|--- |4.0.0
Version|0.0 |4.0.0


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

[Bug c++/18289] GCC3.4.2 selects incorrect function overload when an ellipsis overload is available

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-03 21:03 
---
This is not a bug.

[13.3.3.2]/2 says that a standard conversion sequence is better
than an ellipsis conversion sequence.

The note in [13.3]/1 says:
The function selected by overload resolution is not guaranteed to
be appropriate for the context. Other restrictions, such as the
accessibility of the function, can make its use in the calling
context ill-formed.

Converting a pointer to a pointer of a base class is a standard
conversion. So gcc is right in choosing f(A*) and complaining
about it later.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/18292] Cannot use function name within function.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 21:06 
---
I cannot reproduce this, can you attach the preprocessed source?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/18290] Build failure: ansidecl.h not found (?)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 21:08 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 21:08 
---
*** Bug 18290 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||Thomas dot Koenig at online
   ||dot de


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[joel at oarcorp dot com]

--- Additional Comments From joel at oarcorp dot com  2004-11-03 21:09 ---
Subject: Re:  M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

bkoz at gcc dot gnu dot org wrote:
> --- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-03 00:12 
> ---
> 
> Joel, you might want to talk to the m68k maintainers. 
> 
> Take your pick:
> m68hc11 portStephane Carrez [EMAIL PROTECTED]
> m68k port (?)   Jeff Law[EMAIL PROTECTED]
> m68k-motorola-sysv port Philippe De Muyter  [EMAIL PROTECTED]
> 
> Since you are the rtems maintainer, I'm expecting you to be on top of fixing
> this, since it's currently seen as a m68k-rtems bug.
> 
> This bug hasn't been framed in a clear manner, IMHO. There's no test case, no
> patch file. If it's a generic m68k problem with 68060 and libstdc++ atomicity,
> it should be marked as such (and not rtems-specific.) If this has nothing to do
> with libstdc++, but instead has something to do with gcc or rtems, well, the
> category on this bug should reflect this.
> 
> Hope this helps.

It does and just reiterates what shuold have been done when it was 
reported.  Chris is going to try to put together a test case.

What we are concerned about is that it is more than likely a generic
problem.  Very few problems are RTEMS specific at this level.  Chris
believes that a 16-bit variable may be allocated on the stack and
this would result in it being misaligned.  This is likely the issue.
The MC68060 can't do misaligned accesses for the instruction in 
question.  On a MC68060 without software emulation of missing 
instructions, then you get a fault.

So the concern is that this is a generic m680x0 issue with
letting the stack get misaligned and it just gets caught in
this one very complex C++ scenario.

Don't close it yet and give Chris a chance to give a test case.

--joel



-- 


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

[Bug target/18106] Weak symbols are unimplemented on Windows

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2004-11-03 21:12 
---
For what its worth, the issue in comment #2 was resolved.  This patch can again
be safely applied.  It is awaiting review.

-- 
   What|Removed |Added

   Last reconfirmed|2004-10-22 11:43:25 |2004-11-03 21:12:22
   date||


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

[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info

[dnovillo at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

[lucier at math dot purdue dot edu]

--- Additional Comments From lucier at math dot purdue dot edu  2004-11-03 21:31 
---
Subject: Re:  [4.0 Regression] internal compiler error: in 
tree_redirect_edge_and_branch, at tree-cfg.c:4146

Was a new test case added with this patch?



-- 


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

[Bug c/18292] Cannot use function name within function.

[deepak at despammed dot com]

--- Additional Comments From deepak at despammed dot com  2004-11-03 21:38 ---
(In reply to comment #1)
> I cannot reproduce this, can you attach the preprocessed source?

Here is the plain source:

#include 

extern volatile sig_atomic_t pe_connection_BAD;

void
sig(int signal) {
int omask = sigsetmask(0);  /* sigsetmask(foo): we just need omask. */
extern void sig(int);

switch (signal) {
case SIGINT :
break;
case SIGUSR1 :
pe_connection_BAD = 1;
}

sigblock(omask & ~sigmask(SIGINT));
signal(SIGINT, sig);/* nscli will check for it. */
signal(SIGUSR1, sig);

}

$ cc ~/test.c -c
/home/deep/test.c: In function `sig':
/home/deep/test.c:18: error: called object is not a function
/home/deep/test.c:19: error: called object is not a function
$ 

I have added the preprocessed code to this bug report as attachment.

-- 


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

[Bug c/18292] Cannot use function name within function.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 21:41 
---
Not a bug, you have a variable called signal which shadows the global function:
sig(int signal) {

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c/18292] Cannot use function name within function.

[deepak at despammed dot com]

--- Additional Comments From deepak at despammed dot com  2004-11-03 21:50 ---
(In reply to comment #4)
> Not a bug, you have a variable called signal which shadows the global function:
> sig(int signal) {

Agree.  Is it possible to change the error message to say exactly this?  For
instance, declaring a local variable under the same name as a parameter gives
this --

/home/deep/test2.c:3: warning: declaration of `bar' shadows a parameter


-- 
   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug c/18292] Cannot use function name within function.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 21:57 
---
Use -Wshadow:
  -WshadowWarn when one local variable shadows another


-- 


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

[Bug middle-end/18293] New: Redundant copy operation introduced by expand

[steven at gcc dot gnu dot org]

Given this piece of code, 
 
struct deferred_access; 
extern struct deferred_access *D25481; 
struct deferred_access * 
foo (void) 
{ 
  return (struct deferred_access *) ((long unsigned int) D25481 * 16); 
} 
 
 
which generates on i686 in .00.expand (-fdump-rtl-expand-details): 
 
 
;; return (struct deferred_access *) ((long unsigned int) (int) D25481 * 16) 
(insn 10 9 11 (set (reg:SI 60) 
(mem/f/i:SI (symbol_ref:SI ("D25481") [flags 0x40] ) [2 D25481+0 S4 A32])) -1 (nil) 
(nil)) 
 
(insn 11 10 12 (set (reg:SI 61) 
(reg:SI 60)) -1 (nil) 
(nil)) 
 
(insn 12 11 13 (parallel [ 
(set (reg:SI 62) 
(ashift:SI (reg:SI 61) 
(const_int 4 [0x4]))) 
(clobber (reg:CC 17 flags)) 
]) -1 (nil) 
(expr_list:REG_EQUAL (mult:SI (reg:SI 60) 
(const_int 16 [0x10])) 
(nil))) 
 
(insn 13 12 14 (set (reg:SI 58 [  ]) 
(reg:SI 62)) -1 (nil) 
(nil)) 
 
 
 
Notice the unnecessary copy insn 11: 
(insn 11 10 12 (set (reg:SI 61) (reg:SI 60)) -1 (nil) (nil)) 
 
Is there some way, oh RTL gurus tell me!, to avoid introducing this 
garbage RTL that only introduces work for the RTL optimizers?

-- 
   Summary: Redundant copy operation introduced by expand
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,sayle at gcc dot gnu dot
org


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-11-03 22:25 ---
On the m68k the biggest alignment has traditionally only been 2 bytes 
(inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD 
(and previously on some configurations that are removed now) or when using 
-malign-int.  So unless you change that (which of course changes the ABI) 
you'll continue to get unaligned long words somewhere. 

-- 


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

[Bug bootstrap/18288] remaking existing build after cvs update gives configure recheck problems

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-11-03 22:32 ---
You can also just remove the Makefile from the subdirectory to trigger 
reconfiguring from the toplevel. 

-- 


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[joel at oarcorp dot com]

--- Additional Comments From joel at oarcorp dot com  2004-11-03 22:56 ---
Subject: Re:  M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

schwab at suse dot de wrote:
> --- Additional Comments From schwab at suse dot de  2004-11-03 22:25 ---
> On the m68k the biggest alignment has traditionally only been 2 bytes 
> (inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD 
> (and previously on some configurations that are removed now) or when using 
> -malign-int.  So unless you change that (which of course changes the ABI) 
> you'll continue to get unaligned long words somewhere. 

Then I think the m68060 breaks that rule by not supporting a number of
m68040 integer and FP instructions.  They provide software to handle
traps for unimplemented instructions but for performance reasons it is
best to avoid generating them in the first place.  This is similar to
how the 68040's reduced FP capabilities relative to the 68881/2 was handled.

http://www.freescale.com/files/product/doc/MC68060AR_D.pdf

(hand-typed .. sorry) describes the differences between a 68040 and 
68040.  On page 5, it specifically mentions that the CAS and CAS2
"Unlike the MC68040, the MC68060 supports the CAS instruction with 
misaligned operands, and all CAS2 variants, only via software emulation."

Table 7 on page 11, gives a full list of unimplemented integer
instructions.

Off the cuff, one possible solution is that _Atomic_word does not
have a required alignment.  I know it is possible to force alignment
on a variable. Can the same be done with a type?  T

Or is the solution to do as Andreas suggests and turn on the -malign-int
option by default on the MC68060?

I wouldn't think that making the alignment 4 bytes on the MC68060 target
would be a huge impact since those should be relatively large memory
targets board configurations anyway.

--joel


-- 


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

[Bug middle-end/18293] Redundant copy operation introduced by expand

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-03 22:58 
---
Confirmed.  This is related to casts somehow.
Also this happens on 3.3 which is even more funny and just show the deficiencies in 
the expanders 
which no one noticed before.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||compile-time-hog, memory-
   ||hog, missed-optimization
  Known to fail||3.3 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-11-03 22:58:55
   date||


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[cjohns at cybertec dot com dot au]

--- Additional Comments From cjohns at cybertec dot com dot au  2004-11-03 23:05 
---
Does this mean the instruction in question (cas) in atomicity.h cannot be used
on the 68060 if the stack can be aligned to a 2 byte boundary ?

Would a stack aligned this way cause a slow down if the call/ret address being
pushed and popped is not aligned to a 32bit boundary ?

I do not full understand the ABI issues hence my next question. RTEMS +
application is built as a single executable, typically all with the same tool
set, so does an ABI issue exist in our case ?

-- 


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

[Bug rtl-optimization/18294] New: ICE in rtl_verify_flow_info during bootstrap

[sje at cup dot hp dot com]

I get an ICE when bootstrapping the latest GCC on ia64-hp-hpux11.20.  It dies
when compiling adjust_field_type in gengtype.c.  Attached is a small test case
to reproduce the problem.  The test case only fails in ILP32 mode (the default),
it cannot be reproduced in LP64 mode (-mlp64) and it cannot be reproduced on
IA64 Linux because that has no ILP32 mode.

Test case:


void
adjust_field_type (int x)
{
  void *params[10];
  int i;
  for (i = 0; i < 10; i++)
params[i] = ((void *)0);
  for (i = 0; i < 10; i++)
if (x == 0) {
  if (params[i] != ((void *)0))
foo (x);
}
  return;
}

-- 
   Summary: ICE in rtl_verify_flow_info during bootstrap
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-hp-hpux11.20
  GCC host triplet: ia64-hp-hpux11.20
GCC target triplet: ia64-hp-hpux11.20


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[joel at oarcorp dot com]

--- Additional Comments From joel at oarcorp dot com  2004-11-03 23:25 ---
Subject: Re:  M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

cjohns at cybertec dot com dot au wrote:
> --- Additional Comments From cjohns at cybertec dot com dot au  2004-11-03 23:05 
> ---
> Does this mean the instruction in question (cas) in atomicity.h cannot be used
> on the 68060 if the stack can be aligned to a 2 byte boundary ?

Not if the memory to be swapped is on the stack.  The memory could be in 
global memory and be properly aligned.

Grrr... I forgot you can do this with GCC:

typedef unsigned int _Atomic_word __attribute__ ((aligned (4)));

Wouldn't changing the definition for the m68k to the above fix this?

> Would a stack aligned this way cause a slow down if the call/ret address being
> pushed and popped is not aligned to a 32bit boundary ?

I suspect it would but don't know the MC68060 enough to state that 
authoritatively.

> I do not full understand the ABI issues hence my next question. RTEMS +
> application is built as a single executable, typically all with the same tool
> set, so does an ABI issue exist in our case ?

If you can find something in a FreeScale document showing improved
performance for aligned accesses on the MC68060, that would tell me
that for RTEMS, we want mc68060 to imply stricter alignment.  I would
bet that others would as well if a performance increase is obtained.

--joel




-- 


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

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|ICE in rtl_verify_flow_info |[4.0 Regression] ICE in
   |during bootstrap|rtl_verify_flow_info during
   ||bootstrap
   Target Milestone|--- |4.0.0


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

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-11-03 23:44 ---
Even the 68020 should already show slight improvement when using 4 byte 
aligment due to the 32 bit data bus (the 68000/010 only have a 16 bit data 
bus). 
 
Adding an aligned attribute to the _Atomic_int type doesn't help for automatic 
variables as gcc limits the alignment to STACK_BOUNDARY.  But it will work for 
static variables. 
 
About the ABI change you are of course safe if everything is using the changed 
aligment (including the interface to the RTEMS kernel). 

-- 


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

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-04 00:20 
---
Confirmed:
t.c: In function 'adjust_field_type':
t.c:14: error: insn outside basic block
(insn 91 82 0 (set (reg/f:DI 381)
(reg/f:DI 328 sfp)) -1 (nil)
(nil))
t.c:14: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2255
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-04 00:20:36
   date||


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

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-04 00:24 
---
This is caused during .jump

-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[stevenb at suse dot de]

--- Additional Comments From stevenb at suse dot de  2004-11-04 00:28 ---
Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch statements 
with large # of cases

> However, there's clearly an algorithmic problem in this code.

There is.  The loop predictors are quadratic in the loop nest depth.
Honza already suggested predicting the loops from the innermost one to
outer, and just not predict the outer loops with such an expensive
algorithm.



-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-11-04 00:29 
---
- 

-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-04 00:58 
---
Hmm, we are putting code after the loop and after function end, I don't know why.

-- 


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

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[peter at the-baradas dot com]

--- Additional Comments From peter at the-baradas dot com  2004-11-04 02:17 ---
Chris Johns <[EMAIL PROTECTED]> asked me:

>Is the Coldfire aligned to a 2 byte boundary or a 4 byte boundary ?

The Colfire operates the same as the x86 in that the cache/bus unit will
automagically handle unaligned data as multiple aligned accesses for smaller
data sizes (i.e. byte-short-byte) to the bus/cache to access a long on a
0bxx11 address without a software trap.

Chris also asks in comment #11:

>Would a stack aligned this way cause a slow down if the call/ret address being
>pushed and popped is not aligned to a 32bit boundary ?

On the ColdFire core there will be a *measurable* performance hit if the stack
is not kept long aligned since the interface from the ColdFire core to the cache
unit will have to prevent accesses that can straddle alignment boundaries, so an
access that is entirely within a cache line boundary, but is unaligned(for the
size of the access) will still be broken up into seperate aligned accesses to
the cache.  The 16 bit instruction alignement performance penalty is mitigated
by the instruction pre-fetch unit performing 32-bit aligned accesses to the
cache/bus unit.



-- 


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

[Bug target/18230] SPARC VIS instructions are not generated by GCC

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2004-11-04 03:10 
---
 It seems that sparc{,64} is not supported in host-linux.c so the tests may be
passing by accident.

-- 


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

[Bug libfortran/18284] BACKSPACE broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-04 03:20 
---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug rtl-optimization/16088] [4.0 Regression] Generates wrong code

[lucier at math dot purdue dot edu]

--- Additional Comments From lucier at math dot purdue dot edu  2004-11-04 03:31 
---
Subject: Re:  [4.0 Regression] Generates wrong code

I tried again, I'm having the same problems with today's 4.0.

I also have the same problems on sparc-sun-solaris2.9.  I tried 
debugging it with gdb 6.2.1 on that platform but got garbage 
information about variables, etc.  Geoff says I can't trust gdb on 
powerpc-apple-darwin7.5.0, either, with -O1.

Is there any gdb on any OS platform that I can use to debug this 
problem?  Should I try it on a friend's x86 Linux box?  Or should I 
proceed in a different way.



-- 


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

[Bug libstdc++/18277] [4.0 Regression] libsupc++/guard.cc:62: error: 'RECURSIVE_ERRORCHECKMUTEX' was not declared in this scope

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|libsupc++/guard.cc:62:  |[4.0 Regression]
   |error:  |libsupc++/guard.cc:62:
   |'RECURSIVE_ERRORCHECKMUTEX' |error:
   |was not declared in this|'RECURSIVE_ERRORCHECKMUTEX'
   |scope   |was not declared in this
   ||scope
   Target Milestone|--- |4.0.0


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

[Bug target/18295] New: ICE

[ralf_corsepius at rtems dot org]

The code from the attachment causes arm-rtems-gcc/arm-elf-gcc to ICE at -O3:

# arm-rtems4.7-gcc -msoft-float  -O3 -c clnt_tcp.i
../../../../../../../rtems.orig/c/src/../../cpukit/librpc/src/rpc/clnt_tcp.c: In
function `clnttcp_call':
../../../../../../../rtems.orig/c/src/../../cpukit/librpc/src/rpc/clnt_tcp.c:291:
warning: assignment from incompatible pointer type
../../../../../../../rtems.orig/c/src/../../cpukit/librpc/src/rpc/clnt_tcp.c:328:
internal compiler error: in verify_local_live_at_start, at flow.c:546
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

It does not ice with optimization levels < 3.
# arm-rtems4.7-gcc --version
arm-rtems4.7-gcc (GCC) 3.4.3 20041103 (prerelease)

This is a regression against gcc-3.2.3 which compiles the code without error.

-- 
   Summary: ICE
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: arm-elf* arm-rtems*


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

[Bug rtl-optimization/18295] ICE

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|target  |rtl-optimization
   Keywords||ice-on-valid-code


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

[Bug rtl-optimization/18295] ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-04 04:41 
---
This looks close to PR 15342, I am going to assume it works at -O2.

-- 
   What|Removed |Added

  BugsThisDependsOn||15342


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

[Bug rtl-optimization/18295] ICE

[ralf_corsepius at rtems dot org]

--- Additional Comments From ralf_corsepius at rtems dot org  2004-11-04 04:42 
---
Created an attachment (id=7470)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7470&action=view)
*.i of a real world source files triggering the ICE


-- 


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

[Bug java/18190] [4.0 regression] primitive array optimization is gone

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-04 04:53 
---
Some of the code from java_expand_expr should be moved into 
java_gimplify_new_array_init.
And maybe fix up libjava code or maybe just storing the array's vtable by using a 
store.  I might look 
into doing this tomorrow.

-- 
   What|Removed |Added

   Last reconfirmed|2004-10-28 01:39:42 |2004-11-04 04:53:33
   date||


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

[Bug pch/14940] PCH largefile test fails on various platforms

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2004-11-04 04:57 
---
+ #elif defined(__sparc__)
+ # define TRY_EMPTY_VM_SPACE   0x6000

 Also works for sparc-linux and largefile.c on sparc64-linux.  Unfortunatly,
there are other pch failures on sparc64-linux.

-- 


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

[Bug rtl-optimization/18295] ICE

[ralf_corsepius at rtems dot org]

--- Additional Comments From ralf_corsepius at rtems dot org  2004-11-04 05:16 
---
Thanks, yes, 15342 looks very similar.

And yes, it does not ice at -O2 (This is what I had meant by writing "it does
not ice at optimization levels < 3").

 

-- 


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

[Bug tree-optimization/18009] [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-04 05:27 
---
Subject: Bug 18009

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-04 05:26:55

Modified files:
gcc: ChangeLog tree-vectorizer.h tree-vectorizer.c 

Log message:
PR tree-optimization/18009
* tree-vectorizer.h (enum dr_alignment_support): New type.
(MAX_NUMBER_OF_UNALIGNED_DATA_REFS): Removed.
(LOOP_UNALIGNED_DR): replaced with LOOP_VINFO_UNALIGNED_DR and holds a
single data_reference (instead of a varray of references).
* tree-vectorizer.c (new_loop_vec_info): Likewise.
(vect_gen_niters_for_prolog_loop): Likewise.
(vect_update_inits_of_drs): Likewise.

(vect_update_inits_of_drs): Setting of DR_MISALIGNMENT moved to
vect_enhance_data_refs_alignment.
(vect_do_peeling_for_alignment): Likewise.
(vect_enhance_data_refs_alignment): Decide if and by how much to peel;
this functionality used to be in vect_analyze_data_refs_alignment.
Also update DR_MISALIGNMENT due to peeling; this functionality used to
be in vect_update_inits_of_drs and vect_do_peeling_for_alignment).
(vect_analyze_data_refs_alignment): Decision on whether and by how much
to peel moved to vect_enhance_data_refs_alignment. Call
vect_supportable_dr_alignment.

(vect_compute_data_ref_alignment): Set STMT_VINFO_VECTYPE.
(vect_compute_data_refs_alignment): Return bool. Consider return value
of vect_compute_data_ref_alignment and return true/false accordingly.
(vect_enhance_data_refs_alignment): Consider return value of
vect_compute_data_refs_alignment and return true/false accordingly.

(vect_supportable_dr_alignment): New function.
(vectorizable_store): Call vect_supportable_dr_alignment.
(vectorizable_load): Call vect_supportable_dr_alignment. Alignment
support checks moved from here to vect_supportable_dr_alignment.

(vect_transform_loop): Avoid 80 columns overflow.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6157&r2=2.6158
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vectorizer.h.diff?cvsroot=gcc&r1=2.6&r2=2.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vectorizer.c.diff?cvsroot=gcc&r1=2.22&r2=2.23



-- 


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

[Bug rtl-optimization/17428] [4.0 Regression] internal compiler error: in spill_failure, at reload1.c:1880

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-11-04 07:06 
---
Patch for the other problem:

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00260.html

-- 


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

[Bug pch/14940] PCH largefile test fails on various platforms

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-11-04 07:09 
---
> + #elif defined(__sparc__)
> + # define TRY_EMPTY_VM_SPACE 0x6000
> 
>  Also works for sparc-linux and largefile.c on sparc64-linux.  Unfortunatly,
> there are other pch failures on sparc64-linux.

I'm a bit skeptical about using the same value for the 32-bit and the 64-bit
flavors, but I'm not a specialist of Linux on the SPARC at all.  I'd suggest to
contact David S. Miller (see the MAINTAINERS file).


-- 
   What|Removed |Added

 CC||phython at gcc dot gnu dot
   ||org


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