[Bug c++/37365] New: ice for legal C++ code

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package ccscript3-1.0.9
with the GNU C++ compiler version 4.4 snapshot 20080829

The compiler said

testscript.cpp: In function 'virtual void shInterp::waitThread()':
testscript.cpp:213: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Pre-processed source code attached. Flag -O3 required.

Here is valgrind output for the crash.

==17433== Invalid read of size 2
==17433==at 0x926599: decl_function_context (tree.c:)
==17433==by 0x61760C: df_get_entry_block_def_set (df-scan.c:3415)
==17433==by 0x61E497: df_scan_blocks (df-scan.c:637)
==17433==by 0x60D291: rest_of_handle_df_initialize (df-core.c:746)
==17433==by 0x751B21: execute_one_pass (passes.c:1277)
==17433==by 0x751D54: execute_pass_list (passes.c:1325)
==17433==by 0x751D6C: execute_pass_list (passes.c:1326)
==17433==by 0x82064B: tree_rest_of_compilation (tree-optimize.c:418)
==17433==by 0x991E6F: cgraph_expand_function (cgraphunit.c:1039)
==17433==by 0x993BDC: cgraph_optimize (cgraphunit.c:1101)
==17433==by 0x4A0714: cp_write_global_declarations (decl2.c:3608)
==17433==by 0x7D2DD6: toplev_main (toplev.c:979)
==17433==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: ice for legal C++ code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c++/37365] ice for legal C++ code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-09-04 08:05 ---
Created an attachment (id=16218)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16218&action=view)
C++ source code


-- 


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

[Bug c++/37366] New: ice for legal C++ code

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package cln-1.1.13
with the GNU C++ compiler version 4.4 snapshot 20080829

The compiler said

./base/output/cl_output_dec.cc: In function 'void
cln::fprintdecimal(std::ostream&, long int)':
./base/output/cl_output_dec.cc:33: error: non-trivial conversion at assignment
D.24223
x
D.24223 = -x;

./base/output/cl_output_dec.cc:33: internal compiler error: verify_gimple
failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Pre-processed source code attached. No flag required.


-- 
   Summary: ice for legal C++ code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c++/37366] ice for legal C++ code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-09-04 08:09 ---
Created an attachment (id=16219)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16219&action=view)
C++ source code


-- 


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

[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2008-09-04 09:12 
---
Jonathan, while we are at it, can we also unify tr1/boost_sp_shared_count.h and
tr1/boost_shared_ptr.h, likewise for bits/boost_sp_shared_count.h and
bits/boost_shared_ptr.h?

Moreover, for the sake of clarity, we could as well complete the split and
duplicate tr1_impl/boost_sp_counted_base.h. 

Finally, with all due respect, all those boost_* prefixes in the names, given
the proper copyrights that we have in the files, seem redundant to me.

Can you work on the above? Just let me know, I can try to find the time...


-- 


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

[Bug tree-optimization/37354] [4.4 Regression] ICE: in find_func_aliases, at tree-ssa-structalias.c:3906

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-09-04 09:28 ---
./cc1plus -quiet t.ii -O
t.ii: In function 'void AlsaDriver1()':
t.ii:8: error: non-register as LHS of unary operation
m_pFunction = (struct GenericMemFuncType) D.2092;

t.ii:8: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


invalid gimple which obviously confuses us.  We should use VIEW_CONVERT_EXPR
here instead.  I'm unsure if we want to fix this up during gimplification
or in the frontends though.

Sill, mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-09-04 02:27:57 |2008-09-04 09:28:21
   date||


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-09-04 09:44 ---
Andrey, this is likely due to the selective scheduler merge.  Can you
investigate or delegate?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||abel at ispras dot ru


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

[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/37364] [4.4 Regression] IRA generates ineffient code

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-09-04 09:49 ---
*** Bug 37365 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug c++/37365] ice for legal C++ code

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-04 09:49 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/37331] ICE trying to compile /dev/null

[patriciak784-gccmainling at yahoo dot de]

--- Comment #7 from patriciak784-gccmainling at yahoo dot de  2008-09-04 
09:50 ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > ... a self compiled gcc 4.3.1 ...
> > > 
> > > Scary ;)
> > > 
> > What did you expect, Paolo?
> 
> He was joking as we all compile GCC by using GCC and not by "hand".  I would 
> be
> scary if you actually did compile GCC by hand translating it.
> 
Now I understand :-)


-- 


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

[Bug c++/37366] ice for legal C++ code

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-04 09:51 ---
Likely a dup of PR37289 which was fixed on Aug 31st.  I cannot reproduce
with current trunk.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/37289] [4.4 Regression] ICE after non-trivial conversion at assignment

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-09-04 09:51 ---
*** Bug 37366 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

Two porting issues -- Temporary classes and void pointers

[Alberto23]

Well, I am porting C++ code from Visual Studio C++ to GCC.

I found two main issues that bother me enough to write about them.

(1.0) Temporary classes

 {buf << class_A(); }   // does not compile on GCC,
yak
 {Class_A tmp;buf << tmp; }   // compiles on GCC

So it seems GCC does not want us to use direct notation of temporary
classes.
Consider: { buf << A() << B() << C(); } which will not be allowed by the
samaritan


(2.0) void pointers

{  char* ap;   void* vp = ap; } // does not compile on GCC, yak
  // but in VS++ void*
can receive all pointers.

 { vp = (void*) ap; }  // the good samaritan wants you to cast even the
amorphic void*; yak


If you know of some way to teach the GCC to work like VS++ with these issues
-- would be delighted to hear from you.

-- 
View this message in context: 
http://www.nabble.com/Two-porting-issuesTemporary-classes-and-void-pointers-tp19307106p19307106.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug other/37367] New: gcc-4.4 speed regression

[tim at klingt dot org]

using a small piece of code of a digital filter, i was trying to benchmark
several looping constructs. on x86_64 the following code was running 5% faster
with g++-4.3 than with g++-4.4:

float __attribute__ ((noinline)) bench_5(float * out_sample, int n)
{
float b1 = std::cos(0.01);
float y1 = 0;
float y2 = 1;

do
{
float y0 = b1 * y1 - y2;
*out_sample++ = y0;
--n;
}
while (__builtin_expect(n!=0, 1));
}

[EMAIL PROTECTED]:~$ g++-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-0ubuntu3'
--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-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-0ubuntu3) 

[EMAIL PROTECTED]:~$ g++-4.4 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../gcc-4.4-20080815/configure
--enable-languages=c,c++,fortran,objc,obj-c++ --enable-shared
--with-system-zlib --enable-mpfr --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/local/include/c++/4.4 --program-suffix=-4.4
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
Thread model: posix
gcc version 4.4.0 20080815 (experimental) (GCC) 

