[Bug c++/39271] 64 bit memory allocation possible error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-23 08:02 ---
Why don't you think all would work?  So you are asking for only 8Gig of memory.
 On a 64bit machine it should work because of virtual memory.  Anyways the
nothrow version of operator new, just call directly malloc, so it is up to the
libc to do the right thing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/39270] Explicit instantiation rejected

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-23 09:56 ---
Confirmed.  Fails at least since GCC 3.3.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
  Known to fail||3.3.6
   Last reconfirmed|-00-00 00:00:00 |2009-02-23 09:56:30
   date||


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

[Bug c++/39269] Invalid template friend declaration accepted

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-23 09:58 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-23 09:58:27
   date||


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

--- Comment #14 from hubicka at gcc dot gnu dot org  2009-02-23 13:11 
---
Subject: Bug 37709

Author: hubicka
Date: Mon Feb 23 13:10:53 2009
New Revision: 144381

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144381
Log:
PR tree-optimization/37709  
* tree.c (block_ultimate_origin): Move here from dwarf2out. 
* tree.h (block_ultimate_origin): Declare.  
* dwarf2out.c (block_ultimate_origin): Move to tree.c   
* tree-ssa-live.c (remove_unused_scope_block_p):
Eliminate blocks containig no instructions nor live variables nor
nested blocks.
(dump_scope_block): New function.
(remove_unused_locals): Enable removal of dead blocks by default;
enable dumping at TDF_DETAILS.  

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbxout.c
trunk/gcc/dwarf2out.c
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree.c
trunk/gcc/tree.h


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

