[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-10-26 06:45 
---
Subject: Re:  [4.0 Regression] 24% C++ compile-time regression
 in comparison with 3.4.1 at -O1 optimization level

 Hi,

I have tested -fno-threadsafe-statics now and it does not affect so much,
IMHO:

$ c++  -I../include  -time -O0 -Wall   -DPIC -fPIC  -c ir.cc -o ir.pic.o
# cc1plus 68.57 2.26
# as 5.92 0.27

$ c++  -I../include  -fno-threadsafe-statics -time -O0 -Wall   -DPIC -fPIC  -c ir.cc 
-o ir.pic.o
# cc1plus 67.94 2.04
# as 5.86 0.26

Cheers,
Karel



-- 


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

[Bug middle-end/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-26 04:35 
---
Here is it reduced further, maybe now someone will look into it now (I can reproduce 
it with -O2 -fno-
pcc-struct-return on i686-pc-linux-gnu):
struct cset_converter { int func; int cd; };
void abort(void);
struct cset_converter
init_iconv_desc (int i)
{
  struct cset_converter ret;
  unsigned i1;
  char *pair;
  if (!i)
{
  ret.func = 0;
  ret.cd = 0;
  return ret;
}
  ret.func = 2;
  ret.cd = 2;
  return ret;
}
struct f
{
  struct cset_converter a;
  struct cset_converter b;
};
void ff(struct f *a)
{
  a->a = init_iconv_desc(0);
  a->b = init_iconv_desc(1);
}
int main(void)
{
  struct f a;
  ff (&a);
  if (a.a.func!=0 || a.a.cd !=0)
abort();
  if (a.b.func!=2 || a.b.cd !=1)
abort();
  return 0;
}

-- 


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-26 04:28 
---
Subject: Re:  ICE cause by reload 

I found a typo in my sourcebase introduced when applying one of
the patches.  Fixing that typo (matching the complete patch attached to
the PR) produces the correct offset.

I think the patch is the correct change to get reload to behave
correctly.


-- 


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

[Bug target/18154] Inefficient max/min code for PowerPC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-26 04:25 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-26 04:25:17
   date||


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

[Bug middle-end/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-26 04:23 
---
And here is a semi reduced/self-contained source which I came up after debuggin this a 
little bit:
struct cset_converter { int func; int cd; };
void abort(void); int puts(const char*);
int f(int i){return i;}
void g(void){puts("hi");}
struct conversion
{
  int pair;
  int func;
  int fake_cd;
};
static const struct conversion conversion_tab[] = {
  { 2, 2, 2 },
  { 3, 3, 3 }
};
static struct cset_converter
init_iconv_desc (int i)
{
  struct cset_converter ret;
  unsigned i1;
  char *pair;
  if (!i)
{
  ret.func = 0;
  ret.cd = 0;
  return ret;
}
  pair = __builtin_alloca(i*3);
  for (i1 = 0; i1 < (sizeof (conversion_tab) / sizeof ((conversion_tab)[0])); i1++)
if (i == conversion_tab[i1].pair)
  {
 ret.func = conversion_tab[i1].func;
 ret.cd = conversion_tab[i1].fake_cd;
 return ret;
  }

  ret.func = 2;
  ret.cd = f(i);
  if (ret.cd == 4)
{
  g();
  ret.func = 4;
}
  return ret;
}
struct f
{
  struct cset_converter a;
  struct cset_converter b;
};

void ff(struct f *a)
{
  a->a = init_iconv_desc(0);
  a->b = init_iconv_desc(1);
}

int main(void)
{
  struct f a;
  ff (&a);
  if (a.a.func!=0 || a.a.cd !=0)
abort();
  if (a.b.func!=2 || a.b.cd !=1)
abort();
  return 0;
}


-- 
   What|Removed |Added

  Component|regression  |middle-end


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

[Bug target/18154] New: Inefficient max/min code for PowerPC

[dje at gcc dot gnu dot org]

int min(int a, int b) {
  if (a < b)
return a;
  else
return b;
}

should produce

rlwinm  r2,r3,1,31,31
subfc   r0,r4,r3
rlwinm  r0,r4,1,31,31
subfe   r0,r2,r0
andcr2,r4,r0
and r0,r3,r0
or  r3,r0,r2
blr

but instead produces a branch sequence

 mr r0,r3
 mr r3,r4
 cmpw cr7,r0,r4
 bgelr- cr7
 mr r3,r0
 blr

with unnecessary dependencies.

-- 
   Summary: Inefficient max/min code for PowerPC
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: powerpc-*-*
GCC target triplet: *-*-*


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

[Bug regression/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-26 03:13 
---
It looks like init_iconv_desc is miscompiled.

-- 


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

[Bug regression/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-26 02:48 
---
Thanks  Danny for looking into what causes correct code, I will look into it soon 
(after I build a new 
cross compiler from powerpc-darwin).

-- 
   What|Removed |Added

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


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

[Bug regression/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-10-26 02:26 ---
A data point:

Free/OpenBsd and windows targets differ drom i386-linux in defining
#define DEFAULT_PCC_STRUCT_RETURN 0
which affect aggregate_value_p and thus gimplify_return_expr.  

Compiling charset.c with -O2 -funit-at-a-time -fpcc-struct-return on mingw
builds a "good" cc1.exe

Danny



-- 


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

[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-10-26 01:07 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02141.html

-- 


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

[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-26 00:49 
---
Your self caused this regression.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hjl at lucon dot org
   |dot org |
   Severity|normal  |critical
 Status|UNCONFIRMED |ASSIGNED
  Component|driver  |target
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-26 00:49:47
   date||
Summary|-static-libgcc links in |[3.4/4.0 Regression] -
   |libunwind.so.7  |static-libgcc links in
   ||libunwind.so.7
   Target Milestone|--- |3.4.3


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

[Bug driver/18153] New: -static-libgcc links in libunwind.so.7

[hjl at lucon dot org]

-static-libgcc links in libunwind.so.7 even if it isn't used at all:

[EMAIL PROTECTED] tmp]$ cat f.c
int
main ()
{
  return 0;
}
[EMAIL PROTECTED] tmp]$ /usr/gcc-3.4/bin/gcc -static-libgcc f.c
[EMAIL PROTECTED] tmp]$ ./a.out
./a.out: error while loading shared libraries: libunwind.so.7: cannot open 
shared object file: No such file or directory

-- 
   Summary: -static-libgcc links in libunwind.so.7
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-26 00:13 
---
Subject: Re:  ICE cause by reload 

There is a reduced testcase attached to the Bugzilla PR.  Please
do not confuse discussion with other examples.



-- 


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

[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)

[wilson at tuliptree dot org]

--- Additional Comments From wilson at tuliptree dot org  2004-10-26 00:06 ---
Subject: Re:  bad unwind info due to multiple returns
(missing epilogue)

On Thu, 2004-10-21 at 11:03, davidm at hpl dot hp dot com wrote:
> OK, I tried this patch on the CVS gcc-3_4_branch (the 4.0 branch didn't work at
> all for me, even in it's pristine version).
> I'm not sure the g++ failures are real: if I try and cut & past one of the
> failing commands myself, it works just fine.  For example, one of the failures is:

I have started some builds to try to test the patch.  You didn't say
what kind of problems you ran into with gcc mainline.  There are a few
known problems such as linking problems if you don't have the libunwind
package installed, but that shouldn't be an issue here.  I haven't done
an IA-64 bootstrap in a while.  I will find out soon enough.



-- 


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

[Bug target/15286] ICE cause by reload

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-10-25 23:58 ---
I tried the last patch and for the following statement built with -O2 -mcpu=G5 
(aaple's mixed mode)
I get the following instruction sequence. It looks OK to me. But David's case might be 
different
than what I am looking at:


clock_start=(((double)clock())/((double)(100)));


bl L_clock$stub
rldicl r3,r3,0,32
lha r0,232(r29)
addis r2,r31,ha16(LC40-"L008$pb")
std r3,456(r1)
lfd f12,lo16(LC40-"L008$pb")(r2)
cmpwi cr7,r0,0
nop
lfd f13,456(r1)
fcfid f0,f13
fdiv f0,f0,f12
fctidz f0,f0
stfd f0,528(r1)
nop
nop
nop
ld r19,528(r1)
ble cr7,L147
 ...

ti+=double)clock())/((double)(100)))-clock_start);

L186:
bl L_clock$stub
rldicl r3,r3,0,32
rldicl r2,r19,0,32
std r3,464(r1)
std r2,472(r1)
addis r2,r31,ha16(LC40-"L008$pb")
lfd f0,464(r1)
lfd f13,472(r1)
lwz r0,816(r30)
cmpwi cr7,r0,0
fcfid f12,f0
lfd f0,lo16(LC40-"L008$pb")(r2)
fcfid f11,f13
addis r2,r31,ha16(LC39-"L008$pb")
fdiv f12,f12,f0
lfd f0,lo16(LC39-"L008$pb")(r2)
fsub f12,f12,f11
...



-- 


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

[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)

[wilson at tuliptree dot org]

--- Additional Comments From wilson at tuliptree dot org  2004-10-25 23:54 ---
Subject: Re:  bad unwind info due to multiple returns
(missing epilogue)

On Fri, 2004-10-22 at 03:57, davidm at hpl dot hp dot com wrote:
>  It looks to
> me as if "expect" sometimes fails to notice the (failure-free) termination of
> the compiler and that leads to subsequent and spurious test-suite failures. 
> I'll see if this is a bug in "expect".

Yes, there are some known problems with some versions of expect,
particularly on 64-bit machines.  I haven't seen any such problems on my
IA-64 debian linux machine though, at least, not that I have noticed. 
Most of the testsuite problems I have had have been load related.  If
the load average changes while running the testsuite, this can cause
tests which are close to the timeout to be over/under depending on the
load.  Also, some java tests are self-timing, and can fail if the load
changes unexpected while they are running.

I think it was HJ that wrote the patch to fix the expect problem.



-- 


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-25 23:43 
---
Subject: Re:  ICE cause by reload 

Try again with what patch?  I have all patches applied and I
consistently get the output I emailed earlier with a native Mac OS X
compiler. 

David


-- 


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

[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[pinskia at gcc dot gnu dot org]

-- 
Bug 17278 depends on bug 17707, which changed state.

Bug 17707 Summary: [4.0 Regression] O(N^2) in cgraph_reset_static_var_maps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17707

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/15678] [4.0 Regression] Compilation time increased by 10-20%

[pinskia at gcc dot gnu dot org]

-- 
Bug 15678 depends on bug 17707, which changed state.

Bug 17707 Summary: [4.0 Regression] O(N^2) in cgraph_reset_static_var_maps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17707

   What|Old Value   |New Value

 Status|UNCONFIRMED |NEW
 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/17707] [4.0 Regression] O(N^2) in cgraph_reset_static_var_maps

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 23:22 
---
The code has been removed for 4.0.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/16667] GCC allows invalid syntax in C99 designated initializers

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 22:25 
---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug c/16667] GCC allows invalid syntax in C99 designated initializers

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-25 22:23 
---
Subject: Bug 16667

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-25 22:23:08