the command line to compile the code was:
g++ benchmarks/loop_benchmark.cpp -O3 -lrt -march=core2

the difference in the machine code is the order of two subl and leal
instructions:
*** 340,347 
addq$16, %rax
cmpl%r8d, %edx
jb  .L61
-   subl%r9d, %esi
leal0(,%r9,4), %eax
mov %eax, %eax
addq%rax, %rcx
cmpl%r9d, %r10d
--- 340,347 
addq$16, %rax
cmpl%r8d, %edx
jb  .L61
leal0(,%r9,4), %eax
+   subl%r9d, %esi
mov %eax, %eax
addq%rax, %rcx
cmpl%r9d, %r10d
***

since i read that gcc-4.4 is supposed to be aimed at code optimization, i
thought it may be interesting to report it ...
the complete code can be found at http://tinyurl.com/5socts


-- 
   Summary: gcc-4.4 speed regression
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-09-04 10:01 ---
Confirmed that the patch fixes the problems for cris-elf for trunk too.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-04 10:01:47
   date||


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

[Bug tree-optimization/37368] New: [4.4 Regression] Segfault in remove_unused_locals

[tbm at cyrius dot com]

With current trunk (revision 139978)

(sid)743:[EMAIL PROTECTED]: ..4.3-2008-09-04-r139978/gcc] ./cc1 -quiet -O
~/xserver-xorg-video-mga.i
../../src/mga_dga.c: In function 'MGASetupDGAMode':
../../src/mga_dga.c:92: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.4 Regression] Segfault in remove_unused_locals
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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

[Bug tree-optimization/37368] [4.4 Regression] Segfault in remove_unused_locals

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2008-09-04 10:04 ---
Program received signal SIGSEGV, Segmentation fault.
remove_unused_locals () at gcc/tree-ssa-live.c:589
589 var_ann (t)->used = false;
(gdb) where
#0  remove_unused_locals () at gcc/tree-ssa-live.c:589
#1  0x006404b5 in execute_function_todo (data=) at
gcc/passes.c:951
#2  0x0064071f in execute_todo (flags=205336536) at gcc/passes.c:1024
#3  0x0064090b in execute_one_pass (pass=0x101b200) at
gcc/passes.c:1209
#4  0x00640c35 in execute_pass_list (pass=0x101b200) at
gcc/passes.c:1326
#5  0x007374bc in tree_rest_of_compilation (fndecl=0x7fa70c5d4c00) at
gcc/tree-optimize.c:418
#6  0x008b0640 in cgraph_expand_function (node=0x7fa70c5d4d00) at
gcc/cgraphunit.c:1038
#7  0x008b23b4 in cgraph_optimize () at gcc/cgraphunit.c:1097
#8  0x004169c3 in c_write_global_declarations () at gcc/c-decl.c:8080
#9  0x006e872f in toplev_main (argc=, argv=)
at gcc/toplev.c:979
#10 0x7fa70cebf1a6 in __libc_start_main () from /lib/libc.so.6
#11 0x004044d9 in _start ()
(gdb)


-- 


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

[Bug tree-optimization/37368] [4.4 Regression] Segfault in remove_unused_locals

[tbm at cyrius dot com]

--- Comment #2 from tbm at cyrius dot com  2008-09-04 10:24 ---
Created an attachment (id=16220)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16220&action=view)
Preprocessed code


-- 


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

[Bug tree-optimization/37368] [4.4 Regression] Segfault in remove_unused_locals

[tbm at cyrius dot com]

--- Comment #3 from tbm at cyrius dot com  2008-09-04 10:24 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */

static int
FindSmallestPitch (int i)
{
  int Pitches1[5];
  int *linePitches = ((void *) 0);
  switch (i)
  {
case 0x0519:
  linePitches = Pitches1;
  }
  return *linePitches;
}
void MGASetupDGAMode (int i)
{
  FindSmallestPitch (i);
}


-- 


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

[Bug tree-optimization/37368] [4.4 Regression] Segfault in remove_unused_locals

[tbm at cyrius dot com]

--- Comment #4 from tbm at cyrius dot com  2008-09-04 10:25 ---
Drop the "static" from the declaration of FindSmallestPitch() and you get:

(sid)1519:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -Wall 
-O -c
mini.c
mini.c: In function 'FindSmallestPitch':
mini.c:5: internal compiler error: in make_decl_rtl, at varasm.c:1297
Please submit a full bug report,


-- 


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

[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

[hubicka at gcc dot gnu dot org]

--- Comment #7 from hubicka at gcc dot gnu dot org  2008-09-04 10:31 ---
Subject: Bug 37345

Author: hubicka
Date: Thu Sep  4 10:30:26 2008
New Revision: 139980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139980
Log:
PR tree-optimization/37345
PR tree-optimization/37358
PR tree-optimization/37357
* tree.c (build_function_type_skip_args): Build distinct type copy;
set TYPE_CONTEXT.
(build_function_decl_skip_args): Set type of new decl not orig decl;
clear DECL_VINDEX for methods turned into functions.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr37345.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug middle-end/37357] [4.4 Regression] Revision 139772 breaks C++

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2008-09-04 10:31 ---
Subject: Bug 37357

Author: hubicka
Date: Thu Sep  4 10:30:26 2008
New Revision: 139980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139980
Log:
PR tree-optimization/37345
PR tree-optimization/37358
PR tree-optimization/37357
* tree.c (build_function_type_skip_args): Build distinct type copy;
set TYPE_CONTEXT.
(build_function_decl_skip_args): Set type of new decl not orig decl;
clear DECL_VINDEX for methods turned into functions.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr37345.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug middle-end/37358] [4.4 Regression] IPA-CP generates duplicated symbols at -O3

[hubicka at gcc dot gnu dot org]

--- Comment #6 from hubicka at gcc dot gnu dot org  2008-09-04 10:31 ---
Subject: Bug 37358

Author: hubicka
Date: Thu Sep  4 10:30:26 2008
New Revision: 139980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139980
Log:
PR tree-optimization/37345
PR tree-optimization/37358
PR tree-optimization/37357
* tree.c (build_function_type_skip_args): Build distinct type copy;
set TYPE_CONTEXT.
(build_function_decl_skip_args): Set type of new decl not orig decl;
clear DECL_VINDEX for methods turned into functions.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr37345.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

[hubicka at gcc dot gnu dot org]

--- Comment #8 from hubicka at gcc dot gnu dot org  2008-09-04 10:37 ---
Fixed by my patch


-- 

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=37345

[Bug middle-end/37358] [4.4 Regression] IPA-CP generates duplicated symbols at -O3

[hubicka at gcc dot gnu dot org]

--- Comment #7 from hubicka at gcc dot gnu dot org  2008-09-04 10:37 ---
Fixed by my patch.