--- Comment #15 from hubicka at gcc dot gnu dot org  2009-02-23 13:12 
---
Fixed.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/33237] [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2009-02-23 13:35 
---
To be fixed with the alias-improvements branch merge.  Not going to be fixed
on the 4.3 or the 4.4 branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dnovillo at gcc dot gnu dot |rguenth at gcc dot gnu dot
   |org |org
  Known to fail|4.3.0   |4.3.0 4.4.0


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

[Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays

[hubicka at gcc dot gnu dot org]

--- Comment #44 from hubicka at gcc dot gnu dot org  2009-02-23 13:41 
---
Hi,
I believe that using fold_convert instead of fold_build1 means that we would
bypass folding done in fold_unary that handles stuff like two conversions in a
row while fold_convert is primarily about returning constant when result is
constant.

Since I want to avoid wrapping fold calls all frontends except for C++
consistently put around convert_to_* calls, I want to do this kind of folding.

I believe only reason to avoid folding is C++ template stuff.


-- 


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

[Bug middle-end/12392] very long optimized compile

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2009-02-23 13:43 
---
-O2 compile-time improved from ~300s to ~180s over the last 1.5 years.


-- 


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

[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2009-02-23 14:09 ---
I don't understand the comment above the assert at all (Honza probably
does) and so this might not  be the correct approach but the following
patch should just obviously work.   At least it does for this testcase
and I am about to bootstrap and regression test it:

2009-02-23  Martin Jambor  

* tree-inline.c (tree_versionable_function_p): Return false for
functions calling setjmp or alloca.

Index: tree-inline.c
===
--- tree-inline.c   (revision 144380)
+++ tree-inline.c   (working copy)
@@ -4174,12 +4174,17 @@ copy_static_chain (tree static_chain, co
 bool
 tree_versionable_function_p (tree fndecl)
 {
+  struct function *fn_cfun;
   if (fndecl == NULL_TREE)
 return false;
   /* ??? There are cases where a function is
  uninlinable but can be versioned.  */
   if (!tree_inlinable_function_p (fndecl))
 return false;
+
+  fn_cfun = DECL_STRUCT_FUNCTION (fndecl);
+  if (fn_cfun->calls_setjmp || fn_cfun->calls_alloca)
+return false;

   return true;
 }


-- 


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

[Bug middle-end/12392] very long optimized compile

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2009-02-23 14:16 
---
I just timed a-i branch and we get most of the time spent in PRE...

 PRE   :  18.69 (13%) usr   0.25 ( 7%) sys  19.30 (12%) wall  
39484 kB ( 5%) ggc

301320   10.8102  compute_transp
1041753.7374  sbitmap_intersection_of_preds
55662 1.9969  bitmap_set_bit
51810 1.8587  bitmap_bit_p

something for you, Steven?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||stevenb dot gcc at gmail dot
   ||com


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

[Bug tree-optimization/39272] New: [4.4 Regression] -D_FORTIFY_SOURCE=2 no longer warns with new glibc headers

[rguenth at gcc dot gnu dot org]

t.h:

#pragma GCC system_header

extern __inline __attribute__ ((__always_inline__)) char *
__attribute__ ((__nothrow__)) blabla (char *__restrict __dest, __const char
*__restrict __src)
{
  return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 > 1));
}

t.c:
#include "t.h"

char buf[6];
int main(int argc, char **argv) {
 blabla(buf,"hello ");
 return 0;
}


no longer warns with GCC 4.4 because blabla is in a system-header
(blabla == strcpy, but 4.3 folds that to memcpy which we also do not warn,
4.4 doesn't do that folding).


-- 
   Summary: [4.4 Regression] -D_FORTIFY_SOURCE=2 no longer warns
with new glibc headers
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug ada/39264] gnat.dg/pack3.adb fails on powerpc64/s390x

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2009-02-23 14:43 
---
Visible on s390x as well:
  http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02251.html


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|powerpc64-unknown-linux-gnu |
   GCC host triplet|powerpc64-unknown-linux-gnu |
 GCC target triplet|powerpc64-unknown-linux-gnu |
   Last reconfirmed|-00-00 00:00:00 |2009-02-23 14:43:35
   date||
Summary|gnat.dg/pack3.adb fails on  |gnat.dg/pack3.adb fails on
   |powerpc64   |powerpc64/s390x


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

[Bug ada/39264] gnat.dg/pack3.adb fails on powerpc64/s390x

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2009-02-23 14:43 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-02-23 14:43:35 |2009-02-23 14:43:59
   date||


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

[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2009-02-23 14:52 ---
Dismal Testsuite results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html

Rob


-- 


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

[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749

[jh at suse dot cz]

--- Comment #6 from jh at suse dot cz  2009-02-23 15:05 ---
Subject: Re:  [4.4 Regression] internal 
 compiler error: in initialize_cfun, at tree-inline.c:1749

Hi,
the assert seems confused.  We can clone setjmp/alloca, just can't inline it.
(well, in fact we even can inline alloca if we are cureful)
just replace src_cfun by cfun and add notice_special_calls into processing
of new statements.

Honza


-- 


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

[Bug bootstrap/39273] New: cc1 Cannot find library mpfr. ".libs" prepended to library name libmpfr.so.1.2.0,

[rvatne at gmail dot com]

The configure options:
  /t3-0/shared/gnu/gcc-4.3.3/configure --prefix=/t3-0/shared/gnu/gcc-trunk
--srcdir=/t3-0/shared/gnu/gcc-4.3.3 --enable-languages=c,fortran
--with-mpfr=/usr/local --with-gmp=/usr/local  --with-pkgversion=432
--disable-bootstrap CC=gcc


Using this compiler:
>gcc -v
Reading specs from /t3-0/local/bin/../lib/gcc/sparc-sun-solaris2.7/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6



gmake output:

gmake[2]: Leaving directory `/t3-0/shared/gnu/gcc-bld3/gcc'
Checking multilib configuration for libgcc...
mkdir sparc-sun-solaris2.8
mkdir sparc-sun-solaris2.8/libgcc
Configuring in sparc-sun-solaris2.8/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /t3-0/shared/gnu/gcc-4.3.3/install-sh
-c
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for sparc-sun-solaris2.8-ar... ar
checking for sparc-sun-solaris2.8-lipo... lipo
checking for sparc-sun-solaris2.8-nm... /t3-0/shared/gnu/gcc-bld3/./gcc/nm
checking for sparc-sun-solaris2.8-ranlib... ranlib
checking for sparc-sun-solaris2.8-strip... strip
checking whether ln -s works... yes
checking for sparc-sun-solaris2.8-gcc... /t3-0/shared/gnu/gcc-bld3/./gcc/xgcc
-B/t3-0/shared/gnu/gcc-bld3/./gcc/
-B/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/bin/
-B/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/lib/ -isystem
/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/include -isystem
/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/sys-include
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
gmake[1]: *** [configure-target-libgcc] Error 1
gmake[1]: Leaving directory `/t3-0/shared/gnu/gcc-bld3'
gmake: *** [all] Error 2


looking in configure.log in sparc-sun-solaris2.8/libgcc

configure:2567: checking for suffix of object files
configure:2588: /t3-0/shared/gnu/gcc-bld3/./gcc/xgcc
-B/t3-0/shared/gnu/gcc-bld3/./gcc/
-B/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/bin/ -B/t3-0/shared/gnu/g
cc-trunk/sparc-sun-solaris2.8/lib/ -isystem
/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/include -isystem
/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/sys-in
clude -c -O2 -g -g -O2conftest.c >&5
ld.so.1: cc1: fatal: .libs/libmpfr.so.1.2.0: open failed: No such file or
directory
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See  for instructions.
configure:2591: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:2604: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.


It seems that the newly buildt "xgcc" does not use the LD_LIBRARY_PATH to find
the "libmpfr.so.1.2.0" library, but instead prepends at fixed path (.libs/).


-- 
   Summary: cc1 Cannot find library mpfr. ".libs" prepended to
library name libmpfr.so.1.2.0,
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rvatne at gmail dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug bootstrap/39273] cc1 Cannot find library mpfr. ".libs" prepended to library name libmpfr.so.1.2.0,

[rvatne at gmail dot com]

--- Comment #1 from rvatne at gmail dot com  2009-02-23 15:08 ---
Created an attachment (id=17347)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17347&action=view)
the failing config.log

the config.log from sparc-sun-solaris2.8/libgcc


-- 


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

[Bug bootstrap/39273] cc1 Cannot find library mpfr. ".libs" prepended to library name libmpfr.so.1.2.0,

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-02-23 15:09 ---
No the .libs/libmpfr.so.1.2.0 is embeded into libmpfr.so.1.2.0 .  So something
is incorrect in your building of MPRF.


-- 


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

[Bug bootstrap/39273] cc1 Cannot find library mpfr. ".libs" prepended to library name libmpfr.so.1.2.0,

[rvatne at gmail dot com]

--- Comment #3 from rvatne at gmail dot com  2009-02-23 15:18 ---
(In reply to comment #2)
> No the .libs/libmpfr.so.1.2.0 is embeded into libmpfr.so.1.2.0 .  So something
> is incorrect in your building of MPRF.
> 

NO, I don't think so.  The MPRF is "pkgadded" from sunfreeware.com - 
and
here's a truss output from running cc1 (directly)


gcc-bld3$ truss /t3-0/shared/gnu/gcc-bld3/./gcc/cc1 -quiet -iprefix
/t3-0/shared/gnu/gcc-bld3/gcc/../lib/gcc/sparc-sun-solaris2.8/4.3.3/ -isystem
/t3-0/shared/gnu/gcc-bld3/./gcc/include -isystem
/t3-0/shared/gnu/gcc-bld3/./gcc/include-fixed -D__sparcv8 -isystem
/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/include -isystem
/t3-0/shared/gnu/gcc-trunk/sparc-sun-solaris2.8/sys-include conftest.c -quiet
-dumpbase conftest.c -mcpu=v9 -auxbase conftest -g -g -O2 -O2 -o
/tmp/conftest.s
execve("/t3-0/shared/gnu/gcc-bld3/gcc/cc1", 0xFFBEE05C, 0xFFBEE0C8)  argc = 26
resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
open("/var/ld/ld.config", O_RDONLY) = 3
fstat(3, 0xFFBED8B8)= 0
mmap(0x, 112, PROT_READ, MAP_SHARED, 3, 0) = 0xFF39
close(3)= 0
stat("/usr/local/lib/libintl.so.8", 0xFFBED940) = 0
resolvepath("/usr/local/lib/libintl.so.8", "/t3-0/local/lib/libintl.so.8.0.2",
1023) = 32
open("/usr/local/lib/libintl.so.8", O_RDONLY)   = 3
mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF38
mmap(0x, 106496, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON, -1, 0)
= 0xFF36
mmap(0xFF36, 35170, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xFF36
mmap(0xFF378000, 4404, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 32768) = 0xFF378000
munmap(0xFF36A000, 57344)   = 0
memcntl(0xFF36, 8836, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(3)= 0
stat("/usr/local/lib/libiconv.so.2", 0xFFBED940) = 0
resolvepath("/usr/local/lib/libiconv.so.2",
"/t3-0/local/lib/libiconv.so.2.4.0", 1023) = 33
open("/usr/local/lib/libiconv.so.2", O_RDONLY)  = 3
mmap(0xFF38, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xFF38
mmap(0x, 999424, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON, -1, 0)
= 0xFF20
mmap(0xFF20, 924047, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xFF20
mmap(0xFF2F, 11904, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 917504) = 0xFF2F
munmap(0xFF2E2000, 57344)   = 0
mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xFF35
memcntl(0xFF20, 13660, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(3)= 0
stat(".libs/libmpfr.so.1.2.0", 0xFFBED9A8)  Err#2 ENOENT
ld.so.1: cc1: fatal: .libs/libmpfr.so.1.2.0: open failed: No such file or
directory
write(2, " l d . s o . 1 :   c c 1".., 84)  = 84
munmap(0xFF38, 8192)= 0
lwp_self()  = 1
*** process killed ***

I shows (i think) that the loader (ld.so) finds libiconv etc. in a normal way,
but libmpfr is opend "direct path" ??


-- 


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

[Bug bootstrap/39273] cc1 Cannot find library mpfr. ".libs" prepended to library name libmpfr.so.1.2.0,

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-02-23 15:23 ---
That only shows that .libs/libmpfr.so.1.2.0 is inside cc1's path.  I think you
should try a simple programed linked with MPFR using the old GCC and you most
likely get the same behavior.  


-- 


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

[Bug c/39274] New: internal compiler error: in check_cfg, at haifa-sched.c, var-tracking

[sergei_lus at yahoo dot com]

This simple code: 

typedef void (*TestFunction)(int *);

void Add(int *testCase);
void test(void);
int* TestNew( TestFunction function);

static void foo(int* tc){
   test();
}

int* GetProfileSuite(){
   Add(TestNew(foo));
   return 0;
}

...triggers internal assert on my port of 4.3.2 when compiled with -O2 -g. It
will pass with -O2 only or with -O2 -fno-var-tracking -g. 

The assert triggered is this one:

...
static void
check_cfg (rtx head, rtx tail)
{
...
if (control_flow_insn_p (head))
   {
  gcc_assert (BB_END (bb) == head); << This one 

  if (any_uncondjump_p (head))
  gcc_assert (EDGE_COUNT (bb->succs) == 1
 && BARRIER_P (NEXT_INSN (head)));

It looks like free_cfg pass removes something it should not after
NOTE_INSN_VAR_LOCATION was inserted by variable_tracking pass.


-- 
   Summary: internal compiler error: in check_cfg, at haifa-sched.c,
var-tracking
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com


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

[Bug c++/14179] [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers

[hubicka at gcc dot gnu dot org]

--- Comment #52 from hubicka at gcc dot gnu dot org  2009-02-23 16:06 
---
With patches proposed for c/12245 we now need 377MB (from original over 1GB)
garbage and produce 920MB of IL.
Pretty much all the garbage is coming from temporary list constructed here:

  /* Add it to the vector.  */
  CONSTRUCTOR_APPEND_ELT(v, identifier, initializer);

in cp_parser_initializer_list.
Perhaps explicitly freeing would be good idea? 

Honza


-- 


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

[Bug middle-end/39275] New: -funroll-loop fails

[linuxl4 at sohu dot com]

{~/tmp}$gcc --version
gcc (GCC) 4.4.0 20090223 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.

{~/tmp}$g++  -O2  -funroll-loops  -c looppass.cpp
/mnt/svn/svn/llvm/lib/Analysis/LoopPass.cpp: In member function 'void
llvm::LPPassManager::deleteLoopFromQueue(llvm::Loop*)':
/mnt/svn/svn/llvm/lib/Analysis/LoopPass.cpp:101: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: -funroll-loop fails
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linuxl4 at sohu dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/14179] [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers

[mark at codesourcery dot com]

--- Comment #53 from mark at codesourcery dot com  2009-02-23 16:11 ---
Subject: Re:  [4.2/4.3/4.4 Regression] out of memory while
 parsing array with many initializers

hubicka at gcc dot gnu dot org wrote:

> Perhaps explicitly freeing would be good idea? 

I certainly have no objection to explicitly freeing storage if we know
we don't need it anymore.


-- 


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

[Bug c/39276] New: [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[rob1weld at aol dot com]

# gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: i386-pc-solaris2.11
Configured with: ../lto_trunk/configure --prefix=/usr/local/lto
--enable-languages=lto,c++ --enable-shared --disable-static --enable-multilib
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged
with rev 144262) 


The Testsuite gcc.log shows many "getconf: Invalid argument 
(_NPROCESSORS_ONLN)" errors. Here is one example:

PASS: gcc.c-torture/execute/builtins/20010124-1.c execution,  -O0 -flto 
Executing on host: /usr/share/src/lto_build/gcc/xgcc
-B/usr/share/src/lto_build/gcc/
/usr/share/src/lto_trunk/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
/usr/share/src/lto_trunk/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
/usr/share/src/lto_trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
 -w  -O0 -fwhopr   -lm   -o
/usr/share/src/lto_build/gcc/testsuite/gcc/20010124-1.x1(timeout = 300)
getconf: Invalid argument (_NPROCESSORS_ONLN)


/usr/share/src/lto_build/gcc/ltrans-driver[99]: [: argument expected


output is:
getconf: Invalid argument (_NPROCESSORS_ONLN)


/usr/share/src/lto_build/gcc/ltrans-driver[99]: [: argument expected


FAIL: gcc.c-torture/execute/builtins/20010124-1.c compilation,  -O0 -fwhopr 
UNRESOLVED: gcc.c-torture/execute/builtins/20010124-1.c execution,  -O0 -fwhopr 


On Solaris if you execute this, you get this:

# /usr/bin/getconf _NPROCESSORS_ONLN
getconf: Invalid argument (_NPROCESSORS_ONLN)

# /usr/xpg4/bin/getconf _NPROCESSORS_ONLN 
getconf: Invalid argument (_NPROCESSORS_ONLN)


But, if you execute this, you get this:

# /bin/ksh93 -c getconf | grep NPROCESSORS_ONLN
NPROCESSORS_ONLN=1

# /bin/ksh93 -c "getconf NPROCESSORS_ONLN"
1


The last result is probably what is wanted.

Rob


-- 
   Summary: [lto] - Testsuite gcc.log shows many "getconf: Invalid
argument (_NPROCESSORS_ONLN)"
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug middle-end/39275] -funroll-loop fails

[linuxl4 at sohu dot com]

--- Comment #1 from linuxl4 at sohu dot com  2009-02-23 16:15 ---
Created an attachment (id=17348)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17348&action=view)
source


-- 


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

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

[hubicka at gcc dot gnu dot org]

--- Comment #46 from hubicka at gcc dot gnu dot org  2009-02-23 16:29 
---
So with brand new tuplified world, we need new statistics ;)

After parsing we are still the same:
cfg.c:216 (connect_src)  608608: 0.2%520:
0.0%3028808: 1.6% 519680: 1.3%  64954
cp/lex.c:511 (build_lang_decl)   805432: 0.3% 209648:
0.6%3196488: 1.7% 349552: 0.9%  18896
stringpool.c:73 (alloc_node)  65088: 0.0%  0:
0.0%3208992: 1.7%  0: 0.0%  34105
fold-const.c:7969 (build_fold_addr_expr_with_typ 530352: 0.2%  0:
0.0%3440880: 1.8% 441248: 1.1%  55156
cfg.c:226 (connect_dest) 598696: 0.2% 180224:
0.5%3484960: 1.8% 594504: 1.5%  73663
cgraph.c:432 (cgraph_create_node) 0: 0.0%  0:
0.0%3712320: 1.9% 412480: 1.1%  12890
gimple-low.c:888 (record_vars_into)   0: 0.0%  0:
0.0%3808032: 2.0%  0: 0.0%  79334
cp/pt.c:8398 (tsubst_decl)  2244888: 0.9%  0:
0.0%4552704: 2.4% 357768: 0.9%  44721
tree.c:6101 (build_method_type_directly)1946800: 0.8%  0:
0.0%4704000: 2.5% 266032: 0.7%  33254
tree-inline.c:3595 (copy_tree_r)9428112: 3.7%  0:
0.0%4793248: 2.5%1243776: 3.2% 186815
cfg.c:142 (alloc_block) 1046016: 0.4%  0:
0.0%4988448: 2.6%  0: 0.0%  62859
cgraph.c:681 (cgraph_create_edge) 0: 0.0%  0:
0.0%5183328: 2.7%  0: 0.0%  53993
cfg.c:280 (unchecked_make_edge)   0: 0.0% 696256:
1.9%5271424: 2.8%  0: 0.0%  93245
gimplify.c:4295 (gimplify_modify_expr)  1183600: 0.5%  0:
0.0%5519400: 2.9% 300632: 0.8%  57164
gimple-iterator.c:446 (gsi_insert_after_without_4903960: 1.9%  0:
0.0%5826440: 3.1%2146080: 5.5% 268260
gimple.c:287 (gimple_build_call_1)   871144: 0.3%  0:
0.0%6066056: 3.2% 247408: 0.6%  51874
tree.c:964 (build_int_cst_wide)6096: 0.0%  0:
0.0%   10089256: 5.3%3310168: 8.6%   2292
gimplify.c:522 (create_tmp_var_raw)  453768: 0.2%  0:
0.0%   10537632: 5.5% 523400: 1.4%  65425
cp/lex.c:591 (copy_decl)  26304: 0.0%  0:
0.0%   13586520: 7.1%1326296: 3.4%  56894
Total 254844605 37217584   
190405469 38695562  5886026
source location GarbageFreed   
 Leak OverheadTimes

After early optimizations:

tree-inline.c:4051 (copy_decl_to_var)145488: 0.0%  0:
0.0%5595072: 2.0% 273360: 0.4%  34170
gimple-iterator.c:446 (gsi_insert_after_without_   14165480: 3.2%  0:
0.0%5633680: 2.0%3959832: 5.9% 494979
ggc-common.c:187 (ggc_calloc)565872: 0.1%  
17553976:12.6%5692736: 2.1% 423928: 0.6%  67925 
cgraph.c:681 (cgraph_create_edge) 0: 0.0%  0:
0.0%5958624: 2.2%  0: 0.0%  62069
tree-ssanames.c:141 (make_ssa_name_fn) 16722480: 3.8%  0:
0.0%8318040: 3.0%1669368: 2.5% 208671
gimplify.c:522 (create_tmp_var_raw) 5067048: 1.2%  0:
0.0%8897280: 3.2% 664968: 1.0%  83121
tree.c:964 (build_int_cst_wide)6096: 0.0%  0:
0.0%   10327480: 3.8%3388168: 5.1%   2341
tree-dfa.c:150 (create_var_ann)   0: 0.0%  
23279784:16.7%   10578392: 3.8%3078016: 4.6% 384752
tree-inline.c:3595 (copy_tree_r)   49340008:11.2%  0:
0.0%   12558984: 4.6%5762144: 8.6% 796535
gimple.c:2071 (gimple_copy)11219128: 2.6%  0:
0.0%   13100280: 4.8%1193408: 1.8% 209046
cp/lex.c:591 (copy_decl)  62424: 0.0%  0:
0.0%   13550400: 4.9%1326296: 2.0%  56894 
tree-inline.c:484 (remap_block) 1924416: 0.4%  0:
0.0%   14794832: 5.4%1286096: 1.9% 160762
tree-ssa-operands.c:499 (ssa_operand_alloc)   0: 0.0%  
33737566:24.3%   17976728: 6.5%3547382: 5.3%  11222
tree-inline.c:4094 (copy_decl_no_change)   12372728: 2.8%  0:
0.0%   29185744:10.6%1892440: 2.8% 250867
Total 439703478139072686   
274931123 66651575  9262384
source location GarbageFreed   
 Leak OverheadTimes 

Declarations and debug info being major consum

[Bug c++/18835] memory consumption is high for C++ testcase

[hubicka at gcc dot gnu dot org]

--- Comment #3 from hubicka at gcc dot gnu dot org  2009-02-23 16:39 ---
Testcase no longer compile:
/home/jh/bitmachine.cc:5049: error: declaration of 'typedef typename
Context::inner_context_type::state_base_type
boost::fsm::simple_state::state_base_type'
/home/jh/bitmachine.cc:4961: error: conflicts with previous declaration
'typedef typename Context::inner_context_type::state_base_type
boost::fsm::simple_state::state_base_type'
/home/jh/bitmachine.cc:5053: error: declaration of 'typedef typename
Context::inner_context_type::outermost_context_type
boost::fsm::simple_state::outermost_context_type'
/home/jh/bitmachine.cc:4920: error: conflicts with previous declaration
'typedef typename Context::inner_context_type::outermost_context_type
boost::fsm::simple_state::outermost_context_type'

Can we have updated one?


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays

[hubicka at gcc dot gnu dot org]

--- Comment #45 from hubicka at gcc dot gnu dot org  2009-02-23 16:46 
---
Subject: Bug 12245

Author: hubicka
Date: Mon Feb 23 16:46:32 2009
New Revision: 144384

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144384
Log:
PR c/12245
* ggc.h (htab_create_ggc): Use ggc_free to free hashtable when
resizing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ggc.h


-- 


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

[Bug c/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-02-23 16:48 ---
Created an attachment (id=17349)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17349&action=view)
Proposed Patch to fix ltrans-driver on Platform OpenSolaris

This patch should fix this Bug (and another, use gawk instead of awk)
in the ../lto_trunk/gcc/lto/ltrans-driver file on OpenSolaris 2009.06 .

Rob


-- 


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

[Bug c++/14179] [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers

[hubicka at ucw dot cz]

--- Comment #54 from hubicka at ucw dot cz  2009-02-23 16:51 ---
Subject: Re:  [4.2/4.3/4.4 Regression] out of memory while parsing array with
many initializers

> > Perhaps explicitly freeing would be good idea? 
> 
> I certainly have no objection to explicitly freeing storage if we know
> we don't need it anymore.

Problem is that I don't know enough of C++ parser to be sure where we
can safely free this vector?

Honza


-- 


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

[Bug c/39277] New: Segmentation fault when compiling arith1.c of Pari/GP 2.3.3/2.3.4 with -O3

[Michael dot Finken at me dot com]

I am compiling version 2.3.3 (or 2.3.4) of the Pari/GP math library. The
compiler crashes with a segmentation fault, when the source file arith1.c is
compiled with -O3.

The compiler is gcc 4.3.3, freshly compiled on Solaris 2.8.

Here's the log output of the compile:

Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.3/configure --prefix=/app/murex/mxjobs/tools
--with-local-prefix=/app/murex/mxjobs/tools --enable-languages=c,c++
--with-gmp=/app/murex/m
xjobs/tools --with-mpfr=/app/murex/mxjobs/tools --disable-nls --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 4.3.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-Wall'
'-fno-strict-aliasing' '-fomit-frame-pointer' '-I.' '-I../src/headers' '-o'
'arith1.o' '-mcpu=v9'

/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../libexec/gcc/sparc-sun-solaris2.8/4.3.3/cc1
-E -quiet -v -I. -I../src/headers -iprefix /app/murex/mxjobs/tools/Pack
ages/gcc-4.3.3/bin/../lib/gcc/sparc-sun-solaris2.8/4.3.3/ -D__sparcv8
../src/basemath/arith1.c -mcpu=v9 -Wall -fno-strict-aliasing
-fomit-frame-pointer -O3 -fpch-pre
process -o arith1.i
ignoring nonexistent directory
"/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../sparc-sun-solaris2.8/include"
ignoring duplicate directory
"/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.8/4.3.3/include"
ignoring duplicate directory
"/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed"
ignoring nonexistent directory
"/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../sparc-sun-solaris2.8/i
nclude"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../src/headers

/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../lib/gcc/sparc-sun-solaris2.8/4.3.3/include

/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed
 /app/murex/mxjobs/tools/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-Wall'
'-fno-strict-aliasing' '-fomit-frame-pointer' '-I.' '-I../src/headers' '-o'
'arith1.o' '-mcpu=v9'

/app/murex/mxjobs/tools/Packages/gcc-4.3.3/bin/../libexec/gcc/sparc-sun-solaris2.8/4.3.3/cc1
-fpreprocessed arith1.i -quiet -dumpbase arith1.c -mcpu=v9 -auxbase-str
ip arith1.o -O3 -Wall -version -fno-strict-aliasing -fomit-frame-pointer -o
arith1.s
GNU C (GCC) version 4.3.3 (sparc-sun-solaris2.8)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3a569cfd8a08af79990f0013cab714dc
../src/basemath/arith1.c: In function 'Fl_pow':
../src/basemath/arith1.c:1788: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: Segmentation fault when compiling arith1.c of Pari/GP
2.3.3/2.3.4 with -O3
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Michael dot Finken at me dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c/39277] Segmentation fault when compiling arith1.c of Pari/GP 2.3.3/2.3.4 with -O3

[Michael dot Finken at me dot com]

--- Comment #1 from Michael dot Finken at me dot com  2009-02-23 16:57 
---
Created an attachment (id=17350)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17350&action=view)
This is the log of the compile command

This is the complete output of the compile command, when run with gcc -v


-- 


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

[Bug c/39277] Segmentation fault when compiling arith1.c of Pari/GP 2.3.3/2.3.4 with -O3

[Michael dot Finken at me dot com]

--- Comment #2 from Michael dot Finken at me dot com  2009-02-23 16:58 
---
Created an attachment (id=17351)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17351&action=view)
The intermediate file after pre-processing

The magic source file...


-- 


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

[Bug c/39277] Segmentation fault when compiling arith1.c of Pari/GP 2.3.3/2.3.4 with -O3

[Michael dot Finken at me dot com]

--- Comment #3 from Michael dot Finken at me dot com  2009-02-23 16:58 
---
Created an attachment (id=17352)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17352&action=view)
The assembler source, created upto the crash.


-- 


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

[Bug c/39277] Segmentation fault when compiling arith1.c of Pari/GP 2.3.3/2.3.4 with -O3

[Michael dot Finken at me dot com]

--- Comment #4 from Michael dot Finken at me dot com  2009-02-23 17:01 
---
This happens with gcc 4.3.2 as well. 
I compiled gcc 4.3.3 today, hoping that the problem would no longer appear.


-- 

Michael dot Finken at me dot com changed:

   What|Removed |Added

 CC||Michael dot Finken at me dot
   ||com


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

[Bug c/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-02-23 17:04 ---
Created an attachment (id=17353)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17353&action=view)
Proposed Patch to fix ltrans-driver on Platform OpenSolaris

Revised Patch.


-- 

rob1weld at aol dot com changed:

   What|Removed |Added

  Attachment #17349|0   |1
is obsolete||


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

[Bug target/5362] Undocumented target options

[sje at cup dot hp dot com]

--- Comment #12 from sje at cup dot hp dot com  2009-02-23 17:16 ---
I am adding Nick Clifton to the CC list since he is listed as the maintainer
for fr30 and mcore.  fr30 and it's two options (-mno-lsim and -msmall-model)
are not documented at all in invoke.texi.  mcore is missing documentation about
the -mno-lsim option.  IA64 was missing some documentation but I fixed that
while fixing PR 30687.  All the other targets have been removed.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com,
   ||nickc at redhat dot com


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

[Bug other/36395] TARGET_VECTOR_ALIGNMENT_REACHABLE isn't documented

[sje at cup dot hp dot com]

--- Comment #2 from sje at cup dot hp dot com  2009-02-23 17:27 ---
Adding Dorit Nuzman and Devang Patel to the CC list since they are listed as
the authors of the patch that created this macro.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||dorit at il dot ibm dot com


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

[Bug driver/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-02-23 17:29 ---
I don't think ltrans-driver should be a shell script anyways because on windows
you will most likely not have /bin/sh installed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


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

[Bug driver/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[dnovillo at google dot com]

--- Comment #4 from dnovillo at google dot com  2009-02-23 17:33 ---
Subject: Re:  [lto] - Testsuite gcc.log shows many "getconf: 
Invalid argument (_NPROCESSORS_ONLN)"

On Mon, Feb 23, 2009 at 12:29, pinskia at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #3 from pinskia at gcc dot gnu dot org  2009-02-23 17:29 
> ---
> I don't think ltrans-driver should be a shell script anyways because on 
> windows
> you will most likely not have /bin/sh installed.

Yes, ltrans-driver is a quick hack.  It probably only works reliably
on some variants of Linux.  It's a small script, so it should be easy
to fix.


Diego.


-- 


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

[Bug c++/37789] [4.4 regression] ICE with __FUNCTION__

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-23 17:39 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01073.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||02/msg01073.html


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

[Bug c++/36411] [4.4 regression] ICE with invalid template template parameter

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-02-23 17:43 ---
Oops. A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00575.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug middle-end/12392] very long optimized compile

[stevenb dot gcc at gmail dot com]

--- Comment #25 from stevenb dot gcc at gmail dot com  2009-02-23 17:47 
---
Subject: Re:  very long optimized compile

Re Comment #24:

I can look into it...


-- 


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

[Bug driver/39278] New: subdirectory named 'gcc' with parent in $PATH, before actual gcc executable in $PATH, is treated as executable

[dickie at acm dot org]

If gcc is invoked without an absolute path, and there is a *directory* named
'gcc' which can be found by searching $PATH before the actual gcc executable,
then that location is taken as a starting point for searching for includes. As
a result, standard include files such as stddef.h cannot be found.

In the following example, an empty directory named /home/gdickie/gcc is
created, and its parent /home/gdickie is placed into the search path. This
results in an automatically-generated option "-iprefix
/home/gdickie/../lib/gcc/i486-linux-gnu/4.3.2/", but this directory does not
actually exist.  

After the failure is a demonstration with /usr/bin added the front of the path,
which fixes the problem. Another way of fixing the problem is to invoke
/usr/bin/gcc with a full path.

src$ mkdir ~/gcc
src$ PATH=~:$PATH
src$ echo '#include ' > test.c
src$ gcc -v -save-temps -c test.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix
/home/gdickie/../lib/gcc/i486-linux-gnu/4.3.2/ test.c -D_FORTIFY_SOURCE=2
-mtune=generic -fpch-preprocess -o test.i
ignoring nonexistent directory
"/home/gdickie/../lib/gcc/i486-linux-gnu/4.3.2/include"
ignoring nonexistent directory
"/home/gdickie/../lib/gcc/i486-linux-gnu/4.3.2/include-fixed"
ignoring nonexistent directory
"/home/gdickie/../lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/home/gdickie/../lib/gcc/../../lib/gcc/i486-linux-gnu/4.3.2/include"
ignoring nonexistent directory
"/home/gdickie/../lib/gcc/../../lib/gcc/i486-linux-gnu/4.3.2/include-fixed"
ignoring nonexistent directory
"/home/gdickie/../lib/gcc/../../lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/include
End of search list.
test.c:1:20: error: stddef.h: No such file or directory
src$ cat test.i
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
src$ 

src$ PATH=/usr/bin:$PATH
src$ gcc -v -save-temps -c test.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -E -quiet -v test.c -D_FORTIFY_SOURCE=2
-mtune=generic -fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.2/include
 /usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -mtune=generic -auxbase test -version -fstack-protector -o test.s
GNU C (Ubuntu 4.3.2-1ubuntu12) version 4.3.2 (i486-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9ecd6562c106044a1f3a6d56a4b5859b
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic'
 as -V -Qy -o test.o test.s
GNU assembler version 2.18.93 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.93.20081009
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-l

[Bug driver/39278] subdirectory named 'gcc' with parent in $PATH, before actual gcc executable in $PATH, is treated as executable

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-23 18:01 ---


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

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-02-23 18:01 ---
*** Bug 39278 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dickie at acm dot org


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

[Bug middle-end/16373] -O2 and -O3 compiler switches do not "omit-frame-pointers" as the docs. describe.

[sje at cup dot hp dot com]

--- Comment #6 from sje at cup dot hp dot com  2009-02-23 18:55 ---
It looks to me like this has been fixed.  In the -O documentation in
invoke.texi it says:

@option{-O} also turns on @option{-fomit-frame-pointer} on machines
where doing so does not interfere with debugging.

Closing it out as fixed.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com
 Status|NEW |RESOLVED
  GCC build triplet|3.3.2   |
   GCC host triplet|3.3.2   |
 GCC target triplet|3.3.2   |
  Known to work||4.4.0
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c/33466] mixed-case suffix for decimal float constants

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2009-02-23 19:00 ---
Subject: Bug 33466

Author: janis
Date: Mon Feb 23 19:00:32 2009
New Revision: 144391

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144391
Log:
PR c/33466
* expr.c (interpret_float_suffix): Reject invalid suffix that uses
letters from decimal float and fixed-point suffixes.

PR c/33466
* gcc.dg/cpp/pr33466.c: New test.
* gcc.dg/dfp/pr33466.c: New test.
* gcc.dg/fixed-point/pr33466.c: New test.

Added:
branches/c-4_5-branch/gcc/testsuite/gcc.dg/cpp/pr33466.c
branches/c-4_5-branch/gcc/testsuite/gcc.dg/dfp/pr33466.c
branches/c-4_5-branch/gcc/testsuite/gcc.dg/fixed-point/pr33466.c
Modified:
branches/c-4_5-branch/gcc/testsuite/ChangeLog
branches/c-4_5-branch/libcpp/ChangeLog
branches/c-4_5-branch/libcpp/expr.c


-- 


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

[Bug c/33466] mixed-case suffix for decimal float constants

[janis at gcc dot gnu dot org]

--- Comment #7 from janis at gcc dot gnu dot org  2009-02-23 19:05 ---
The checkin is for Joseph's c-4.5 branch.  I'll move this to trunk after 4.4
branches.


-- 


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

[Bug bootstrap/39279] New: [lto] - Werror in ../lto_trunk/gcc/lto/lto.c

[rob1weld at aol dot com]

# cat stage_current 
stage2

# gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: i386-pc-solaris2.11
Configured with: ../lto_trunk/configure --prefix=/usr/local/lto
--enable-languages=lto,c++ --enable-shared --disable-static --enable-multilib
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl --with-demangler-in-ld --enable-clocale=gnu
--with-system-libunwind --with-libelf=/usr/local CPPFLAGS=-I/usr/local/include
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged
with rev 144262) 


/usr/share/src/lto_build/./prev-gcc/xgcc -B/usr/share/src/lto_build/./prev-gcc/
-B/usr/local/lto/i386-pc-solaris2.11/bin/ -c  -g -O2 -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -Ilto -I../../lto_trunk/gcc -I../../lto_trunk/gcc/lto
-I../../lto_trunk/gcc/../include -I../../lto_trunk/gcc/../libcpp/include
-I/usr/local/include -I/usr/local/include -I../../lto_trunk/gcc/../libdecnumber
-I../../lto_trunk/gcc/../libdecnumber/dpd -I../libdecnumber   
../../lto_trunk/gcc/lto/lto.c -o lto/lto.o
cc1: warnings being treated as errors
../../lto_trunk/gcc/lto/lto.c: In function ‘free_section_data’:
../../lto_trunk/gcc/lto/lto.c:497: error: request for implicit conversion from
‘void *’ to ‘caddr_t’ not permitted in C++
gmake[3]: *** [lto/lto.o] Error 1
gmake[3]: Leaving directory `/usr/share/src/lto_build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/usr/share/src/lto_build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/share/src/lto_build'
gmake: *** [all] Error 2


Rob


-- 
   Summary: [lto] - Werror in ../lto_trunk/gcc/lto/lto.c
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug target/39250] unsigned char times 64U produces long slow loop

[aesok at gcc dot gnu dot org]

--- Comment #1 from aesok at gcc dot gnu dot org  2009-02-23 19:10 ---
Hi.

The GCC always use a shift for optimizing multiply by power of 2 constant.

expr.c:expand_expr_real_1:8680

  /* Check for a multiplication with matching signedness.  */
  else if (TREE_CODE (TREE_OPERAND (exp, 0)) == NOP_EXPR
  && TREE_CODE (type) == INTEGER_TYPE
  && (TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (exp, 0),
0)))
  < TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (exp, 0
  && ((TREE_CODE (TREE_OPERAND (exp, 1)) == INTEGER_CST
   && int_fits_type_p (TREE_OPERAND (exp, 1),
   TREE_TYPE (TREE_OPERAND (TREE_OPERAND (exp,
0), 0)))
   /* Don't use a widening multiply if a shift will do.  */
   && ((GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (TREE_OPERAND (exp,
1
> HOST_BITS_PER_WIDE_INT)
   || exact_log2 (TREE_INT_CST_LOW (TREE_OPERAND (exp, 1))) <
0))

expmed.c:expand_mult
...
  if (coeff != 0)
{
  /* Special case powers of two.  */
  if (EXACT_POWER_OF_2_OR_ZERO_P (coeff))
return expand_shift (LSHIFT_EXPR, mode, op0,
 build_int_cst (NULL_TREE, floor_log2 (coeff)),
 target, unsignedp);


For the AVR target for multiply by 2 with using  a shift give better code,
but for multiply by 4,8, ... using a shift is bad and for code size and for
speed. 

I think this optimization should not be hard coded, but should be chosen
based on the insn cost data. Perhaps there are other targets, which is better
to use multiplication rather than a shift.

Anatoly.


-- 


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

[Bug fortran/39229] No warning of truncated lines if a continuation line follows

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2009-02-23 19:38 ---
parse.c (next_statement):
816   if (gfc_at_eol ())
817 {
818   if ((gfc_option.warn_line_truncation || gfc_current_form ==
FORM_FREE)
819   && gfc_current_locus.lb
820   && gfc_current_locus.lb->truncated)
821 gfc_warning_now ("Line truncated at %C");
822
823   gfc_advance_line ();
824 }

scanner.c:
gfc_at_eol (void)
{
  if (gfc_at_eof ())
return 1;

  return (*gfc_current_locus.nextc == '\0');
}

in gdb:

Breakpoint 1, next_statement () at
/home/daniel/svn/gcc-whole-file/gcc/fortran/parse.c:816
816   if (gfc_at_eol ())
(gdb) print *gfc_current_locus->lb
$22 = {location = 3, file = 0xa8a4930, next = 0xa8bb5f8, truncated = 1,
dbg_emitted = 0 '\0', line = {32}}
(gdb) print *gfc_current_locus->nextc
$23 = 32
(gdb) cont
Continuing.

Breakpoint 1, next_statement () at
/home/daniel/svn/gcc-whole-file/gcc/fortran/parse.c:816
816   if (gfc_at_eol ())
(gdb) print *gfc_current_locus->lb
$24 = {location = 131, file = 0xa8a4930, next = 0xa8bb738, truncated = 0,
dbg_emitted = 1 '\001', line = {32}}
(gdb) print *gfc_current_locus->nextc
$25 = 0

For the continued line gfc_at_eol() returns false and thus its truncated-flag
is silently lost.


-- 


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

[Bug fortran/39280] New: Optimizing integer power

[tkoenig at gcc dot gnu dot org]

$ cat foo.f90
subroutine foo
  implicit none
  integer :: i,n
  do i=1,10
n = (-1)**(i+1)
call bar(n)
  end do
end subroutine foo
$ gfortran -S -O2 -fdump-tree-optimized foo.f90
...

  i = i + 1;
  n.0 = _gfortran_pow_i4_i4 (-1, i);
  n = n.0;
  bar (&n);

We could eliminate the call to _gfortran_pow_i4_i4.


-- 
   Summary: Optimizing integer power
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug c++/39281] New: Error message 'multiple types in one declaration' need to be reworded

[yuri at tsoft dot com]

Usually this error message is issued when semicolon is missing after the
struct/class declaration.

Message itself is pretty obscure.

It's better to change it:
error: multiple types in one declaration, missing semicolon after type
declaration?

This will give users a clue and will likely eliminate the need to google the
error message.


-- 
   Summary: Error message 'multiple types in one declaration' need
to be reworded
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/39281] Error message 'multiple types in one declaration' need to be reworded

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/39282] New: 4.4 reject code accepted by 4.3 and comeau.

[pluto at agmk dot net]

template < typename T >
struct ManagerBase
{
virtual void insert( T* );
};

template < typename T >
class ManagerInterface : public ManagerBase< T >
{
using ManagerBase< T >::insert;
public:
virtual bool insert( T* d, char const* ) = 0;
};

template < typename T >
class ManagerImpl : public ManagerInterface< T >
{
using ManagerInterface< T >::insert;
public:
bool insert( T* d, char const* );
};

struct X { };
ManagerImpl m;


$ g++ -O2 -Wall -Woverloaded-virtual -c bug.cpp -o /dev/null

bug.cpp: In instantiation of 'ManagerImpl':
bug.cpp:24:   instantiated from here
bug.cpp:4: error: 'void ManagerBase::insert(T*) [with T = X]' is
inaccessible
bug.cpp:17: error: within this context


-- 
   Summary: 4.4 reject code accepted by 4.3 and comeau.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net


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

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2009-02-23 21:24 ---
Subject: Bug 38880

Author: jason
Date: Mon Feb 23 21:23:58 2009
New Revision: 144395

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144395
Log:
PR c++/38880
* varasm.c (initializer_constant_valid_p) [PLUS_EXPR]: Check
narrowing_initializer_constant_valid_p.
(narrowing_initializer_constant_valid_p): Don't return
null_pointer_node for adding a pointer to itself.

Added:
trunk/gcc/testsuite/g++.dg/init/static-init1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/const7.C
trunk/gcc/varasm.c


-- 


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

[Bug c/33466] mixed-case suffix for decimal float constants

[joseph at codesourcery dot com]

--- Comment #8 from joseph at codesourcery dot com  2009-02-23 21:43 ---
Subject: Re:  mixed-case suffix for decimal float constants

On Mon, 23 Feb 2009, janis at gcc dot gnu dot org wrote:

> Modified:
> branches/c-4_5-branch/gcc/testsuite/ChangeLog
> branches/c-4_5-branch/libcpp/ChangeLog

You should be using ChangeLog.c45 on the branch, not ChangeLog, to avoid 
gratuitous merge conflicts when I merge from trunk.


-- 


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

[Bug other/21071] libtool doesn't use just built libunwind

[sje at cup dot hp dot com]

--- Comment #4 from sje at cup dot hp dot com  2009-02-23 22:21 ---
I think this has been fixed by the updates of libtool.  At least I don't see it
in my ToT build.  HJ, are you still seeing this?  Can we close this defect?


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug c++/36411] [4.4 regression] ICE with invalid template template parameter

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-02-23 22:35 ---
Subject: Bug 36411

Author: hjl
Date: Mon Feb 23 22:34:50 2009
New Revision: 144396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144396
Log:
gcc/cp

2009-02-23  H.J. Lu  

PR c++/36411
* pt.c (coerce_template_template_parms): Return 0 if parameter
is error_mark_node.

gcc/testsuite/

2009-02-23  H.J. Lu  

PR c++/36411
* g++.dg/template/void14.C: New.

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


-- 


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

[Bug c++/36411] [4.4 regression] ICE with invalid template template parameter

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-23 22:35 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/21071] libtool doesn't use just built libunwind

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-23 22:38 ---
Fixed as of revision 144386.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

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


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

[Bug target/39283] New: volatile data types ignore __attribute__ ((__aligned ...))

[hp at gcc dot gnu dot org]

Maybe there are two bugs here.

#include 

typedef int ix __attribute__ ((__aligned__ (16)));
typedef volatile int vx __attribute__ ((__aligned__ (16)));

ix ix1 = __alignof__ (ix);
ix ix2 = __alignof__ (ix1);
vx vx1 = __alignof__ (vx);
vx vx2 = __alignof__ (vx1);

int main(void)
{
  printf ("ix1: %d, ix2: %d, vx1: %d, vx2: %d\n",
  ix1, ix2, vx1, vx2);
  return ix1 == ix2 && ix1 == vx1 && ix1 == vx2 ? 0 : 1;
}

For i686-pc-linux-gnu, observe 16, 16, 4, 4 for the above program.  That's by
itself surprising: the "volatile" specifier seems to nullify the attribute
specifier.

For crisv32-axis-linux-gnu it's even worse: it's 16, 16, 1, 4 at -O0, but 16,
16, 4, 4 at -O2.  Bother.


-- 
   Summary: volatile data types ignore __attribute__ ((__aligned
...))
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: crisv32-axis-linux-gnu, i686-pc-linux-gnu


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

[Bug c/39284] New: Computed gotos combined too aggressively

[jyasskin at gmail dot com]

The following uses a file "ceval.i" that I'll upload shortly and a nightly
build of gcc-4.4.0-20090223. The file is a version of Python's core
interpretation loop modified to use computed gotos in order to help the
processor's branch predictor do a better job than with a switch statement.
However, gcc combines the computed gotos into only a few instructions,
producing a result nearly as bad as the switch.

The computed gotos are all of the form "goto *next_label;". About half of the
instances counted are reachable, as measured by the asm volatile farther down.
$ grep -c -F 'goto *next_label' ceval.i
256

I compile with -fno-gcse because
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#index-fgcse-646
says it helps and with "--param max-goto-duplication-insns=10" because
Diego Novillo suggested tweaking that parameter.
$ gcc-4.4 -m32  -pthread  -fno-strict-aliasing -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fno-gcse --param max-goto-duplication-insns=10  -S -dA
ceval.i -o ceval.s
$ egrep -c 'jmp[[:space:]]*\*' ceval.s
4


I tried to make the common instruction sequence leading up to the indirection
jump shorter by putting an asm volatile before it, but that didn't work. You
can see the result by running:

$ sed 's!goto \*next_label!asm volatile ("/* Computed goto */":::"memory");goto
*next_label!' < ceval.i > ceval-asm.i
$ gcc-4.4 -m32  -pthread  -fno-strict-aliasing -g -fwrapv -O3 -fno-gcse --param
max-goto-duplication-insns=10  -S -dA ceval-asm.i -o ceval-asm.s
$ egrep -c 'Computed goto' ceval-asm.s
130
$ egrep -c 'jmp[[:space:]]*\*' ceval-asm.s
4


One of the relevant bits of assembly (search for "Computed goto" in
ceval-asm.s) is:

.L1125:
# basic block 66
.LBE835:
# ../src/Python/ceval.c:1000
.loc 1 1000 0
jmp *-72(%ebp)
.LVL558:
.p2align 4,,7
.p2align 3
.L1433:
# basic block 67

...

# basic block 114
#APP
# 11 "../src/Include/ceval-vm.i" 1
/* Computed goto */
# 0 "" 2
#NO_APP
movl%esi, %ebx
.LVL599:
.p2align 4,,7
.p2align 3
.L484:
# basic block 115
# ../src/Python/ceval.c:1000
.loc 1 1000 0
movl$1, %eax
.LVL600:
movl%ebx, %esi
.LVL601:
jmp .L1125

The documentation for max-goto-duplication-insns says:

The maximum number of instructions to duplicate to a block that jumps to a
computed goto. To avoid O(N^2) behavior in a number of passes, GCC factors
computed gotos early in the compilation process, and unfactors them as late as
possible. Only computed jumps at the end of a basic blocks with no more than
max-goto-duplication-insns are unfactored. The default value is 8. 

Since .L1125 and basic block 66 have only a single instruction, the computed
goto should have been unfactored.

$ gcc-4.4 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/dnovillo/perf/sbox/gcc/local.x86_64/src/configure
--prefix=/home/dnovillo/perf/sbox/gcc/local.x86_64/inst
--srcdir=/home/dnovillo/perf/sbox/gcc/local.x86_64/src
--with-gmp=/home/dnovillo/i686 --with-mpfr=/home/dnovillo/i686
--build=i686-pc-linux-gnu --enable-languages=c++,fortran,objc,obj-c++
Thread model: posix
gcc version 4.4.0 20090223 (experimental) (GCC)


-- 
   Summary: Computed gotos combined too aggressively
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyasskin at gmail dot com


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

[Bug c/39283] volatile data types ignore __attribute__ ((__aligned ...))

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-23 22:43 ---
This works correctly with the C++ front-end:

[dhcp-10-98-10-23:~] apinski% ~/local-gcc/bin/gcc t.c
[dhcp-10-98-10-23:~] apinski% ./a.out
ix1: 16, ix2: 16, vx1: 4, vx2: 4
[dhcp-10-98-10-23:~] apinski% ~/local-gcc/bin/g++ t.c
./[dhcp-10-98-10-23:~] apinski% ./a.out
ix1: 16, ix2: 16, vx1: 16, vx2: 16


Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |c
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||3.3 4.0.2 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-02-23 22:43:50
   date||


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

[Bug c/39284] Computed gotos combined too aggressively

[jyasskin at gmail dot com]

--- Comment #1 from jyasskin at gmail dot com  2009-02-23 22:44 ---
Created an attachment (id=17354)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17354&action=view)
ceval.i


-- 


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

[Bug c/39283] volatile data types ignore __attribute__ ((__aligned ...))

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-02-23 22:45 ---
So the cris problem with 1 vs 4 might be a different issue but the C front-end
does something incorrectly anyways.


-- 


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

[Bug middle-end/39284] Computed gotos combined too aggressively

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-02-23 22:46 ---
This is by design; GCSE is the one which pulls back the computed gotos IIRC.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


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

[Bug c/39283] volatile data types ignore __attribute__ ((__aligned ...))

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2009-02-23 22:48 ---
(In reply to comment #2)
> So the cris problem with 1 vs 4 might be a different issue but the C front-end
> does something incorrectly anyways.

I was assuming it's the same basic problem, if nothing else that assumption
simplified bug-reporting. :) But sure, middle-end instead of target is then
more consistent.


-- 


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

[Bug middle-end/39284] Computed gotos combined too aggressively

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-02-23 22:48 ---
It says may but not will get better performance.


-- 


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

[Bug c/39283] volatile data types ignore __attribute__ ((__aligned ...))

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2009-02-23 22:56 ---
(In reply to comment #3)
> But sure, middle-end instead of target is then
> more consistent.

...or "c".  Whatever!


-- 


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

[Bug middle-end/39284] Computed gotos combined too aggressively

[jyasskin at gmail dot com]

--- Comment #4 from jyasskin at gmail dot com  2009-02-23 22:58 ---
Taking out -fno-gcse doesn't change the result.

$ gcc-4.4 -m32  -pthread  -fno-strict-aliasing -g -fwrapv -O3 --param
max-goto-duplication-insns=10  -S -dA ceval.i -o ceval.s
$ egrep -c 'jmp[[:space:]]*\*' ceval.s
4


-- 


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

[Bug middle-end/39284] Computed gotos combined too aggressively

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2009-02-23 23:19 ---
Should unfactor.  We have pass_duplicate_computed_gotos for this.  We should
look into this, see why it doesn't work.

Someone added a "optimize_for_size_p()" check in duplicate_computed_gotos(). 
That is just *stupid*.  If there should be a check like that, it should be per
function, not per basic block.  I bet that's the cause.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-23 23:19:12
   date||


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[john dot carter at tait dot co dot nz]

--- Comment #7 from john dot carter at tait dot co dot nz  2009-02-23 23:53 
---
R Guenther said...
>  (int)u1 == (int)(u8_t)(~(int)u2)
>
>  that we do not warn for the first case is because it is optimized to
>u1 == ~u2 before.
>
>   Why do you think the warning is incorrect?
---

I would expect 

  u2 to be promoted to a 4 byte int

  ~ to do the ones complement on a 4 byte int

  (unsigned char)~u2 to truncate to one byte discarding the most significant 3
bytes

  and then the result get promoted to an int to evaluate the ==

ie. The cast cannot get optimized away, it's not a null op, it discards the
most significant bytes. 

ie. (int)(unsigned char)~(int)u2 is not equivalent to
~(int)u2

ie. This is a bug


-- 


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

[Bug rtl-optimization/30688] Branch registers loaded too late on ia64

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2009-02-24 00:01 ---
More work is needed then just setting flag_branch_target_optimize{,2}, we need
to define TARGET_BRANCH_TARGET_REGISTER_CLASS (return BR_REGS) and 
TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (return 1) but even then it doesn't
seem to help.  I think bt-load wants to move the load of the branch register up
but is constrained because we load it from a general register and we load the
general register just before loading the branch register.  Unless bt-load tries
to move the load of the general register up it cannot move the load of the
branch register up and I don't think it will try to move the load of the
general register up because that is not what it is designed to do.


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[michael dot malone at tait dot co dot nz]

--- Comment #8 from michael dot malone at tait dot co dot nz  2009-02-24 
00:40 ---
#ifdef UINT
  #include 
  #define TYPE uint16_t
#else
  #define TYPE unsigned short int
#endif

#define VALUE 0xFF

int main(void);

int main() {
   TYPE variable_a = ~VALUE;
   TYPE variable_b = VALUE;
   TYPE result;

   #ifdef ASSIGN
   TYPE tmp = ~variable_a;
   result = (variable_b == tmp);
   #else
   result = (variable_b == (TYPE) ~variable_a);
   #endif

   return 0;
}

Further to John's input, here is a sample program which shows up why this bug
is interesting.  When one uses a typedef'd type, the promoted comparison
warning is displayed.  When one does not, it isn't!

This is not the case for gcc-4.2.3 -both variants compile without warnings.

The compile commands I used were:
gcc gcc_bug.c -W -Wall -o bug
and
gcc gcc_bug.c -W -Wall -DUINT -o bug


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[michael dot malone at tait dot co dot nz]

--- Comment #9 from michael dot malone at tait dot co dot nz  2009-02-24 
00:43 ---
I forgot to mention, if you assign to an intermediate variable, the warning
also disappears which is the behaviour I would expect from an explicit cast.


-- 

michael dot malone at tait dot co dot nz changed:

   What|Removed |Added

 CC||michael dot malone at tait
   ||dot co dot nz


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

[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2009-02-24 
01:17 ---
The currently proposed patch doesn't solve the problem where 'make -k
check-libiberty' executed at the top level of the build directory results in
gcc being used instead of xgcc. If you execute 'make -k check' in
darwin_objdir/libiberty, you get...

/sw/src/fink.build/gcc44-4.3.999-20090221/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090221/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4.4/i686-apple-darwin10/bin/ -DHAVE_CONFIG_H -g -O2
-fomit-frame-pointer -I..
-I../../../gcc-4.4-20090221/libiberty/testsuite/../../include  -o test-demangle
\
../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c
../libiberty.a

whereas if you execute 'make -k check-libiberty' in darwin_objdir, you get the
incorrect compiler...

gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.4-20090221/libiberty/testsuite/../../include  -o test-demangle
\
../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c
../libiberty.a


-- 


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

[Bug libstdc++/36104] [4.3/4.4 regression] gnu-versioned-namespace is broken

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2009-02-24 01:23 ---

Mine. This is still broken in 4.4.0.

Actually, in 4.2.4 --enable-symvers=gnu-versioned-namespace runs into a build
error in libgomp, where the argument given (gnu-versioned-namespace) does not
match with yes, no, gnu.

The simple patch attached fixes libgomp. I thought I posted this a long time
ago, but looks like it got dropped. 

-benjamin



-benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to fail||4.3.0
  Known to work||4.1.2
   Last reconfirmed|-00-00 00:00:00 |2009-02-24 01:23:57
   date||
Summary|gnu-versioned-namespace is  |[4.3/4.4 regression] gnu-
   |broken in gcc 4.3.0 |versioned-namespace is
   ||broken


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

[Bug libstdc++/36104] [4.3/4.4 regression] gnu-versioned-namespace is broken

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2009-02-24 01:24 ---
Created an attachment (id=17355)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17355&action=view)
enable-symvers=gnu-versioned-namespace vs. libgomp


-- 


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

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2009-02-24 05:14 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/39282] 4.4 reject code accepted by 4.3 and comeau.

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-02-24 05:21 ---
The error is correct: the ManagerInterface::insert using declaration is
private.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/39260] Failed to build lame-3.98-2 source with graphite

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2009-02-24 06:48 ---
Subject: Bug 39260

Author: spop
Date: Tue Feb 24 06:47:56 2009
New Revision: 144403

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144403
Log:
2009-02-23  Sebastian Pop  

PR tree-optimization/39260
* graphite.c (harmful_stmt_in_bb): Stop a SCoP when the basic block
contains a condition with a real type.
(build_scop_conditions_1): Conditions are always last_stmt of a bb.

* gcc.dg/graphite/pr39260.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr39260.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37844] -floop-interchange leads to an ICE

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-02-24 07:04 ---
The bug is fixed on trunk revision 144404.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2009-02-24 07:05 ---

Any chance you could narrow this down? The revision stated as problematic has
nothing to do with libstdc++. The file implicated, cfenv, has not had a change
in 3 months.

What was a revision that worked?

This seems fine, and is after your revision:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02143.html

Was this a temporary blip? If so, please close. If not, please provide some
more detail.


-- 


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