Modified files:
gcc: ChangeLog c-parse.in 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: init-desig-obs-1.c init-desig-obs-2.c 
  init-desig-obs-3.c 

Log message:
PR c/16667
* c-parse.in (array_designator): New.
(designator): Use it.
(initelt): Only permit array_designator without '=', not ".foo".

testsuite:
* gcc.dg/init-desig-obs-1.c, gcc.dg/init-desig-obs-2.c,
gcc.dg/init-desig-obs-3.c: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6014&r2=2.6015
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parse.in.diff?cvsroot=gcc&r1=1.250&r2=1.251
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4494&r2=1.4495
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/init-desig-obs-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/init-desig-obs-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/init-desig-obs-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/18152] corrupted profile info after optimized compilation and --fprofile-use

[joc at presence-pc dot com]

--- Additional Comments From joc at presence-pc dot com  2004-10-25 22:03 ---
Note also that occurs when trying to compile MySQL with -fprofile-use flag, and
several other files are affected by the problem (but now all the files).

For example, an other error during compilation :

[EMAIL PROTECTED] /usr/local/mysql-4.1/innobase/page> gcc -DHAVE_CONFIG_H -I. -I.
-I.. -I./../include -I./../../include -I../../include-DDBUG_OFF -O3
-DDBUG_OFF -mtune=athlon-mp -march=athlon-mp -fprofile-use -DDEBUG_OFF
-DUNIV_LINUX -DUNIV_INTEL_X86 -MT page0page.o -MD -MP -MF ".deps/page0page.Tpo"
-c -o page0page.o page0page.c; 
page0page.c: In function `page_rec_get_n_recs_before':
page0page.c:1112: error: corrupted profile info: number of executions for edge
1-2 thought to be -1
page0page.c:1112: error: corrupted profile info: number of executions for edge
1-11 thought to be 1497932
page0page.c:1112: error: corrupted profile info: number of iterations for basic
block 2 thought to be -1
page0page.c:1112: error: corrupted profile info: number of executions for edge
16-17 thought to be -3
page0page.c:1112: error: corrupted profile info: number of executions for edge
16-26 thought to be 107993545

When removing the -mtune / -march flags :

[EMAIL PROTECTED] /usr/local/mysql-4.1/innobase/page> gcc -DHAVE_CONFIG_H -I. -I.
-I.. -I./../include -I./../../include -I../../include-DDBUG_OFF -O3
-DDBUG_OFF  -fprofile-use -DDEBUG_OFF -DUNIV_LINUX -DUNIV_INTEL_X86 -MT
page0page.o -MD -MP -MF ".deps/page0page.Tpo" -c -o page0page.o page0page.c;
page0page.c: In function `page_delete_rec_list_end':
page0page.c:700: error: coverage mismatch for function
'page_delete_rec_list_end' while reading counter 'arcs'.
page0page.c:700: error: number of counters is 250 instead of 251

When removing the -O3 flag, a lot of "warning: no coverage for function
'function_name' found", but no more compilation errors.

-- 


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

[Bug middle-end/18152] corrupted profile info after optimized compilation and --fprofile-use

[joc at presence-pc dot com]

--- Additional Comments From joc at presence-pc dot com  2004-10-25 21:56 ---
The file has been compiled with 

gcc -DHAVE_CONFIG_H -I. -O3 -DDBUG_OFF -Wimplicit -Wreturn-type -Wswitch
-Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare
-Wwrite-strings -Wunused -mtune=athlon-mp -march=athlon-mp -mfpmath=sse -mmmx
-msse -m3dnow -O3 -fomit-frame-pointer -fmove-all-movables -freduce-all-givs
-frename-registers -fprofile-generate -fbranch-target-load-optimize2   -MT
ctype-latin1.o -MD -MP -MF ".deps/ctype-latin1.Tpo" -c -o ctype-latin1.o
ctype-latin1.c

command line

-- 


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