-- 

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=37358

[Bug middle-end/37357] [4.4 Regression] Revision 139772 breaks C++

[hubicka at gcc dot gnu dot org]

--- Comment #5 from hubicka at gcc dot gnu dot org  2008-09-04 10:38 ---
FIxed.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37343] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

[hubicka at gcc dot gnu dot org]

--- Comment #6 from hubicka at gcc dot gnu dot org  2008-09-04 10:47 ---
Subject: Bug 37343

Author: hubicka
Date: Thu Sep  4 10:45:57 2008
New Revision: 139983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139983
Log:
PR middle-end/37343
* tree-switch-conversion.c (check_final_bb): Accept only IP
invariants.
* g++.dg/torture/pr37343.C New file.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr37343.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c


-- 


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

[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2008-09-04 10:52 ---
Ugly -fPIC friendly workaround would be to add runtime initialization.  I.E.

if (!initialized)
 {populate my array; initialized = true;}
that would still allow conversion to happen and generate better code than
expand_switch.


-- 


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

[Bug c/37369] New: ice for legal C code

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package enlightenment-0.16.8.12-15
with the GNU C compiler version 4.4 snapshot 20080829

The compiler said

backgrounds.c: In function 'BackgroundGetUniqueString':
backgrounds.c:2742: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Pre-processed source code attached. Flag -O2 required.

Here is a valgrind stack back trace

==6993== Invalid read of size 1
==6993==at 0x875CB0: cgraph_expand_function (cgraphunit.c:1043)
==6993==by 0x877A1C: cgraph_optimize (cgraphunit.c:1101)
==6993==by 0x416782: c_write_global_declarations (c-decl.c:8055)
==6993==by 0x6B6C16: toplev_main (toplev.c:979)
==6993==by 0x52D3435: (below main) (in /lib64/libc-2.8.so)
==6993==  Address 0x2 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: ice for legal C code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c/37369] ice for legal C code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-09-04 11:54 ---
Created an attachment (id=16221)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16221&action=view)
C source code


-- 


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

[Bug c++/37370] New: ice for legal C++ code

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package epos-2.5.37
with the GNU C++ compiler version 4.4 snapshot 20080829

The compiler said

slowstring.h: In member function 'CBasicString CBasicString::substr(int,
int) const [with T = char]':
slowstring.h:232: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Pre-processed source code attached. Flag -O3 required.

Here is a valgrind stack back trace

==7011== Invalid read of size 2
==7011==at 0x62B705: decl_class_context (dwarf2out.c:5777)
==7011==by 0x63F7E8: dwarf2out_abstract_function (dwarf2out.c:13361)
==7011==by 0x641D24: gen_decl_die (dwarf2out.c:15111)
==7011==by 0x686F52: rest_of_handle_final (final.c:4163)
==7011==by 0x751B21: execute_one_pass (passes.c:1277)
==7011==by 0x751D54: execute_pass_list (passes.c:1325)
==7011==by 0x751D6C: execute_pass_list (passes.c:1326)
==7011==by 0x751D6C: execute_pass_list (passes.c:1326)
==7011==by 0x82064B: tree_rest_of_compilation (tree-optimize.c:418)
==7011==by 0x991E6F: cgraph_expand_function (cgraphunit.c:1039)
==7011==by 0x993BDC: cgraph_optimize (cgraphunit.c:1101)
==7011==by 0x4A0714: cp_write_global_declarations (decl2.c:3608)
==7011==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: ice for legal C++ code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c++/37370] ice for legal C++ code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-09-04 11:56 ---
Created an attachment (id=16222)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16222&action=view)
C++ source code


-- 


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

[Bug tree-optimization/37368] [4.4 Regression] Segfault in remove_unused_locals

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-09-04 11:57 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/37343] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-09-04 11:57 ---
*** Bug 37368 has been marked as a duplicate of this bug. ***


-- 


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[abel at ispras dot ru]

--- Comment #2 from abel at ispras dot ru  2008-09-04 12:06 ---
> Andrey, this is likely due to the selective scheduler merge.  Can you
> investigate or delegate?
We couldn't reproduce this with a cross from x86_64.  Also,  Adam Nemet fixed
the problem with MIPS/sel-sched bootstrap
(http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00152.html) -- the mail mentions
that he reached stage3 with his patch of 139918, this bug is of 139940.  Can
this be reproduced natively on MIPS with 139918?  


-- 


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

[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-09-04 12:20 ---
*** Bug 37370 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/37370] ice for legal C++ code

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-04 12:20 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/37369] ice for legal C code

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-04 12:21 ---
I can not reproduce this with the current trunk.  I suggest you update your
snapshot before filing more bugreports.  Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

[hjl dot tools at gmail dot com]

--- Comment #30 from hjl dot tools at gmail dot com  2008-09-04 13:07 
---
(In reply to comment #29)
> Subject: Re:  [4.4 Regression] Bootstrap failure compiling libgcc
> 
> I think you meant to respond to Eric instead of me.  Vlad's
> patch fixed the original problem for me and Eric, but Eric
> is now see a new problem.
> 

ira-merge branch has additional IRA fixes which may solve Eric's
problem if it is caused by IRA merge. I'd like to make sure that
his problem isn't IRA related.


-- 


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

[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION

[domob at gcc dot gnu dot org]

-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-07-06 19:48:56 |2008-09-04 13:12:06
   date||


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

--- Comment #29 from hjl dot tools at gmail dot com  2008-09-04 13:34 
---
On ira-merge branch at revision 139972, there are no regression
on Linux/ia32 and Linux/ia64. Linux/x86-64 has regressions:

+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2

It is tracked by PR 37364.


-- 


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

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

--- Comment #3 from patriciak784-gccmainling at yahoo dot de  2008-09-04 
13:35 ---
I did examine both problems a bit further.
If I understand correctly what is happening, there is the object parse_in which
is, during program flow, passed to preprocess_file as argument pfile.
An object of type cpp_reader seems to have several buffers which are organized
as a stack. The topmost buffer worked is saved in ->buffer.
And now preprocess_file gets the cpp_reader object and as 'flag_no_output' is
true (I don't know why...) the function tries to pop all buffers from the
buffer stack and by popping them does some processing on them (by doing a loop
as long as there is a previous buffer pfile->buffer->prev and then doing
another call to cpp_scan_nooutput for the last buffer).
All files seem to have at least one buffer but processing "/dev/null"
temporarily creates a buffer but unallocates it beacause EOF is reached before
calling preprocess_file. 
And this function does not check if there _is_ a buffer pfile->buffer != NULL
and therefore both commands fail.
At the moment the important lines (file gcc/c-ppoutput.c lines 71..77) look
like this:
  if (flag_no_output)
{
  /* Scan -included buffers, then the main file.  */
  while (pfile->buffer->prev)
cpp_scan_nooutput (pfile);
  cpp_scan_nooutput (pfile);
}
I did try
  if (flag_no_output)
{
  if(pfile->buffer)
 {
  /* Scan -included buffers, then the main file.  */
  while (pfile->buffer->prev)
cpp_scan_nooutput (pfile);
  cpp_scan_nooutput (pfile);
 }
}
And it does indeed work - no segfaults any more! :->
This part can perhaps even be optimized a bit:
  if (flag_no_output)
{
  /* Scan -included buffers, then the main file.  */
  while(pfile->buffer)
cpp_scan_nooutput (pfile);
}
I didn't test that one yet but I suppose it works.
I suppose someone should run the testsuite and post the results...

And one more thing:
running 'gcc -c out.o -x c /dev/null' now prints:
cc1: warning: nul.gch: too short to be a PCH file (nul.gch probably because on
windows /dev/null is internally converted to the system file NUL which does the
same this as /dev/null on *nix)
Do you think this output is the right thing to do? Or is that a bug, too?
At least out.o is an empty object file.
and running 'gcc -E -dM -fpreprocessed - < /dev/null' doesn't print anything.


-- 


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

[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr

[jwakely dot gcc at gmail dot com]

--- Comment #15 from jwakely dot gcc at gmail dot com  2008-09-04 13:52 
---
Sure, I can do that


-- 


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

[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr

[paolo dot carlini at oracle dot com]

--- Comment #16 from paolo dot carlini at oracle dot com  2008-09-04 14:00 
---
Great, thanks a lot again.


-- 


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[abel at ispras dot ru]

--- Comment #3 from abel at ispras dot ru  2008-09-04 14:34 ---
This does not fail on a cross for us with 139918.  


-- 


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

[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-09-04 14:42 ---
No regressions for native x86_64-unknown-linux-gnu.


-- 


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[daney at gcc dot gnu dot org]

--- Comment #4 from daney at gcc dot gnu dot org  2008-09-04 14:49 ---
You will note that I configured with --with-arch=sb1.

This in turn causes cc1 to be invoked with -march=sb1

I will attempt to test with a cross build.

My bootstrap gcc is: gcc (GCC) 4.4.0 20080223 (experimental) [trunk revision
132568]

There is the possibility that the stage1 compiler is being miscompiled, so I
will try another bootstrap with: gcc (Debian 4.3.1-8) 4.3.1 to see if that
changes anything.


-- 


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

[Bug c/37371] New: wrong initialisation of an array of ptrs

[skylendar at yahoo dot com]

First of all, thanx to all the gcc team for their fantastic job.

gcc: 4.3.2 bootstraped with CFLAGS=-O2 -pipe -march=athlon -fomit-frame-pointer

Target: linux 2.6.25 on mandriva 2008.0

Problem: the following code works fine with low optimization -O0, -O1,
but gives fancy results with -O2, -O3. No problem with compilation.

The fill function fills up and array of char * with char* provided as
arguments.
The arguments are 0L terminated.

The example program should produce:

a
b
c

Thanx beforehand for your attention.

...

#include 

void fill(char *t[], char *c, ...)
{
  char **ptr = &c;
  while(*ptr)
*t++ = *ptr++;
}

int main()
{
int i;
char *abc[3];
fill(abc, "a", "b", "c", 0L);
for(i = 0; i < 3; i++)
printf("%s\n", abc[i]);
}


-- 
   Summary: wrong initialisation of an array of ptrs
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skylendar at yahoo dot com


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-09-04 14:53 ---
As on the trunk we are now feeding out-of-SSA with random dead statements
at -O0 we should look into this.  Or schedule a DCE pass before it if it
cannot cope with dead statements.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
   Priority|P2  |P1


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

[hjl dot tools at gmail dot com]

--- Comment #31 from hjl dot tools at gmail dot com  2008-09-04 14:53 
---
I tried i586-linux with ira-merge branch. It built libgcc fine.
So the problem is either fixed on ira-merge branch or it isn't
caused by IRA merge.


-- 


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

[Bug c/37371] wrong initialisation of an array of ptrs

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-09-04 14:55 ---
You should include  and use va_XXX macros.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-09-04 14:58 ---
I would suggest to try ira-merge branch to rule out any IRA related
problems.


-- 


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

[Bug middle-end/37044] Heisenbug: SVN of gcc throws internal compiler error on PPC

[contact at multimedia dot cx]

--- Comment #5 from contact at multimedia dot cx  2008-09-04 15:13 ---
Perhaps the change should have, but it didn't. The problem still manifests with
SVN 139974 (latest as of yesterday).


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl at gcc dot gnu dot org]

--- Comment #30 from hjl at gcc dot gnu dot org  2008-09-04 15:47 ---
Subject: Bug 37243

Author: hjl
Date: Thu Sep  4 15:46:05 2008
New Revision: 139987

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139987
Log:
2008-09-04  H.J. Lu  <[EMAIL PROTECTED]>

PR rtl-optimization/37243
* gfortran.dg/pr37243.f: New.

Added:
trunk/gcc/testsuite/gfortran.dg/pr37243.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37364] [4.4 Regression] IRA generates ineffient code

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-09-04 16:02 ---
"-O2 -march=core2 -fno-ira -fno-regmove" generates

movqx(%rip), %mm0
paddd   y(%rip), %mm0
movq%mm0, -8(%rsp)
movq-8(%rsp), %rax

It seems that regmove isn't effective for IRA.


-- 


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

[Bug middle-end/37372] New: [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge

[grosser at gcc dot gnu dot org]

During SCoP detection we split bbs (e.g. in "scopdet_edge_info"), but the SCoP
detection should only detect SCoPs and not modify anything.
Also it splits bbs in inner loops, that do not need to be splitted.

Bb splitting was introduced to make SCoPs entry/exit defined by a single edge.
That is a great idea to simplify code generation, but we should ensure this in
a later cleanup pass. (May be just before code generation)


-- 
   Summary: [graphite] SCoP detection splits bbs / Define SCoPs with
single entry and exit edge
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: grosser at gcc dot gnu dot org
ReportedBy: grosser at gcc dot gnu dot org


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

[Bug middle-end/37372] [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge

[grosser at gcc dot gnu dot org]

-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||grosser at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-09-04 16:05:31
   date||


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[amacleod at redhat dot com]

--- Comment #8 from amacleod at redhat dot com  2008-09-04 16:09 ---
out of ssa generally expects that there is no dead code. 

I think the original logic was that you never want to generate code for dead
statements, so DCE would be run just before out of ssa.

It assumes any conflicts caused by any copies which will be inserted are
already covered in the conflict graph.  In this particular case, if the PHI
results was live for even a statement or two, it would conflict with the use of
a_lsm.27_5 in the next statement, and then the coalesce would happen with
a_lsm.27_1 instead.  We'd still get the dead copy, but the code would work
fine.

That's a reasonable example of why we don't want to feed dead code into
outofssa. Figuring out which PHI parameter is TRULY available would be a tricky
proposition to catch this case. And its a waste.

So we either run dead code just before out of ssa, or take PHI's with no uses
and discard them at the same time we discard virtual PHIs (this would be
trivial). I wonder if we might eventually find a similar circumstance with a
dead PHI cycle that would not be easy to detect without the same logic as a DCE
tho.

I'd say a DCE pass is generally a better approach, and should be documented as
a requirement, or even wired in.


-- 


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[daney at gcc dot gnu dot org]

--- Comment #6 from daney at gcc dot gnu dot org  2008-09-04 16:12 ---
I get the same ICE using gcc (Debian 4.3.1-8) 4.3.1 as the bootstrap compiler,
so I am going with the theory that the bootstrap compiler is not the cause of
this problem.


-- 


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

[Bug middle-end/37364] [4.4 Regression] IRA generates ineffient code

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-09-04 16:13 ---
(In reply to comment #1)
> "-O2 -march=core2 -fno-ira -fno-regmove" generates
> 
> movqx(%rip), %mm0
> paddd   y(%rip), %mm0
> movq%mm0, -8(%rsp)
> movq-8(%rsp), %rax
> 
> It seems that regmove isn't effective for IRA.
> 

regmove is turned off for IRA. Revert the regmove.c change in
revision 139590

* regmove.c (regmove_optimize): Don't do replacement of output for
IRA.

fixes this regression. Vladimir, IRA should either deal with replacement
of output or let regmove handle it.


-- 


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-09-04 16:17 ---
Thanks for the explanation, for the branch I would recommend an extra DCE
pass right before pass_del_ssa.  On the trunk we need to make sure to run
this at -O0 as well.  Note that the simple DCE can leave dead statements
around, only control-dependent DCE will make sure to not retain any
DCE opportunities.


-- 


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

[Bug preprocessor/37373] New: Variadic macros fail when generated by other macros.

[jkrahn at nc dot rr dot com]

The preprocessor does not parse variadic macros correctly when they are used in
source code generated by other macros. I think that directives within macros
are non-standard, but some standard library functions are implemented as macros
when using FORTIFY_SOURCE, which can cause problems in code that is otherwise
valid.

For example, I am compiling code that uses macros to add extra code for
handling formatted messages in some contexts, similar to the following example:

#define printf(...) printf(stdout,__VA_ARGS__)

#define PRINT_BEGIN(fmt) printf(fmt,
#define PRINT_END)

PRINT_BEGIN("%d")
  100
PRINT_END;


The result is:
tmp.c:9:1: error: unterminated argument list invoking macro "printf"

Obviously, the code can be modified to use macros without splitting the
printf() call into separate macro evaluations. However, given that the code is
valid, it would be nice if system headers could use variadic macros without
breaking valid code.

For now, this may only happens when invoking non-standard features like
FORTIFY_SOURCE, and not with standard system headers. If so, may really be a
feature request, depending on whether those features are intended to be free of
side effects.


-- 
   Summary: Variadic macros fail when generated by other macros.
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkrahn at nc dot rr dot com


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

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

--- Comment #4 from patriciak784-gccmainling at yahoo dot de  2008-09-04 
16:38 ---
Now I know why gcc complains about a misformed pch file nul.gch!
Checking if a file named NUL plus any extension exists, will always return that
it exists because I did this on windows! open will not open a file on the disk
but the NUL device which is the same as /dev/null on *nix.
And of course nul.gch is no valid pch!

So this warning is a windows specific "bug" but I don't think it is necessary
to provide a workaround in gcc as long as this doesn't break anything which is
the case at least for me.


-- 


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[w dot doeringer at fh-worms dot de]

--- Comment #14 from w dot doeringer at fh-worms dot de  2008-09-04 16:48 
---
Created an attachment (id=16223)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16223&action=view)
compiler error on valid code

might point to the problem causing the seg fault


-- 


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[amacleod at redhat dot com]

--- Comment #10 from amacleod at redhat dot com  2008-09-04 16:51 ---
As long as it removes any dead PHIs, it would be sufficient. Other types of
dead statements don't have 'unexpected' side effects across basic block
boundaries, and should be handled fine. Other than being a waste of effort of
course :-)

A little further thinking leads me to think dead PHI cycles could not produce
this problem. The PHI results would get conflicts since they are live out their
basic blocks. It the lack of any use in this case that is the problem.

But removing a PHI with no uses can easily have ripple effects in that it may
have been the only use of some other PHI, etc, etc.  So we're back to DCE type
work anyway.   


-- 


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

[Bug c++/37374] New: "using" shadows declaration

[kduda at arastra dot com]

The following code (example A) compiles:

  namespace N1 { void f() {} }
  namespace N2 { void f(int) {} using N1::f; }
  main() { N2::f(0); }

But this code does not compile (example B) because the compiler claims there is
no f(int) within N2:

  namespace N1 { void f() {} }
  namespace N2 { void f(int); using N1::f; }
  void N2::f(int) {}
  main() { N2::f(0); }

I do not have the C++ expertise to know whether the "using N1::f" should shadow
the previous use of the unqualified name "f" inside "N2", but I do think that
it should be consistent for function declarations vs function definitions. 
That is, if "using N1::f" should shadow the prior use of "f" within "N2", then
example A should not compile because the N2::f with the (int) overload has been
shadowed.  If "using N1::f" should not shadow the prior use of f within N2,
then example B should compile because N2::f(int) was properly declared in
namespace N2.

Example B used to compile in g++-4.1.2.  It was in upgrading to 4.3.0 that code
in our tree that is like example B suddenly stopped compiling.

I apologize that I do not know what the bug is --- is g++ incorrectly allowing
example A to compile, or is it incorrectly giving an error with example B?   I
do not know, but it seems that one must be wrong.

Also, I apologize in advance if gcc's behavior is correct here, and somehow it
is right that A should compile and B should not.  I find the rules around
unqualified name resolution, "using", and function overloading difficult to
understand.  Any explanation greatly appreciated.

Whatever the result, the workaround is easy of course --- just move the "using
N1::f" before any other use of "f" within N2.  Then there is no question about
what sorts of uses of "f" should be shadowed.

Thanks,
-Ken


-- 
   Summary: "using" shadows declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kduda at arastra dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-09-04 17:14 ---
Shouldn't for this code:

IMPLICIT TYPE(t)(x)
DIMENSION x(:)

x get the implicit type on the DIMENSION statement and this be thus equivalent
to

TYPE(t) :: x
DIMENSION x(:)

(if that's a legal way to specify DIMENSION, I'm not sure)?  Thinking of PR
32095 and without knowing what the standard says about this, I'd suppose it is
so.  This would mean the following is illegal:

IMPLICIT TYPE(t) (x)
DIMENSION x(:)
INTEGER :: x

Is this true?  And is it ok to break code like that (I haven't tested if it's
accepted at the moment)?  If it is, I would suggest to do implicit typing on
DIMENSION statements and try if this solves this bug.


-- 


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[daney at gcc dot gnu dot org]

--- Comment #7 from daney at gcc dot gnu dot org  2008-09-04 17:17 ---
The problem is present in 139918


-- 


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

[Bug c++/37374] "using" shadows declaration

[chris dot fairles at gmail dot com]

--- Comment #1 from chris dot fairles at gmail dot com  2008-09-04 17:33 
---
mainline compiles first snippet fine. second gives:

error: 'void N2::f(int)' should have been declared inside 'N2'

For what its worth msvc 9 and Comeau C/C++ 4.3.10.1 compile both snippets w/o
error. 


-- 


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

[Bug libgomp/36442] libgomp/libssp/libmudflap builds fail when using --with-build-sysroot

[psmith at gnu dot org]

--- Comment #2 from psmith at gnu dot org  2008-09-04 17:34 ---
I tried this with the latest stable, GCC 4.3.2, and I still had the same
failures.


-- 


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

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[daney at gcc dot gnu dot org]

--- Comment #8 from daney at gcc dot gnu dot org  2008-09-04 17:39 ---
It is reproducible in a cross compiler as well.

This is my command line:

/home/daney/gccsvn/mipsel-trunk/gcc/cc1 -fpreprocessed j.i -quiet -march=sb1
-O2 -o j.s

Changing to -march={mips32,mips32r2,r5000} "fixes" the problem.  It seems to be
sb1 specific.


-- 


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

[Bug middle-end/37364] [4.4 Regression] IRA generates ineffient code

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-09-04 17:43 ---
The problem may be in IRA_COVER_CLASSES. -mtune=core2 turns on
TARGET_INTER_UNIT_MOVES, which means move between mmx and 64bit
integer registers is cheaper than load/store. But IRA doesn't
handle it properly.


-- 


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

[Bug middle-end/37364] [4.4 Regression] IRA generates ineffient code

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-09-04 17:54 ---
(In reply to comment #3)
> The problem may be in IRA_COVER_CLASSES. -mtune=core2 turns on
> TARGET_INTER_UNIT_MOVES, which means move between mmx and 64bit
> integer registers is cheaper than load/store. But IRA doesn't
> handle it properly.
> 

Is there a way to tell IRA that moving between 2 register
classes is cheaper than load/store?


-- 


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

[Bug middle-end/37375] New: [graphite] Parameter detection and scev only take a surrounding loop as border

[grosser at gcc dot gnu dot org]

We detect this SCoP: 

for (i ...)
{
  foo(); // Difficult

  // ScoP entry

  for (j ...)
B;

  a = 5 + i;

  for (k ...)
C;

  // SCoP exit
}

To find the parameters we have to "instantiate_scev" for every bb.
"instantiate_scev" requires an argument "outermost_loop" to define,
which loop iterators are constant.

If we use (outermost_loop == j), 'i' would be a parameter for calculations
in B. If we use (outermost_loop == i), 'i' would be an loop iterator.

The only loop in this SCoP, that would contain all statements, is 'i'.
If we use (outermost_loop == i), 'i' is handled like an loop iterator.
So the scev of 'a' is {5, +, 1}_1. This is wrong, as 'i' is a parameter
in our SCoP.

But for statement a, there does not exist any other loop, we could use as
outermost loop.

For C we could use (outermost_loop == k). If C uses 'a' in its scev functions,
'a' will remain a parameter in the scev of 'C'. That is wrong, as 'a' is no
parameter of this SCoP, but is calculated.

A possible solution would be to extend the scev framework.
Instead of outermost_loop we could use:

- "outermost_loop_depth" to define the minimal depth, until loop iterators are
variable. 
With (outermost_loop_depth == 2) loops 'j' and 'k' change, but 'i' not.

- "scev_entry" to define the start if the scev region.


for (i ...)
{

  x = 83 + i;

  par = 52 + x;

  foo(); // Difficult

  // ScoP entry

  for (j ...)
B;

  v = par;

  // SCoP exit
}

The evaluation of v should stop at scev_entry and evaluate to v = {par} and not
continue
to v = {135 + i}.


-- 
   Summary: [graphite] Parameter detection and scev only take a
surrounding loop as border
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: FIXME
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grosser at gcc dot gnu dot org


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

[Bug middle-end/37375] [graphite] Parameter detection and scev only take a surrounding loop as border

[grosser at gcc dot gnu dot org]

-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-09-04 17:55:21
   date||


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

[Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-09-04 18:39 ---
Just for the record, move between MMX and GPR isn't a major issue
since we prefer SSE anyway. If it is the only inter class register
move problem for IRA, I am OK to close it as WONTFIX.


-- 


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

[Bug c++/37376] New: No standard mangling for char16/32_t yet

[jason at gcc dot gnu dot org]

char16_t and char32_t are still mangled as a vendor extension in the 4.4
sources.  This is a blocker for 4.4; we need a standard mangling before it is
released in order to avoid binary incompatibility with future releases.


-- 
   Summary: No standard mangling for char16/32_t yet
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org


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

[Bug c++/37376] No standard mangling for char16/32_t yet

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/37376] No standard mangling for char16/32_t yet

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P3


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[rsandifo at gcc dot gnu dot org]

--- Comment #31 from rsandifo at gcc dot gnu dot org  2008-09-04 18:48 
---
Subject: Bug 37243

Author: rsandifo
Date: Thu Sep  4 18:47:35 2008
New Revision: 139993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139993
Log:
gcc/
PR middle-end/37243
* ira-build.c (form_loop_tree): Reverse BB walk.
(create_bb_allocnos): Likewise.
* ira-lives.c (make_regno_born_and_dead, regs_set): Delete.
(mark_reg_store): Rename to...
(mark_ref_live): ...this and take a df_ref argument instead of
note_stores arguments.  Assert that we have a register.
(mark_reg_clobber): Delete.
(def_conflicts_with_inputs_p): New function.
(mark_reg_conflicts): Delete.
(mark_reg_death): Rename to...
(mark_ref_dead): ...this and take a df_ref argument instead of
a register.  Assert that we have a register.
(process_bb_node_lives): Hoist frequency calculation out of
instruction walk.  Convert from a forwards scan to a backwards scan.
Use DF_REF_USES and DF_REF_DEFS instead of register notes and
note_stores.  Remove EH_RETURN_DATA_REGNO and regs_set handling.
(create_allocno_live_ranges): Don't create regs_set.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-build.c
trunk/gcc/ira-lives.c


-- 


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

[Bug middle-end/37359] [4.4 Regression] IRA miscompiled transfer.o in libgfortran, sejmp

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2008-09-04 19:03 ---
Subject: Bug 37359

Author: hjl
Date: Thu Sep  4 19:02:33 2008
New Revision: 139996

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139996
Log:
2008-09-04  Vladimir Makarov  <[EMAIL PROTECTED]>

PR middle-end/37359
* ira-lives.c (process_bb_node_lives): Check setjmp.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c


-- 


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

[Bug c++/37376] No standard mangling for char16/32_t yet

[kris dot van dot hees at oracle dot com]

--- Comment #1 from kris dot van dot hees at oracle dot com  2008-09-04 
19:12 ---
The vendor extension mangling was based on the following email as feedback on
the original patch:

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01622.html

The original suggested mangling was:

char16_t -> k
char32_t -> q

I believe that there was some potential contention on using 'q' due to another
proposal requesting that same symbol.  Is there any information from the ABI
committee on which symbols can be used for the mangling of these two types?


-- 

kris dot van dot hees at oracle dot com changed:

   What|Removed |Added

 CC||kris dot van dot hees at
   ||oracle dot com


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

[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2008-09-04 19:17 ---
Subject: Bug 37099

Author: domob
Date: Thu Sep  4 19:16:13 2008
New Revision: 139997

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139997
Log:
2008-09-04  Daniel Kraft  <[EMAIL PROTECTED]>

* PR fortran/37099
* expr.c (simplify_const_ref): Update expression's character length
when pulling out a substring reference.

2008-09-04  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37099
* gfortran.dg/string_compare_1.f90: New text.
* gfortran.dg/string_compare_2.f90: New text.
* gfortran.dg/string_compare_3.f90: New text.

Added:
trunk/gcc/testsuite/gfortran.dg/string_compare_1.f90
trunk/gcc/testsuite/gfortran.dg/string_compare_2.f90
trunk/gcc/testsuite/gfortran.dg/string_compare_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code

[vmakarov at redhat dot com]

--- Comment #6 from vmakarov at redhat dot com  2008-09-04 19:25 ---
  First of all, I've check the generated code on Core2 and I found it is not
slower than using movd.

  IRA assigns hard registers calculating their costs.  It the memory is
cheaper, it assigns memory.  The first decision point to use memory or hard
register is made in ira-costs.c.  The second decision point is ira-color
because the cost can changed dynamically (e.g. cheap hard register are not
available).

  In this case IRA decides to use memory instead of MMX reg in ira-cost.c

  a0(r61,l0) costs: AREG:25000,25000 DREG:25000,25000 CREG:25000,25000
BREG:25000,25000 SIREG:25000,25000 DIREG:25000,25000 AD_REGS:25000,25000
Q_REGS:25000,25000 NON_Q_REGS:25000,25000 LEGACY_REGS:25000,25000
GENERAL_REGS:25000,25000 SSE_FIRST_REG:42000,42000 SSE_REGS:42000,42000
MMX_REGS:25000,25000 MEM:23000

  The memory is cheaper than MMX_REG therefore r61 gets NO_REGS as cover class
which means using memory.

  The reason for this is in insn

(insn:HI 14 8 20 2
/home/cygnus/vmakarov/build/ira-merge-branch/gcc/gcc/testsuite/gcc.target/i386/pr34256.c:12
(set (reg/i:DI 0 ax)
(subreg:DI (reg:V2SI 61) 0)) 89 {*movdi_1_rex64} (expr_list:REG_DEAD
(reg:V2SI 61)
(nil)))

which has the following description

(define_insn "*movdi_1_rex64"
  [(set (match_operand:DI 0 "nonimmediate_operand"
  "=r,r  ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym")
(match_operand:DI 1 "general_operand"
  "Z ,rem,i,re,n ,C ,*y,*Ym,*y,r   ,m  ,C ,*x,*Yi,*x,r  ,m ,*Ym,*x"))]
  "TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

Please, look at the 8th alternatives ?r *Ym which corresponds to GENERAL_REGS
MMX_REGS.  ? makes the alternative expensive. * is even worse because it
excludes the alternative from register cost calculation.

  The old register allocator would behave the same way if regmove did not
coalesced r61 with another pseudo and the result pseudo had not MMX cost
cheaper than memory.

  There are several ways to fix the problem:

o ignore * and ? in the cost calculation
o fix the pattern
o run regmove as the old RA
o make failure expected

The first solution would result in huge performance regression for practically
any program.

I can not say about the 2nd solution because I am not the port maintainer.

The third solution is bad because in general case IRA does coalescing more
smart on the fly besides it could make RA even slower.

So I'd prefer the last solution.


-- 


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

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-09-04 19:25 ---
Appearantly I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-12-12 07:20:32 |2008-09-04 19:25:22
   date||


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #32 from ebotcazou at gcc dot gnu dot org  2008-09-04 19:30 
---
> I tried i586-linux with ira-merge branch. It built libgcc fine.
> So the problem is either fixed on ira-merge branch or it isn't
> caused by IRA merge.

Or isn't exposed on that branch.

It's a stack slot reuse problem during RA compiling df-scan.c.  Since it's not
related to this PR, I'm closing it and I'll open a new one.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2008-09-04 19:45 ---
(In reply to comment #6)
>   First of all, I've check the generated code on Core2 and I found it is not
> slower than using movd.

I think MMX may be slow anyway.

>   The reason for this is in insn
> 
> (insn:HI 14 8 20 2
> /home/cygnus/vmakarov/build/ira-merge-branch/gcc/gcc/testsuite/gcc.target/i386/pr34256.c:12
> (set (reg/i:DI 0 ax)
> (subreg:DI (reg:V2SI 61) 0)) 89 {*movdi_1_rex64} (expr_list:REG_DEAD
> (reg:V2SI 61)
> (nil)))
> 
> which has the following description
> 
> (define_insn "*movdi_1_rex64"
>   [(set (match_operand:DI 0 "nonimmediate_operand"
>   "=r,r  ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym")
> (match_operand:DI 1 "general_operand"
>   "Z ,rem,i,re,n ,C ,*y,*Ym,*y,r   ,m  ,C ,*x,*Yi,*x,r  ,m ,*Ym,*x"))]
>   "TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
> 
> Please, look at the 8th alternatives ?r *Ym which corresponds to GENERAL_REGS
> MMX_REGS.  ? makes the alternative expensive. * is even worse because it
> excludes the alternative from register cost calculation.

You are right.

>   The old register allocator would behave the same way if regmove did not
> coalesced r61 with another pseudo and the result pseudo had not MMX cost
> cheaper than memory.
> 
>   There are several ways to fix the problem:
> 
> o ignore * and ? in the cost calculation
> o fix the pattern
> o run regmove as the old RA
> o make failure expected
> 
> So I'd prefer the last solution.

I agree, given that it only affects MMX. Uros, what do you think?
Should we mark gcc.target/i386/pr34256.c as XFAIL?


-- 


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

[Bug middle-end/37221] Missed early loop-unroll optimization - causes 40% degradation on SPU

[tehila at il dot ibm dot com]

--- Comment #11 from tehila at il dot ibm dot com  2008-09-04 19:46 ---
(In reply to comment #10)
> I'm bootstraping and testing it on x86 now.
Bootstrap fails (at least on x86_64) (with ICE).

Tehila.


-- 


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

[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-09-04 20:02 ---
(In reply to comment #4)
> DIMENSION x(:)
> (if that's a legal way to specify DIMENSION, I'm not sure)?

"dimension(:)" is only valid for (a) dummy arguments or (b)
allocatable/pointer; but with "(5)" instead of "(:)" all examples compile with
all my compilers, including the picky NAG f95, which indicates that the last
example is probably valid.


-- 


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

[Bug c++/37376] [4.4 Regression] No standard mangling for char16/32_t yet

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-04 20:09 ---
Marked as regression to show up in the important bug list.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2008-09-04 20:09:11
   date||
Summary|No standard mangling for|[4.4 Regression] No standard
   |char16/32_t yet |mangling for char16/32_t yet
   Target Milestone|--- |4.4.0


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

[Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-09-04 20:12 ---
If we decide the test is bogus we should remove it, not xfail it.


-- 


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

[Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-09-04 20:17 ---
I am concerned about those "*Yi"/"*Ym" and "r" pairs:

[EMAIL PROTECTED] i386]$ grep "\*Yi" *.md
i386.md:"=r,m ,*y,*y,?rm,?*y,*x,*x,?r ,m ,?*Yi,*x")
i386.md:"g ,ri,C ,*y,*y ,rm ,C ,*x,*Yi,*x,r   ,m "))]
i386.md:  "=r,r  ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r
,m,?*Yi,*x,?*x,?*Ym")
i386.md:  "Z ,rem,i,re,n ,C ,*y,*Ym,*y,r   ,m  ,C ,*x,*Yi,*x,r  ,m
,*Ym,*x"))]
i386.md:  [(set (match_operand:DI 0 "nonimmediate_operand"
"=r,?r,?o,?*Ym,?*y,?*Yi,*Y2")
i386.md:  [(set (match_operand:DI 0 "nonimmediate_operand"
"=r,o,?*Ym,?*y,?*Yi,*Y2")
[EMAIL PROTECTED] i386]$ grep "\*Ym" *.md 
i386.md:  "=r,r  ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r
,m,?*Yi,*x,?*x,?*Ym")
i386.md:  "Z ,rem,i,re,n ,C ,*y,*Ym,*y,r   ,m  ,C ,*x,*Yi,*x,r  ,m
,*Ym,*x"))]
i386.md:  "=f,m,f,r  ,m ,x,x,x ,m,!*y,!m,!*y,?Yi,?r,!*Ym,!r")
i386.md:  "fm,f,G,rmF,Fr,C,x,xm,x,m  ,*y,*y ,r  ,Yi,r   ,*Ym"))]
i386.md:  [(set (match_operand:DI 0 "nonimmediate_operand"
"=r,?r,?o,?*Ym,?*y,?*Yi,*Y2")
i386.md:  [(set (match_operand:DI 0 "nonimmediate_operand"
"=r,o,?*Ym,?*y,?*Yi,*Y2")
[EMAIL PROTECTED] i386]$ 

IRA is much more sensitive to "*" constraint. We can ignore "*Ym"/"r" pairs.
But should we remove * from "*Yi"/"r" pairs?


-- 


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

[Bug rtl-optimization/37377] New: [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

At revision 140002 I get on i586-linux:

/home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
/home/eric/install/gcc/i586-suse-linux/include -isystem
/home/eric/install/gcc/i586-suse-linux/sys-include -g -O2 -O2  -g -O2 -DIN_GCC 
 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I/home/eric/svn/gcc/libgcc -I/home/eric/svn/gcc/libgcc/.
-I/home/eric/svn/gcc/libgcc/../gcc -I/home/eric/svn/gcc/libgcc/../include
-I/home/eric/svn/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o _popcountdi2.o -MT _popcountdi2.o -MD -MP -MF
_popcountdi2.dep -DL_popcountdi2 -c /home/eric/svn/gcc/libgcc/../gcc/libgcc2.c
\
  -fvisibility=hidden -DHIDE_EXPORTS
/home/eric/svn/gcc/libgcc/../gcc/libgcc2.c: In function '__popcountdi2':
/home/eric/svn/gcc/libgcc/../gcc/libgcc2.c:813: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_popcountdi2.o] Error 1
make[3]: Leaving directory
`/home/eric/build/gcc/native32/i586-suse-linux/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2
make[2]: Leaving directory `/home/eric/build/gcc/native32'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/eric/build/gcc/native32'
make: *** [all] Error 2


-- 
   Summary: [4.4 Regression] Bootstrap failure compiling libgcc
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: blocker
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
 GCC build triplet: i586-*-linux


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

[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2008-09-04 20:23 ---
I'll try to find something about this in the standard.  But you think DIMENSION
(and friends) is legally apply-able ("applicable"?) to symbols that are
declared later with their type?  Hm...  I hope to find out :)

Otherwise I'll try to fix this bug the conservative way ;)  Thanks for your
comments!


-- 


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

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dje at gcc dot gnu dot org]

--- Comment #19 from dje at gcc dot gnu dot org  2008-09-04 20:25 ---
The patch for this bug significantly degrades PowerPC performance.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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

[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-09-04 20:30 
---
It's a miscompilation of df-scan.c:df_reorganize_refs_by_reg by
regalloc/reload.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com


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

[Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2008-09-04 20:30 
---
Created an attachment (id=16224)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16224&action=view)
A patch

I am testing this patch

2008-09-04  H.J. Lu  <[EMAIL PROTECTED]>

PR target/37364
* config/i386/i386.md (*movsi_1): Remove * from *Yi.
(*movdi_1_rex64): Remove * from pairs of r and *Ym/*Yi.
(zero_extendsidi2_32): Likewise.
(zero_extendsidi2_rex64): Likewise.
(*movsf_1): Remove * from *Ym.


-- 


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

[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2008-09-04 20:32 
---
Created an attachment (id=16225)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16225&action=view)
Preprocessed source

Sorry, I don't have time to reduce it.

Compile with -O2 -fomit-frame-pointer -mtune=pentium.


-- 


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