[Bug middle-end/18152] corrupted profile info after optimized compilation and --fprofile-use

[joc at presence-pc dot com]

--- Additional Comments From joc at presence-pc dot com  2004-10-25 21:53 ---
Created an attachment (id=7409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7409&action=view)
c/h files and gcda file to reproduce -fprofile-use bug


-- 


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

[Bug middle-end/18152] corrupted profile info after optimized compilation and --fprofile-use

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 21:52 
---
How did you compile the one which you are profiling?

-- 
   What|Removed |Added

  Component|c   |middle-end


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

[Bug c/18152] New: corrupted profile info after optimized compilation and --fprofile-use

[joc at presence-pc dot com]

Hi,

When trying to compile a file compiled with optimized flag, I got the following
error :


gcc -DHAVE_CONFIG_H -I.-O3 -DDBUG_OFF -Wimplicit -Wreturn-type -Wswitch
-Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare
-Wwrite-strings -Wunused -mtune=athlon-mp -march=athlon-mp -mfpmath=sse -mmmx
-msse -m3dnow -O3 -fomit-frame-pointer -fmove-all-movables -freduce-all-givs
-frename-registers -fprofile-use -fbranch-target-load-optimize2   -MT
ctype-latin1.o -MD -MP -MF ".deps/ctype-latin1.Tpo" -c -o ctype-latin1.o
ctype-latin1.c;
ctype-latin1.c: In function `my_mb_wc_latin1':
ctype-latin1.c:363: error: corrupted profile info: number of executions for edge
3-4 thought to be 13
ctype-latin1.c:363: error: corrupted profile info: number of executions for edge
3-5 thought to be -12

However if I compile the file without the -O3 flag, it only issues warning :

gcc -DHAVE_CONFIG_H -I.-DDBUG_OFF -Wimplicit -Wreturn-type -Wswitch
-Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare
-Wwrite-strings -Wunused -mtune=athlon-mp -march=athlon-mp -mfpmath=sse -mmmx
-msse -m3dnow -fomit-frame-pointer -fmove-all-movables -freduce-all-givs
-frename-registers -fprofile-use -fbranch-target-load-optimize2   -MT
ctype-latin1.o -MD -MP -MF ".deps/ctype-latin1.Tpo" -c -o ctype-latin1.o
ctype-latin1.c;
ctype-latin1.c: In function `my_mb_wc_latin1':
ctype-latin1.c:363: warning: no coverage for function 'my_mb_wc_latin1' found.
ctype-latin1.c: In function `my_wc_mb_latin1':
ctype-latin1.c:379: warning: no coverage for function 'my_wc_mb_latin1' found.
ctype-latin1.c: In function `my_strnncoll_latin1_de':
ctype-latin1.c:570: warning: no coverage for function 'my_strnncoll_latin1_de'
found.
ctype-latin1.c: In function `my_strnncollsp_latin1_de':
ctype-latin1.c:633: warning: no coverage for function 'my_strnncollsp_latin1_de'
found.
ctype-latin1.c: In function `my_strnxfrm_latin1_de':
ctype-latin1.c:651: warning: no coverage for function 'my_strnxfrm_latin1_de' found.
ctype-latin1.c: In function `my_hash_sort_latin1_de':
ctype-latin1.c:677: warning: no coverage for function 'my_hash_sort_latin1_de'
found.

So it seems something is wrong with profile-generate / profile-use in this case.

I'm uploading the c, gcda and h files to reproduce the problem with profile-use.

Thanks,
  Jocelyn

-- 
   Summary: corrupted profile info after optimized compilation and -
-fprofile-use
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joc at presence-pc dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/18002] [4.0/3.4 Regression] 'while' loop performace regression on avr target

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 21:42 
---
Oh, it looks like the powerpc bug was different from the avr one and for the avr bug 
it looks like a 
target problem and nothing else, the rtl looks small.

-- 
   What|Removed |Added

  Component|rtl-optimization|target
Summary|[3.4 Regression] 'while'|[4.0/3.4 Regression] 'while'
   |loop performace regression  |loop performace regression
   |on avr target   |on avr target


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

[Bug target/15286] ICE cause by reload

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-10-25 21:14 ---
By mistake, I applied the test for !reload_completed  to you earlier patch (which was 
worng). 
In any case,
after correcting the patch and with your latest patch, all my test cases passed. Now, 
I need
to do a complete bootstrap with -mcpu=G5 on apple-ppc-darwin and will let you know
how it goes. Thanks.

-- 


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-25 21:11 
---
Subject: Re:  ICE cause by reload 

With the earlier *two* patches from Ulrich, the compiler no longer
ICE. 

The latest patch to alter_subreg() (with the missing GET_MODEs)
does not fix the subreg offset problem for me.

bl L_clock$stub
std r3,168(r1)
lfd f0,168(r1)
fcfid f0,f0
stfd f0,224(r1)
fctidz f0,f0
stfd f0,204(r1)   <---
...
bl L_clock$stub
lwz r0,204(r1)<---
std r3,168(r1)
std r0,176(r1)
lfd f13,168(r1)
lfd f0,176(r1)
fcfid f12,f0
fcfid f0,f13
fsub f0,f0,f12
fctiwz f13,f0
stfd f13,184(r1)
lwz r3,188(r1)

The code continues to access the wrong word.


-- 


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

[Bug rtl-optimization/15242] pessimization of "goto *"

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-25 21:10 
---
I have a patch that fixes this.  I need to figure out a way to do it in a way 
that doesn't require you to pass "-fno-crossjumping -fno-gcse" but I'll figure 
out something... 
 
 

-- 
   What|Removed |Added

 AssignedTo|zlomek at gcc dot gnu dot   |steven at gcc dot gnu dot
   |org |org


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

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-25 21:04 
---
well, as pointed out by David you do need in addition the change I 
described in comment #20.

If you prefer a patch:

Index: gcc/recog.c
===
RCS file: /cvs/gcc/gcc/gcc/recog.c,v
retrieving revision 1.211
diff -c -p -r1.211 recog.c
*** gcc/recog.c 28 Sep 2004 07:59:48 -  1.211
--- gcc/recog.c 25 Oct 2004 21:02:03 -
*** general_operand (rtx op, enum machine_mo
*** 937,943 
  #ifdef INSN_SCHEDULING
/* On machines that have insn scheduling, we want all memory
 reference to be explicit, so outlaw paradoxical SUBREGs.  */
!   if (MEM_P (sub)
  && GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (sub)))
return 0;
  #endif
--- 937,943 
  #ifdef INSN_SCHEDULING
/* On machines that have insn scheduling, we want all memory
 reference to be explicit, so outlaw paradoxical SUBREGs.  */
!   if (!reload_completed && MEM_P (sub)
  && GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (sub)))
return 0;
  #endif


-- 


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

[Bug target/15286] ICE cause by reload

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-10-25 20:58 ---
You need to replace GET_MODE_SIZE (x) with GET_MODE_SIZE (GET_MODE (x)), etc. for a 
clean
compile. But as I mentioned in last comment, I still get the ICE with or without this 
patch (along
with the previous patch) in all the test cases that I tried.


-- 


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

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-25 20:42 
---
(My last message got messed up somehow, I'm trying again.)

David Edelsohn wrote: 
 
>Correction.  While the reload changes fix the crash, it looks like there still  
>is a bug because the resulting code does not access the correct SUBREG.  It  
>does not access the LSW. 
 
That would be because alter_subreg doesn't handle paradoxical subregs 
on big-endian machines correctly.  Something like the following (untested) 
should fix that one: 
 
Index: gcc/final.c 
=== 
RCS file: /cvs/gcc/gcc/gcc/final.c,v 
retrieving revision 1.339 
diff -c -p -r1.339 final.c 
*** gcc/final.c 22 Oct 2004 17:05:05 -  1.339 
--- gcc/final.c 25 Oct 2004 20:35:41 - 
*** alter_subreg (rtx *xp) 
*** 2607,2613  
/* simplify_subreg does not remove subreg from volatile references. 
   We are required to.  */ 
if (MEM_P (y)) 
! *xp = adjust_address (y, GET_MODE (x), SUBREG_BYTE (x)); 
else 
  { 
rtx new = simplify_subreg (GET_MODE (x), y, GET_MODE (y), 
--- 2607,2628  
/* simplify_subreg does not remove subreg from volatile references. 
   We are required to.  */ 
if (MEM_P (y)) 
! { 
!   int offset = SUBREG_BYTE (x); 
! 
!   /* For paradoxical subregs on big-endian machines, SUBREG_BYTE 
!contains 0 instead of the proper offset.  See simplify_subreg.  */ 
!   if (offset == 0 && GET_MODE_SIZE (y) < GET_MODE_SIZE (x)) 
! { 
!   int difference = GET_MODE_SIZE (y) - GET_MODE_SIZE (x); 
!   if (WORDS_BIG_ENDIAN) 
! offset += (difference / UNITS_PER_WORD) * UNITS_PER_WORD; 
!   if (BYTES_BIG_ENDIAN) 
! offset += difference % UNITS_PER_WORD; 
! } 
! 
!   *xp = adjust_address (y, GET_MODE (x), offset); 
! } 
else 
  { 
rtx new = simplify_subreg (GET_MODE (x), y, GET_MODE (y), 
 
 

-- 


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

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-25 20:38 
---
David Edelsohn wrote:  >Correction.  While the reload changes fix the crash, it looks 
like there still  >is a bug because the resulting code does not access the correct 
SUBREG.  It  >does not access the LSW.  That would be because alter_subreg doesn't 
handle paradoxical subregs on big-endian machines correctly.  Something like the 
following (untested) should fix that one:  Index: gcc/final.c 
=== RCS file: 
/cvs/gcc/gcc/gcc/final.c,v retrieving revision 1.339 diff -c -p -r1.339 final.c *** 
gcc/final.c 22 Oct 2004 17:05:05 -  1.339 --- gcc/final.c 25 Oct 2004 20:35:41 
- *** alter_subreg (rtx *xp) *** 2607,2613  /* simplify_subreg 
does not remove subreg from volatile references.We are required to.  */ if 
(MEM_P (y)) ! *xp = adjust_address (y, GET_MODE (x), SUBREG_BYTE (x)); else
   { rtx new = simplify_subreg (GET_MODE (x), y, GET_MODE (y), --- 2607,2628 
 /* simplify_subreg does not remove subreg from volatile references.We 
are required to.  */ if (MEM_P (y)) ! { !   int offset = SUBREG_BYTE (x); 
! !   /* For paradoxical subregs on big-endian machines, SUBREG_BYTE !
contains 0 instead of the proper offset.  See simplify_subreg.  */ !   if (offset 
== 0 && GET_MODE_SIZE (y) < GET_MODE_SIZE (x)) ! { !   int difference 
= GET_MODE_SIZE (y) - GET_MODE_SIZE (x); !   if (WORDS_BIG_ENDIAN) !   
  offset += (difference / UNITS_PER_WORD) * UNITS_PER_WORD; !   if 
(BYTES_BIG_ENDIAN) ! offset += difference % UNITS_PER_WORD; ! } ! 
!   *xp = adjust_address (y, GET_MODE (x), offset); ! } else   {   
  rtx new = simplify_subreg (GET_MODE (x), y, GET_MODE (y),   

-- 


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

[Bug target/18151] Disable building of fixincludes for avr target.

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2004-10-25 20:33 ---
I've added the AVR mainters to the CC list of this bug.

Would one of the AVR maintainers (Denis, Marek) be willing to approve such a
change since this is a new feature?

Thanks
Eric

-- 


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

[Bug target/18151] Disable building of fixincludes for avr target.

[ericw at evcohs dot com]

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/18151] Disable building of fixincludes for avr target.

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||marekm at amelek dot gda dot
   ||pl


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

[Bug target/18151] Disable building of fixincludes for avr target.

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||denisc at overta dot ru


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

[Bug target/18151] New: Disable building of fixincludes for avr target.

[ericw at evcohs dot com]

Building and running fixincludes for the avr target is not necessary with the
current canonical toolset of binutils, gcc and avr-libc:


Building fixincludes currently fails for host=mingw32 host, which being
corrected with bug #17832. But building fixincludes for the avr target is
unnecessary to begin with.

A potential patch would follow the form found here: 


-- 
   Summary: Disable building of fixincludes for avr target.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ericw at evcohs dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr-*-*


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

[Bug c++/18150] Should enable -Wsequence-point for C++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 20:23 
---
Oh, I had forgot to commit the patch which removed the inaccurate part will do.

-- 


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

[Bug c++/18150] Should enable -Wsequence-point for C++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 20:21 
---
Actually only part of the documenation is needed to change see:
.

-- 
   What|Removed |Added

 AssignedTo|pinskia 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=18150

[Bug c++/18150] Should enable -Wsequence-point for C++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 20:19 
---
This is basically is already fixed on the mainline, the only thing left is left is 
documentation.

See PR 15145.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Keywords||documentation
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 20:19:25
   date||


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

[Bug c++/18150] New: Should enable -Wsequence-point for C++

[austern at apple dot com]

-Wsequence-point is documented to be C-only.  However, it would be just as useful for 
C++ as it is for 
C.  We should implement  -Wsequence-point for C++.

-- 
   Summary: Should enable -Wsequence-point for C++
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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

[Bug target/18149] [4.0 regression] bootstrap of i686-darwin

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug java/18148] gcj has wrong type for itable

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 20:06 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 20:06:57
   date||


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

[Bug regression/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 19:59 
---
I should note that it does not effect i686-pc-linux-gnu for some reason


-- 


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

[Bug regression/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 19:55 
---
I also note I can reproduce this when using the C compiler so it definitely has 
nothing to do with the 
C++ compiler.

-- 


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

[Bug c++/17526] [4.0 Regression] locale_facets.cc:47: internal compiler error

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2004-10-25 19:48 
---
I also don't think this is a C++ bug: its a bug in whatever compiled libcpp,
which probably wasn't a C++ compiler.

Also, does this affect all x86 targets?  Does it affect i?86-pc-linux*?

The testcase can be simplified; parsing any wide character literal with the
miscompiled libcpp will cause the ICE, such as simply L'c'.


-- 
   What|Removed |Added

 GCC target triplet|i386-freebsd5.1, i?86-  |i386-freebsd5.1, i?86-
   |openbsd3.1  |openbsd3.1, i?86-pc-mingw32


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

[Bug target/18149] [4.0 regression] bootstrap of i686-darwin

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 19:40 
---
Confirmed, (here is the ironic part): it was caused by the patch which made cctools 
528.5 required:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html 

-- 
   What|Removed |Added

 CC||geoffk at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|bootstrap   |target
 Ever Confirmed||1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 19:40:02
   date||
Summary|bootstrap of gcc-4.0-   |[4.0 regression] bootstrap
   |20041024 on OpenDarwin  |of i686-darwin
   |7.2.1/x86 (i686-apple-  |
   |darwin7.2.1) failed |


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

[Bug bootstrap/18149] New: bootstrap of gcc-4.0-20041024 on OpenDarwin 7.2.1/x86 (i686-apple-darwin7.2.1) failed

[lars dot sonchocky-helldorf at hamburg dot de]

this is a regression since I was already able to bootstrap gcc-4.0 on OD 7.2.1/x86 
successfully:

http://gcc.gnu.org/ml/gcc/2004-09/msg00757.html

The procedure for bootstrapping was similar to the one described in the message above, 
the only 
difference is that I used 
http://www.opendarwin.org/downloads/odcctools-20041018.tar.bz2 which 
corresponds to cctools-528.5 (see: 
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html and 
http://www.opendarwin.org/pipermail/odcctools/2004-October/33.html )

stage1/xgcc -Bstage1/ -B/tmp/gcc/i686-apple-darwin7.2.1/bin/ -c   -O2 -g 
-fomit-frame-pointer -
DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-
long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common   -DHAVE_CONFIG_H 
   -I. -
I. -I../../gcc-4.0-20041024/gcc -I../../gcc-4.0-20041024/gcc/. 
-I../../gcc-4.0-20041024/gcc/../
include -I./../intl -I../../gcc-4.0-20041024/gcc/../libcpp/include  
../../gcc-4.0-20041024/gcc/c-
lang.c -o c-lang.o
In file included from ./tm.h:7,
 from ../../gcc-4.0-20041024/gcc/c-lang.c:26:
../../gcc-4.0-20041024/gcc/config/i386/darwin.h:47:1: error: "ASM_SPEC" redefined
In file included from ./tm.h:6,
 from ../../gcc-4.0-20041024/gcc/c-lang.c:26:
../../gcc-4.0-20041024/gcc/config/darwin.h:334:1: error: this is the location of the 
previous definition
make[2]: *** [c-lang.o] Error 1
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap] Error 2
localhost:~/GCC/FSF/gcc-build lars$

-- 
   Summary: bootstrap of gcc-4.0-20041024 on OpenDarwin 7.2.1/x86
(i686-apple-darwin7.2.1) failed
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lars dot sonchocky-helldorf at hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-apple-darwin7.2.1
  GCC host triplet: i686-apple-darwin7.2.1
GCC target triplet: i686-apple-darwin7.2.1


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

[Bug java/18148] New: gcj has wrong type for itable

[tromey at gcc dot gnu dot org]

gcj computes the type of the `itable' field of Class
differently from how the runtime declares this type.
This is confusing to the maintainer and potentially
fragile (depending on the vagaries of struct layout).
See http://gcc.gnu.org/ml/java-patches/2004-q4/msg00286.html

-- 
   Summary: gcj has wrong type for itable
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug target/15286] ICE cause by reload

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 19:14 
---
The second patch has to due with "However, cleanup_subreg_operands first recognizes 
the insn, and 
this is
where it presumably fails; due to this weird piece of code in general_operand:"

-- 


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

[Bug target/15286] ICE cause by reload

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-10-25 19:12 ---
You referred to them as 'both patches' in comment #21.

-- 


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-25 19:07 
---
Subject: Re:  ICE cause by reload 

> I applied the last two patch, but it didn;t help:

The simplify-rtx.c patch is not *two* patches.


-- 


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

[Bug java/18147] Objects in instance initializer blocks are scoped too widely

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2004-10-25 18:55 
---
As a workaround you can put an extra block inside the
instance initializers:

{{ Object foo = ... }}

The bug here seems to be that gcj chains the statements
of each initializer block together when making finit.
Instead, however, it should treat each as a separate
block and chain the blocks together.  That is, an
instance initializer block introduces a new scope.

-- 
   What|Removed |Added

   Keywords|rejects-valid   |


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

[Bug java/18147] Objects in instance initializer blocks are scoped too widely

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 18:49 
---
Confirmed, a workaround is to do something like this:
import java.util.HashMap;
class init
{
  {{
Object foo = new Object();}
  }
  {
Object foo = new Object();
  }
}

The reduced testcase:
import java.util.HashMap;
class init
{
  {
Object foo = new Object();
  }
  {
Object foo = new Object();
  }
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 18:49:33
   date||


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

[Bug java/18147] New: Objects in instance initializer blocks are scoped too widely

[csm at gnu dot org]

If you declare an object within an instance initializer, you cannot declare
another object of the same name in a different instance initializer.

This description seems pretty opaque, so an example of correct code that GCJ
rejects is probably better:

-- init.java --
import java.util.HashMap;
class init
{
  private final HashMap _map1 = new HashMap();
  {
Object foo = new Object();
_map1.put ("foo!", foo);
  }

  private final HashMap _map2 = new HashMap();
  {
Object foo = new Object();
_map2.put ("bar!", foo);
  }
}
-- init.java --

GCJ exits with this error:

init.java:13: error: Variable `foo' is already defined in this method and was
declared `Object foo' at line 7.
   Object foo = new Object();
  ^
1 error

-- 
   Summary: Objects in instance initializer blocks are scoped too
widely
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csm at gnu 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=18147

[Bug target/15286] ICE cause by reload

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-10-25 18:39 ---
I applied the last two patch, but it didn;t help:

% mygccf -O2 -mcpu=G5 -c loader_obj.i
loader_obj.c: In function 'load_obj':
loader_obj.c:92: error: unrecognizable insn:
(insn 1395 601 1396 50 (set (subreg:DI (mem:SI (plus:SI (reg/f:SI 1 r1)
(const_int 716 [0x2cc])) [0 allocednf+0 S4 A8]) 0)
(reg:DI 32 f0)) -1 (nil)
(nil))
loader_obj.c:92: internal compiler error: in extract_insn, at recog.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
See http://developer.apple.com/bugreporter> for instructions.

Just to be clear, this is the patch I applied.

Index: simplify-rtx.c
===

RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.107.2.31.2.9
diff -c -p -r1.107.2.31.2.9 simplify-rtx.c
*** simplify-rtx.c  16 Oct 2004 00:06:42 -  1.107.2.31.2.9
--- simplify-rtx.c  25 Oct 2004 18:38:20 -
*** simplify_gen_subreg (enum machine_mode o
*** 3800,3806 
if (newx)
  return newx;
  
!   if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
  return NULL_RTX;
  
return gen_rtx_SUBREG (outermode, op, byte);
--- 3800,3808 
if (newx)
  return newx;
  
!   if ((GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode
!|| (REG_P (op) && REGNO (op) < FIRST_PSEUDO_REGISTER))
!  && !reload_completed)
  return NULL_RTX;
  
return gen_rtx_SUBREG (outermode, op, byte);

-- 


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

[Bug target/15286] ICE cause by reload

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-10-25 18:33 ---
Correction.  While the reload changes fix the crash, it looks like there still 
is a bug because the resulting code does not access the correct SUBREG.  It 
does not access the LSW.

-- 


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-25 18:04 
---
Subject: Re:  ICE cause by reload 

With both patches, the testcase works.  This probably is a correct
fix for reload.

The code is a little messy and is cleaned up by implementing
fixuns_truncdfsi, which also fixes the testcase.

David


-- 


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

Re: ICE on g++ 3.3.2, 3.3.3, and 3.3.4

[Andrew Pinski]

The code reduces to:
struct QgsScaleCalculator
{
QgsScaleCalculator(int dpi = 0,
   QgsScaleCalculator mapUnits = 0);
};
struct CanvasProperties
{
CanvasProperties (): scaleCalculator (new QgsScaleCalculator) {}
  QgsScaleCalculator * scaleCalculator;
};
But this code is invalid and we should reject it.  This is PR 5247.
Thanks,
Andrew Pinski

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-25 17:17 
---
Well, as I understand it, SUBREG (MEM) is *supposed* to be generated
for the case of SUBREG (pseudo) where the pseudo gets a stack slot.

The scan_paradoxical_subregs mechanism was supposed to have allocated
a large enough stack slot, and cleanup_subreg_operands is then supposed
to convert the SUBREG (MEM) to a MEM with its address offset accordingly.

However, cleanup_subreg_operands first recognizes the insn, and this is
where it presumably fails; due to this weird piece of code in general_operand:

#ifdef INSN_SCHEDULING
  /* On machines that have insn scheduling, we want all memory
 reference to be explicit, so outlaw paradoxical SUBREGs.  */
  if (MEM_P (sub)
  && GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (sub)))
return 0;
#endif

(What the ... has INSN_SCHEDULING to do with what insns we want
to recognize?!)

Does it work if you add an && !reload_completed to that if?

-- 


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

[Bug target/18145] Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 17:03 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 17:03:19
   date||


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

[Bug rtl-optimization/18146] if-conversion is not performed for some reason

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 17:01 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 17:01:28
   date||


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

[Bug c++/18144] Use of parent's field in template classes

[guillaume dot lemaitre33 at wanadoo dot fr]

--- Additional Comments From guillaume dot lemaitre33 at wanadoo dot fr  
2004-10-25 16:54 ---
sorry for the annoyment

-- 


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

[Bug target/15286] ICE cause by reload

[dje at watson dot ibm dot com]

--- Additional Comments From dje at watson dot ibm dot com  2004-10-25 16:47 
---
Subject: Re:  ICE cause by reload 

> uweigand at gcc dot gnu dot org writes:

Ulrich> Does this patch help?

It changes the error, but I'm not sure if it helps.

pr15286.c: In function 'GMRESSolver':
pr15286.c:72: error: unrecognizable insn:
(insn 512 183 397 0 (set (subreg:DI (mem:SI (plus:SI (reg/f:SI 1 r1)
(const_int 204 [0xcc])) [15 clock_start+0 S4 A8]) 0)
(reg:DI 32 f0)) -1 (nil)
(nil))
pr15286.c:72: internal compiler error: in extract_insn, at recog.c:2034

It is storing to (SUBREG:DI (mem:SI)) instead of (mem:DI).



-- 


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

[Bug rtl-optimization/18146] New: if-conversion is not performed for some reason

[kazu at cs dot umass dot edu]

Consider:

int
foo (int a)
{
  switch (a)
{
case 1:
case 3:
case 5:
  return 1;
default:
  return 0;
}
}

./cc1 -O2 -fomit-frame-pointer -mregparm=3 -march=athlon-xp generates

foo:
cmpl$5, %eax
movl%eax, %ecx
ja  .L2
movl$1, %eax
movl$1, %edx
sall%cl, %eax
testb   $42, %al
jne .L4
.L2:
xorl%edx, %edx
.L4:
movl%edx, %eax
ret

Note that if-conversion is not performed at the end of this function.

-- 
   Summary: if-conversion is not performed for some reason
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/18145] New: Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty.

[ericw at evcohs dot com]

See FIXME in avr.c, function avr_file_start.

-- 
   Summary: Do not emit __do_copy_data or __do_clear_bss if .data or
.bss is empty.
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ericw at evcohs dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr-*-*


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

[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-25 16:34 
---
I think the brute-force approach of just updating 
current_function_has_computed_jump in a FOR_EACH_BB loop 
after calling make_edges is a "good enough" fix for this 
problem.  We can figure out if we have computed jumps at 
the tree level and keep it updated from there on. 
 
I'm testing a patch to do exactly this. 
 
 

-- 
   What|Removed |Added

   Last reconfirmed|2004-10-25 16:32:16 |2004-10-25 16:34:05
   date||


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

[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2004-10-25 16:31:39 |2004-10-25 16:32:16
   date||


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

[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 16:31 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 16:31:39
   date||


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

[Bug c++/18144] Use of parent's field in template classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 16:30 
---
Read the release notes.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/18144] New: Use of parent's field in template classes

[guillaume dot lemaitre33 at wanadoo dot fr]

The following code, that compiles well with 3.3.4, doesn't compile with 3.4.2,
complaining that "toto" hasn't been declared.

template< typename T >
class Miyeu
{
public:

  T* toto;
};

template< typename T >
class Fin : public Miyeu< T >
{
public:
  int taille;

protected:
  void allouer( int p_taille )
  {
if( p_taille > taille )
  {
delete[] toto;
toto = new T[p_taille];
taille = p_taille;
  }
  }
};

-- 
   Summary: Use of parent's field in template classes
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot lemaitre33 at wanadoo dot fr
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-25 16:20 
---
Does this patch help?

Index: gcc/simplify-rtx.c
===
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.206
diff -c -p -r1.206 simplify-rtx.c
*** gcc/simplify-rtx.c  18 Oct 2004 18:46:06 -  1.206
--- gcc/simplify-rtx.c  25 Oct 2004 16:17:42 -
*** simplify_gen_subreg (enum machine_mode o
*** 3789,3795 
if (newx)
  return newx;

!   if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
  return NULL_RTX;

return gen_rtx_SUBREG (outermode, op, byte);
--- 3789,3796 
if (newx)
  return newx;

!   if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode
!   || (REG_P (op) && REGNO (op) < FIRST_PSEUDO_REGISTER))
  return NULL_RTX;

return gen_rtx_SUBREG (outermode, op, byte);

-- 


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

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-25 15:54 
---
David Edelsohn wrote:

>One could view this problem as reload not obeying CANNOT_CHANGE_MODE_CLASS
>because it should not try to spill just the SImode SUBREG instead of creating a
>DImode temporary on the stack.  It needs to spill the entire result, not just
>the live portion.

Exactly, and that's what reload tries to do, at least initially.  Note that
push_reload checks CANNOT_CHANGE_MODE_CLASS, and correctly decides it needs
to reload in DImode.  That's why in the debug_reload output you see DImode
as the mode to perform the reload in.

Now, I haven't actually debugged this live; but from looking at the source
code what I assume is going wrong is the following:

Right at the end of reload, in gen_reload, there's this hunk of code:

  /* If IN is a paradoxical SUBREG, remove it and try to put the
 opposite SUBREG on OUT.  Likewise for a paradoxical SUBREG on OUT.  */
[snip]
  else if (GET_CODE (out) == SUBREG
   && (GET_MODE_SIZE (GET_MODE (out))
   > GET_MODE_SIZE (GET_MODE (SUBREG_REG (out
   && (tem = gen_lowpart_common (GET_MODE (SUBREG_REG (out)), in)) != 0)
out = SUBREG_REG (out), in = tem;

This is most likely where the DImode reload is replaced by the SImode one.

Now, this should not happen if the resulting SUBREG on the input side
gets invalid, as it does in the current situation.  

Here, gen_lowpart_common calls simplify_gen_subreg which calls
simplify_subreg.  This last function has code to verify using
CANNOT_CHANGE_MODE_CLASS that no invalid mode change is being encoded
into a SUBREG.  However, in *simplify_gen_subreg*, that decision is
subsequently simply ignored:

  newx = simplify_subreg (outermode, op, innermode, byte);
  if (newx)
return newx;

  if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
return NULL_RTX;

  return gen_rtx_SUBREG (outermode, op, byte);

Note how the SUBREG is generated anyway.  I'm not quite sure what the
point of this code is; but I'd suggest somewhere here is the place that
needs to get fixed ...


-- 


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

[Bug target/15286] ICE cause by reload

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-10-25 15:46 ---
GCC is using fix_truncdfdi2 because no unsfix_truncdfsi2 pattern is defined and
clock_t is an unsigned long.  A short-term workaround is to implement an
unsfix_truncdfsi2 pattern for PPC64 that uses fctid and explicitly moves the
value to a GPR.

However, reload should not be tripping over itself when faced with this.


-- 


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

[Bug rtl-optimization/18084] [3.4 regression]setfill coupled with inline function: incorrect results on Linux x86

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 14:56 
---
It also works in 3.3.3.


-- 
   What|Removed |Added

  Known to work|4.0.0   |4.0.0 3.3.3
Summary|[3.4 only]setfill coupled   |[3.4 regression]setfill
   |with inline function:   |coupled with inline
   |incorrect results on Linux  |function: incorrect results
   |x86 |on Linux x86


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

[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse because of the frame pointer

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-10-25 14:35 ---
The problem here is triggered in reload() function around line 950, this part
(#ifdef'd part was added by me:):

  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
if (reg_renumber[i] < 0 && reg_equiv_memory_loc[i])
  {
rtx x = eliminate_regs (reg_equiv_memory_loc[i], 0, NULL_RTX);

#ifdef DEBUG
debug_rtx(reg_equiv_memory_loc[i]);
debug_rtx(x);
#endif
if (strict_memory_address_p (GET_MODE (regno_reg_rtx[i]),
 XEXP (x, 0)))
  reg_equiv_mem[i] = x, reg_equiv_address[i] = 0;
  ...

For the testcase from comment #9 (converted to plain c), 'gcc -O2 -msse' will
produce relevant debug information:
IN:
(mem:V4SF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [6 S16 A8])
OUT:
(mem:V4SF (plus:SI (reg/f:SI 6 bp)
(const_int -56 [0xffc8])) [6 S16 A8])

So, the problem is inside eliminate_regs() function, that unaligns otherwise
aligned address. This unaligned address is passed down and somewhere around line
1214, following code will be triggered:

  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
{
  rtx addr = 0;

  if (reg_equiv_mem[i])
addr = XEXP (reg_equiv_mem[i], 0);
  ...

and this addr is used as new (unaligned) address on stack.

To further analyze this issue: following RTX is passed to eliminate_regs():
(mem:V4SF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [6 S16 A8])

After getting through MEM: case, function recurses to PLUS: case, where
following RTX is processed:
plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0]))

and this code is triggered:
  ...
else
  return gen_rtx_PLUS (Pmode, ep->to_rtx,
   plus_constant (XEXP (x, 1),
  ep->previous_offset));

where ep->previous_offset (when substituting frame pointer with ebp) equals
(-24). And the resulting sum is then -56. 

I'm a little lost here, what previous_offset field represents, perhaps someone
with more knowledge could find, if magic number (-24) is OK [it is not!].

BTW: the testcase from comment #9 when -fomit-frame-pointer is added to
compilation flags produces correctly aligned address, because 
ep->previous_offset, when substituting frame pointer with esp, equals to 64.
-32 + 64 = 32 in this case.

Regarding comment #17: Perhaps original testcase still uses ebp, even with
'-fomit-frame-pointer'.

Uros.

-- 


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

[Bug rtl-optimization/18084] [3.4 only]setfill coupled with inline function: incorrect results on Linux x86

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-25 14:24 ---
Here is a short testcase: 
-- 
struct X { 
bool init; 
void foo() { if (!init) init = true; } 
void bar() { foo();  } 
 
}; 
 
typedef unsigned long long int uint64_t; 
uint64_t mask1, mask2; 
 
uint64_t calc() { 
  return mask1 & mask2; 
} 
 
int main() 
{ 
  mask1 = 0xull; 
  mask2 = 0xull; 
  uint64_t value = calc(); 
 
  X().bar(); 
 
  if(value != calc()) 
abort (); 
} 
-- 
g/x> /home/bangerth/bin/gcc-3.4.3-pre/bin/c++ y.cc && ./a.out 
 
g/x> /home/bangerth/bin/gcc-3.4.3-pre/bin/c++ -O3 y.cc && ./a.out 
Aborted 
 
g/x> /home/bangerth/bin/gcc-3.3.4-pre/bin/c++ -O3 y.cc && ./a.out 
 
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -O3 y.cc && ./a.out 
 
Thus, the problem is confined to the 3.4 branch (which does not mean, 
of course, that the bug isn't latent on mainline as well). 
 
W. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 14:24:46
   date||


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

[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 14:07 
---
For ir.cc, does -fno-threadsafe-statics help if so this is a non bug (in that c++ 
front-end has changed 
to output more functions so what does the middle-end/back-end expect but slower 
compile time for 
those components).

-- 


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

[Bug libstdc++/13537] std::deque Is Not Conformant

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-25 14:03 ---
*** Bug 18080 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||ron at vaniwaarden dot org


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

[Bug libstdc++/18080] STL deque push_front, pop_front, push_back, and pop_back not O(1)

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-25 14:03 ---
There is agreement among library maintainers that the analysis in libstdc++/13537
(Comment #3) is correct. See also http://tinyurl.com/52oro

   

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

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/17407] [4.0 Regression] ICE in int_mode_for_mode

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 13:28 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/18121] [4.0 regression] ICE with array type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 13:28 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/18121] [4.0 regression] ICE with array type

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-25 13:27 
---
Subject: Bug 18121

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-25 13:27:33

Modified files:
gcc: ChangeLog c-decl.c tree.c 
gcc/cp : ChangeLog decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: array8.C 
gcc/testsuite/gcc.c-torture/compile: pr17407.c 

Log message:
2004-10-25  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/17407
* c-decl.c (grokdeclarator) : Remove the call
layout_type as it is already done by build_array_type.
* tree.c (build_array_type): Layout the type even

2004-10-25  Andrew Pinski  <[EMAIL PROTECTED]>

PR c++/18121
* decl.c (grokdeclarator) : Remove the call
layout_type as it is already done by create_array_type_for_decl.

2004-10-25  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/17407
* gcc.c-torture/compile/pr17407.c: New test.

PR c++/18121
* g++.dg/template/array8.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6006&r2=2.6007
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.603&r2=1.604
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.439&r2=1.440
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4452&r2=1.4453
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1317&r2=1.1318
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4492&r2=1.4493
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array8.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr17407.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/17407] [4.0 Regression] ICE in int_mode_for_mode

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-25 13:27 
---
Subject: Bug 17407

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-25 13:27:33

Modified files:
gcc: ChangeLog c-decl.c tree.c 
gcc/cp : ChangeLog decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: array8.C 
gcc/testsuite/gcc.c-torture/compile: pr17407.c 

Log message:
2004-10-25  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/17407
* c-decl.c (grokdeclarator) : Remove the call
layout_type as it is already done by build_array_type.
* tree.c (build_array_type): Layout the type even

2004-10-25  Andrew Pinski  <[EMAIL PROTECTED]>

PR c++/18121
* decl.c (grokdeclarator) : Remove the call
layout_type as it is already done by create_array_type_for_decl.

2004-10-25  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/17407
* gcc.c-torture/compile/pr17407.c: New test.

PR c++/18121
* g++.dg/template/array8.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6006&r2=2.6007
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.603&r2=1.604
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.439&r2=1.440
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4452&r2=1.4453
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1317&r2=1.1318
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4492&r2=1.4493
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array8.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr17407.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug bootstrap/18142] "Unknown pseudo-op: .machine" compiling darwin-crt2.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 13:21 
---
It was reverted because it made a cross compiler to powerpc-darwin imposiable if you 
only wantted a 
cc1 and not a full fledge compiler (which is useful when debuging bugs).

-- 


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

[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-10-25 13:20 
---
Subject: Re:  [4.0 Regression] [tree-ssa] Many
 C++ compile-time regression in 4.0-tree-ssa 040120


Updated table with GCC 3.4.2 and 4.0.0-041024 results is available here:
http://gcc.gnu.org/ml/gcc/2004-10/msg00952.html -- still some regressions
mainly on -O1 and -O2.

Cheers,
Karel



-- 


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

[Bug c++/18143] [4.0 Regression] Duplicated thunk with a huge member in the hierarchy

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 13:20 
---
I get an ICE on the mainline without disabling checking:
pr18143.cc:20: internal compiler error: in make_thunk, at cp/method.c:127
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

This used to work correctly in 3.4 so this is a regression.

: Search converges between 2004-09-30-014001-trunk (#569) and 2004-10-01-014001-trunk 
(#570).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-checking, ice-on-valid-
   ||code, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-10-25 13:20:18
   date||
Summary|Duplicated thunk with a huge|[4.0 Regression] Duplicated
   |member in the hierarchy |thunk with a huge member in
   ||the hierarchy
   Target Milestone|--- |4.0.0


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

[Bug bootstrap/18142] "Unknown pseudo-op: .machine" compiling darwin-crt2.c

[bothner at gcc dot gnu dot org]

--- Additional Comments From bothner at gcc dot gnu dot org  2004-10-25 13:18 
---
I think this should remain open as long as we don't have a configure-time check
to warn about an invalid assembler.  Otherwise the support burden will be
intolerable.  Kelley's configure patch to check the assembler was reverted on
Oct 20 (I missed why); we clearly need *something*.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-10-25 13:12 
---
Subject: Re:  [4.0 Regression] 24% C++ compile-time regression
 in comparison with 3.4.1 at -O1 optimization level


Please have a look into http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
for preprocessed ir.cc file for your experiments.

Cheers,
Karel



-- 


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

[Bug c++/18143] New: Duplicated thunk with a huge member in the hierarchy

[grigory dot zagorodnev at intel dot com]

For the code listed below, GCC 4.0 (20041010) emits duplicated virtual 
destructor thunk, so assembler fails to compile.

The size of c3::m member does matter there - test fails with magic value 
0x3fffd or above and passes with any value below.

$ cat go.cpp 
struct c0 {
virtual void foo(){};
};
 
struct c1 {
virtual ~c1(){};
};
 
struct c2 : virtual c1 { };
 
struct c3 {
  char m[0x3fffd];
};
 
struct c4 : c0, c3, c2 {
c4();
};
c4::c4() { };
 
class c5 : virtual c4 {};
class c6 : c4 {};


$ g++ go.cpp
/tmp/cchxBAaw.s: Assembler messages:
/tmp/cchxBAaw.s:631: Error: symbol `_ZTh262140_N2c4D1Ev' is already defined
/tmp/cchxBAaw.s:650: Error: symbol `_ZTh262140_N2c4D1Ev' is already defined
/tmp/cchxBAaw.s:721: Error: symbol `_ZTh262140_N2c4D0Ev' is already defined
/tmp/cchxBAaw.s:740: Error: symbol `_ZTh262140_N2c4D0Ev' is already defined

-- 
   Summary: Duplicated thunk with a huge member in the hierarchy
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grigory dot zagorodnev at intel dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-redhat-linux
  GCC host triplet: i686-redhat-linux
GCC target triplet: i686-redhat-linux


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

[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-10-25 13:06 
---
Subject: Re:  [4.0 Regression] 24% C++ compile-time regression
 in comparison with 3.4.1 at -O1 optimization level


Yes, but this only apply to typecode.cc. If you consider ir.cc, you will
need to increase from 40 to 44% and since subject does not talk about
typecode.cc, I would consider leaving it at 40% better option for now...

Cheers,
Karel



-- 


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

[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  
2004-10-25 13:02 ---
Subject: Re:  [4.0 Regression] [tree-ssa] Many
 C++ compile-time regression in 4.0-tree-ssa 040120

And
http://gcc.gnu.org/ml/gcc/2004-10/msg00955.html



-- 


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

[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 12:55 
---
Rewording summary because now we are only 23%:
File342-O0  400-O0  Delta%  342-O1  400-O1  Delta%  342-O2  400-O2  Delta%
typecode.cc 9.097.6518.82   13.53   17.73   -23.69  32.95   23.29   41.48
>From .

-- 
   What|Removed |Added

Summary|[4.0 Regression] 40% C++|[4.0 Regression] 24% C++
   |compile-time regression in  |compile-time regression in
   |comparison with 3.4.1 at -O1|comparison with 3.4.1 at -O1
   |optimization level  |optimization level


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

[Bug bootstrap/18142] "Unknown pseudo-op: .machine" compiling darwin-crt2.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 12:41 
---
You need a new cctools see:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html
for details.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/18142] New: "Unknown pseudo-op: .machine" compiling darwin-crt2.c

[bothner at gcc dot gnu dot org]

Gcc head has been failing to bootstrap for me for weeks now.
I'm astounded to find this going on, and not finding a match in bugzilla;
I don't think I have anything special in my set-up.  This is a vanilla Mac G$
running OS X 10.3.5 "Panther".  Is nobody else seeing this?

No options to configure except a --prefix.

The bootstrap ends with:

./xgcc -B./ -B/Users/bothner/GNU/install-gcc/powerpc-apple-darwin7.5.0/bin/ -isy
stem /Users/bothner/GNU/install-gcc/powerpc-apple-darwin7.5.0/include -isystem /
Users/bothner/GNU/install-gcc/powerpc-apple-darwin7.5.0/sys-include -L/Users/bot
hner/GNU/build-gcc.head/gcc/../ld -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. 
-I. -I/Users/bothner/GNU/gcc.head/gcc -I/Users/bothner/GNU/gcc.head/gcc/. -I/Use
rs/bothner/GNU/gcc.head/gcc/../include -I./../intl -I/Users/bothner/GNU/gcc.head
/gcc/../libcpp/include   \
  -c /Users/bothner/GNU/gcc.head/gcc/config/darwin-crt2.c -o crt2.o
/var/tmp//ccLVOez4.s:1:Unknown pseudo-op: .machine
/var/tmp//ccLVOez4.s:1:Rest of line ignored. 1st junk character valued 112 (p).
/var/tmp//ccLVOez4.s:319:Unknown pseudo-op: .subsections_via_symbols
make[2]: *** [crt2.o] Error 1

-- 
   Summary: "Unknown pseudo-op: .machine" compiling darwin-crt2.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bothner at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.5.0
  GCC host triplet: powerpc-apple-darwin7.5.0
GCC target triplet: powerpc-apple-darwin7.5.0


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

[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-10-25 12:03 
---
Subject: Re:  [4.0 Regression] [tree-ssa] Many
 C++ compile-time regression in 4.0-tree-ssa 040120


Sure! Here we go: http://gcc.gnu.org/ml/gcc/2004-10/msg00952.html
and results are really promissing, although some interesting regressions
are still presented.

Cheers,
Karel



-- 


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

[Bug other/18132] Problem compiling gcc 3.4.2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-25 11:51 
---
Can you try without setting the CFLAGS?

-- 


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