[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto

[doko at ubuntu dot com]

--- Comment #6 from doko at ubuntu dot com  2009-01-29 05:41 ---
the fix for this causes http://bugs.debian.org/513420
a miscompilation of libgsf with the gcc-4_3-branch, filed as PR39015.


-- 


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

[Bug middle-end/39015] New: [4.3 regression] wrong code building libgsf

[doko at ubuntu dot com]

[forwarded from http://bugs.debian.org/513420]

Reverting the fix for PR38615 on the 4.3 branch lets the build succeed.

What am I trying to do:
* Build libgsf from source again on amd64 (or build libgsf svn trunk).

How am I trying to do it / steps to reproduce:
* Set up a sid environment in which to build libgsf from the Debian source
  package, e.g. in pbuilder.
* Get the libgsf source package and extract it.
* In the source directory, run
env MALLOC_CHECK_=2 debian/rules build

What behaviour did I expect to get:
* The libgsf build runs to completion.

What behaviour did I actually get:
* The libgsf build fails during documentation generation, with messages
  similar to the following:
creating gsf-scan
gtk-doc: Running scanner gsf-scan
sh: line 1: 27898 Segmentation fault  ( ./gsf-scan )
Scan failed: 
make[3]: *** [scan-build.stamp] Error 139
make[3]: Leaving directory `/tmp/buildd/libgsf-1.14.11/build/doc'
* This behaviour is fully repeatable for me.

Notes and observations:
* "gsf-scan" is built from generated sources using gtk-doc-tools.
* To preserve the gsf-scan sources and objects, comment out the unlink line
  which removes them in /usr/bin/gtkdoc-scangobj .
* When running plain "debian/rules build" without the env MALLOC_CHECK_=2,
  the problem manifests at a later point in the build as follows:
cd ../../doc/html && gtkdoc-mkhtml   gsf ../gsf-docs.sgml
../xml/text.xml:255: parser error : Input is not proper UTF-8, indicate
encoding !
Bytes: 0xD0 0x45 0x2E 0x02
When to quote fields.Default value: ÐE.
   ^
../xml/text.xml:255: parser error : PCDATA invalid Char value 2
When to quote fields.Default value: ÐE.
  ^
../xml/text.xml:279: parser error : chunk is not well balanced

^
../gsf-docs.sgml:232: parser error : Failure to process entity GsfText
&GsfText;
 ^
../gsf-docs.sgml:232: parser error : Entity 'GsfText' not defined
&GsfText;
 ^
unable to parse ../gsf-docs.sgml
make[3]: *** [html-build.stamp] Error 6
  This can be tracked back to a garbage string in the  block within
  the  block for GsfOutputCsvQuotingMode in doc/gsf.args which is a
  file generated by gsf-scan. The garbage string can vary between repeated
  attempts.
* This libgsf version (1.14.11-1) has previously been built successfully on
  all architectures.
* The problem is still reproducible for me when the optimisation level is
  reduced (in debian/rules) to -O1 .
* I could not reproduce the problem in the following variations:
  * When lowering the optimisation level to -O0 .
  * Building in a 32-bit pbuilder chroot on amd64.
  * Building in a sid environment with the gcc-4.3 packages downgraded to
the 4.3.2-1.1 versions from testing.
  * Building using CC=gcc-4.2 .
  * Building using CC=gcc-4.1 .
  * Building using CC=/usr/lib/gcc-snapshot/bin/gcc .
  which makes me suspect that the problem isn't with the (generated)
  gsf-scan sources, but with gcc's code generation.


-- 
   Summary: [4.3 regression] wrong code building libgsf
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug target/39013] [4.3/4.4 regression] Missing @PLT when -fpie is used

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-01-29 04:04 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01423.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||01/msg01423.html
Summary|[4.3/4.4 regression] @PLT is|[4.3/4.4 regression] Missing
   |missing on failed inline|@PLT when -fpie is used
   |function when -fpie is used |


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

[Bug tree-optimization/39007] -ftree-loop-distribution ICEs

[kazu at gcc dot gnu dot org]

--- Comment #1 from kazu at gcc dot gnu dot org  2009-01-29 02:23 ---
I've got a patch.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kazu at gcc dot gnu dot org
   |dot org |


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

[Bug tree-optimization/29212] ICE with -fipa-pta

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-01-29 02:10 
---
*** Bug 39014 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||warren dot armstrong at anu
   ||dot edu dot au


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

[Bug c++/39014] g++ 4.3.1 ICE with -fipa-pta

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-29 02:10 ---
-fipa-pta does nothing really except enables some analysis  which is not used
at all in the rest of the compiler.

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


-- 

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

[Bug c++/39014] New: g++ 4.3.1 ICE with -fipa-pta

[warren dot armstrong at anu dot edu dot au]

I ran across the following while compiling a C++ source of mine:

borked.cpp: In function 'void std::__introsort_loop(_RandomAccessIterator,
_RandomAccessIterator, _Size, _Compare) [with _RandomAccessIterator =
__gnu_cxx::__normal_iterator*,
std::vector,
std::allocator > > >, _Size = int,
_Compare = bool (*)(mm_entry_t, mm_entry_t)]':
borked.cpp:51: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

I have reduced the source code as much as possible and pasted it below (I
couldn't see a way to make an attachment).  I haven't preprocessed it, but the
only headers involved are standard C++ headers, and there are no complicated
#defines.

I invoked the compiler as:

g++ -c -fipa-pta -o bork.o borked.cpp

If I drop -fipa-pta, everything works.

My compiler version is:

gcc (Gentoo 4.3.1-r1 p1.1) 4.3.1

(I was not sure whether to file a report with Gentoo or here.  I chose here as
I doubt Gentoo have fiddled with the implementation of -fipa-pta.  Apologies if
I guessed wrong.)

---
Source:
---
#include 
#include 
#include 

template< class T1, class T2, class T3 >
class triple{
 public:
T1 first;
T2 second;
T3 third;

triple() : first(), second(), third()
{}

triple( T1 a, T2 b, T3 c ) : first(a), second(b), third(c)
{}
};


typedef int64_t sindex_t;
typedef uint64_t entry_t;
typedef double value_t;

typedef triple mm_entry_t;
typedef triple   mm_size_t;
typedef std::vector< mm_entry_t > mm_entries_t;
typedef std::pair< mm_size_t, mm_entries_t > mm_matrix_t;


#define get_row( entry ) (entry).first
#define get_col( entry ) (entry).second

bool compare( mm_entry_t a, mm_entry_t b ){
if ( get_row(a) < get_row(b) )
return true;

if ( get_row(a) > get_row(b) )
return false;

if ( get_col(a) < get_col(b) )
return true;

return false;
}

int main( int argc, char* argv[] ){
mm_matrix_t matrix;

std::sort( matrix.second.begin(), matrix.second.end(), compare );

return 0;
}


-- 
   Summary: g++ 4.3.1 ICE with -fipa-pta
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: warren dot armstrong at anu dot edu dot au
 GCC build triplet: --build=i686-pc-linux-gnu
  GCC host triplet: --host=i686-pc-linux-gnu
GCC target triplet: Same as host


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

[Bug bootstrap/37915] bootstrap broken for cygwin

[dannysmith at users dot sourceforge dot net]

--- Comment #7 from dannysmith at users dot sourceforge dot net  2009-01-29 
01:57 ---
(In reply to comment #6)
> This bug is fixed and should be closed now.  A new PR, bug 37660, has been
> created for the separate issue in comment 4.
> 
Closing


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-01-29 01:46 ---
This patch:

---
Index: varasm.c
===
--- varasm.c(revision 5094)
+++ varasm.c(working copy)
@@ -6321,6 +6321,11 @@ default_binds_local_p_1 (const_tree exp,
   && (DECL_INITIAL (exp) == NULL
   || DECL_INITIAL (exp) == error_mark_node))
 local_p = false;
+  /* Functions marked inline without body are not local.  */
+  else if (TREE_CODE (exp) == FUNCTION_DECL
+  && DECL_DECLARED_INLINE_P (exp)
+  && DECL_INITIAL (exp) == NULL)
+local_p = false;
   /* Otherwise we're left with initialized (or non-common) global data
  which is of necessity defined locally.  */
   else
---

works for me


-- 


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-01-29 01:13 ---
Linker does complain:

[...@gnu-6 gcc]$ cat /tmp/i.i
inline void foo ();

int
main ()
{
  foo ();
  return 0;
}
[...@gnu-6 gcc]$ gcc  /tmp/i.i  -fpie -pie 
/tmp/ccOgMGls.o: In function `main':
i.i:(.text+0xa): undefined reference to `foo'
/usr/local/bin/ld: /tmp/ccOgMGls.o: relocation R_X86_64_PC32 against undefined
symbol `foo' can not be used when making a shared object; recompile with -fPIC
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
[...@gnu-6 gcc]$ 


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC|ubizjak at gmail dot com|


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-29 00:58 ---
Since default_binds_local_p_1 returns true as shlib is false for -fPIE, I still
don't see any issues here except for the fact the linker not doing the correct
thing.


-- 


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-29 00:52 ---
Why do you think this is a bug?

PowerPC32-linux-gnu produces:
bl f...@local


-- 


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-29 00:50 ---
I don't see the issue with using the non PLT with -fPIE.


-- 


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-01-29 00:48 ---
[...@gnu-6 gcc]$ ./xgcc -B./ -fpie  -S /tmp/i.i -m32 -fpie
[...@gnu-6 gcc]$ cat i.s
.file   "i.i"
.text
.globl bar
.type   bar, @function
bar:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
callfoo
leave
ret
.size   bar, .-bar


-- 


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

[Bug target/39013] [4.3/4.4 regression] @PLT is missing on failed inline function when -fpie is used

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-01-29 00:47 ---
[...@gnu-6 gcc]$ cat /tmp/i.i
inline void foo ();

void
bar ()
{
  foo ();
}
[...@gnu-6 gcc]$ ./xgcc -B./  -S /tmp/i.i -m32 -fPIC 
[...@gnu-6 gcc]$ cat i.s
.file   "i.i"
.text
.globl bar
.type   bar, @function
bar:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$4, %esp
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
callf...@plt
addl$4, %esp
popl%ebx
popl%ebp
ret
.size   bar, .-bar


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
URL|http://bugs.gentoo.org/show_|
   |bug.cgi?id=254355   |
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64  |
   GCC host triplet|x86_64  |
 GCC target triplet|x86_86  |x86_64-linux-gnu
   Last reconfirmed|-00-00 00:00:00 |2009-01-29 00:47:37
   date||
Summary|Compiler miss to add @PLT to|[4.3/4.4 regression] @PLT is
   |symbols when object is  |missing on failed inline
   |compile with -fPIE -pie |function when -fpie is used
   Target Milestone|--- |4.3.4


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[mmitchel at gcc dot gnu dot org]

--- Comment #13 from mmitchel at gcc dot gnu dot org  2009-01-28 23:56 
---
Actually, CLASSTYPE_EMPTY_P is probably a fine thing to use for C++.  (It's of
course C++ specific; you'd either need to access it via a hook, or promote to a
language-independent bit.)  CLASSTYPE_EMPTY_P will not capture an array of
empty objects, but that's an extreme corner-case.

Note that CLASSTYPE_EMPTY_P classes may have arbitrary size.  That's because of
things like:

  struct A{};
  struct B : public A {};
  struct C : public A, public B {};

In C, you cannot put the B sub-object at the same address as the A sub-object
since that would end up with two A sub-objects (the A-in-B-in-C subobject and
A-in-C subobject) at the same address.  So, C will be a two-byte structure. 
Obviously, you can generalize this to make arbitrarily huge empty classes.


-- 


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

[Bug lto/39000] internal compiler error: in output_expr_operand, at lto-function-out.c:1200

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-28 23:02 ---
(In reply to comment #1)
> On Linux/ia32, I got

That is a different bug.  fdesc_expr is only used for ia64.  Basically the
vtables inline the function descriptors.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |lto
 GCC target triplet||ia64-*-*
   Keywords||ice-on-valid-code


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

[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-28 22:37 
---
We should still optimize

static void bar(void) { foo (); }

inline void __attribute__((always_inline)) foo(void)
{
  foo ();
  bar ();
}

to

foo() { foo(); foo (); }

or similar cases, that is basically collapse a cycle covering multiple
functions into one.


-- 


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

[Bug c/39012] GCC accepts badly formatted while statement

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-28 22:17 ---
>while ( !b );

Is vaild code but should be warned about.
In fact with 4.3 and above we do get a warning with -W -Wall:
t.cc: In function 'void g()':
t.cc:13: warning: suggest a space before ';' or explicit braces around empty
body in 'while' statement


-- 


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

[Bug target/39013] Compiler miss to add @PLT to symbols when object is compile with -fPIE -pie

[zorry at ume dot nu]

--- Comment #1 from zorry at ume dot nu  2009-01-28 22:16 ---
Created an attachment (id=17205)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17205&action=view)
gre compile with gcc 4.3 and -fPIE  -save-temps  gre.i

The .i file of gre thats compile with gcc 4.3.2 and CFLAGS -fPIE  LDFLAGS -pie


-- 


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

[Bug c/39013] New: Compiler miss to add @PLT to symbols when object is compile with -fPIE -pie

[zorry at ume dot nu]

http://bugs.gentoo.org/show_bug.cgi?id=254355
We are using patched gcc but it fail on gentoo's default compiler's to.
It works fine with GCC 4.2.4 and lower.
The fail file is part of libnet
the symbol that miss the @PLT is libnet_getgre_length
it sould have @PLT as the rest of the symbols
If i compile the fail file with -pic instead i compiles fine.
and have @PLT added 
gcc version 4.3.3
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.3-r1/work/gcc-4.3.3/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--enable-cld --disable-libgcj --enable-languages=c,c++,treelang --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu 
Thread model: posix
glibc-2.8_p20080602-r1
intel-r-_xeon-r-_cpu_e54...@_2.50ghz
binutils:  2.18  it add relro as default
The file is compile with CFLAGS -fPIE and LDFLAGS -pie -z now


-- 
   Summary: Compiler miss to add @PLT to symbols when object is
compile with -fPIE -pie
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zorry at ume dot nu
 GCC build triplet: x_86_64
  GCC host triplet: x86_64
GCC target triplet: x86_86


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

[Bug fortran/38852] [4.3] UBOUND fails for negative stride triplets

[pault at gcc dot gnu dot org]

--- Comment #13 from pault at gcc dot gnu dot org  2009-01-28 21:52 ---
Fixed on trunk.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
Summary|[Fix pending] UBOUND fails  |[4.3] UBOUND fails for
   |for negative stride triplets|negative stride triplets


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

[Bug fortran/38852] [Fix pending] UBOUND fails for negative stride triplets

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2009-01-28 21:49 ---
Subject: Bug 38852

Author: pault
Date: Wed Jan 28 21:48:53 2009
New Revision: 143743

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143743
Log:
2009-01-28  Paul Thomas  

PR fortran/38852
PR fortran/39006
* trans-intrinsic.c (gfc_conv_intrinsic_bound): Use the array
descriptor ubound for UBOUND, when the array lbound == 1.

2009-01-28  Paul Thomas  

PR fortran/38852
PR fortran/39006
* gfortran.dg/bound_6.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/bound_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39006] Wrong result for array(:,ny:1:-1)) as actual argument (inverting order by negative strides)

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2009-01-28 21:49 ---
Subject: Bug 39006

Author: pault
Date: Wed Jan 28 21:48:53 2009
New Revision: 143743

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143743
Log:
2009-01-28  Paul Thomas  

PR fortran/38852
PR fortran/39006
* trans-intrinsic.c (gfc_conv_intrinsic_bound): Use the array
descriptor ubound for UBOUND, when the array lbound == 1.

2009-01-28  Paul Thomas  

PR fortran/38852
PR fortran/39006
* gfortran.dg/bound_6.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/bound_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-01-28 21:47 ---
Further testcases:

inline __attribute__((always_inline))
void A (void)
{
  A ();
  A ();
  A ();
}

int
main ()
{
  A ();
  return 0;
}

and:

inline void A (void);
inline void B (void);

inline __attribute__ ((always_inline))
void C (void)
{
  B ();
}

inline __attribute__ ((always_inline))
void B (void)
{
  A ();
}

inline __attribute__ ((always_inline))
void A (void)
{
  A ();
  B ();
  C ();
}

int
main ()
{
  A ();
  return 0;
}

Perhaps just changing node->aux for all nodes for which recursive
cgraph_decide_inlining_incrementally will be called would work.


-- 


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

[Bug middle-end/38999] [4.2/4.3/4.4 Regression] Extra overflow warning in 32-bit HWI compiler

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P2
   Target Milestone|4.3.4   |4.2.5


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/38937] [4.4 Regression] dereferencing pointer '' does break strict-aliasing

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/39012] GCC accepts badly formatted while statement

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-28 21:16 ---
That is perfectly valid code.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/38995] lto1 uses unaligned data accesses

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-01-28 21:12 ---
Are all data in IL aligned according to psABI?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-28 21:12:43
   date||


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

[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-01-28 21:08 ---
The #c6 patch doesn't make sense to me.

Two alternative testcases:

inline __attribute__ ((always_inline))
void A (void)
{
  int i;
  asm volatile ("" : "=m" (i));
  A ();
  A ();
}

int
main ()
{
  A ();
  return 0;
}

and

inline void A (void);
inline void B (void);

inline __attribute__ ((always_inline))
void C (void)
{
  B ();
}

inline __attribute__ ((always_inline))
void B (void)
{
  A ();
}

inline __attribute__ ((always_inline))
void A (void)
{
  int i;
  asm volatile ("" : "=m" (i));
  A ();
  C ();
}

int
main ()
{
  A ();
  return 0;
}

As the cgraph_decide_inlining_incrementally + try_inline combo goes
depth-first, it discovers just the first (perhaps indirect) recursive inlining
only, the others mean we keep recursing with deeper and deeper depths.  I
wonder if it couldn't go breadth-first instead.  Honza?


-- 


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

[Bug bootstrap/39001] lto branch doesn't build

[dnovillo at gcc dot gnu dot org]

--- Comment #3 from dnovillo at gcc dot gnu dot org  2009-01-28 21:08 
---
*** Bug 39011 has been marked as a duplicate of this bug. ***


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andreast at gcc dot gnu dot
   ||org


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

[Bug bootstrap/39011] lto bootstrap failure on ppc-linux

[dnovillo at gcc dot gnu dot org]

--- Comment #1 from dnovillo at gcc dot gnu dot org  2009-01-28 21:08 
---

This is the same issue reported in 39001, except that it happens on a different
file.

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


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/39012] New: GCC accepts badly formatted while statement

[gp dot bolton at computer dot org]

while loop is badly formatted in the following example.  Although an "obvious"
bug, this type of thing can occur when modifying existing code having do-while
statements and converting them to while statements.

bool f()
{
  return true;
}

void g()
{
  bool b( false );

  while ( !b )
  {
b = f();
  } while ( !b );
}


-- 
   Summary: GCC accepts badly formatted while statement
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gp dot bolton at computer dot org
 GCC build triplet: i386-apple-darwin9.6.0
  GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: i386-apple-darwin9.6.0


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

[Bug bootstrap/39011] New: lto bootstrap failure on ppc-linux

[andreast at gcc dot gnu dot org]

Bootstrap breaks while configuring libgcc. Distribution is f10.

Here the conftest.c which fails:

/* 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;
 }


The failure report:

checking for suffix of object files...
configure: error: in
`/share1/devel/gcc-testing/lto/objdir/powerpc-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile

Compiling the above snippet with:
/share1/devel/gcc-testing/lto/objdir/./gcc/xgcc
-B/share1/devel/gcc-testing/lto/objdir/./gcc/
-B/usr/local/powerpc-unknown-linux-gnu/bin/
-B/usr/local/powerpc-unknown-linux-gnu/lib/ -isystem
/usr/local/powerpc-unknown-linux-gnu/include -isystem
/usr/local/powerpc-unknown-linux-gnu/sys-include -c -g -O2conftest.c

ends with:

conftest.c:16: internal compiler error: Segmentation fault

Leaving the -g away or add -gstabs lets the compiler build the .o file.

Here the bt from gdb:

GNU C (lto merged with rev 143693) version 4.4.0 20090127 (experimental) [lto
revision 143742] (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b171cd7b97ecc9ca5a6389a8b0f486bf

Program received signal SIGSEGV, Segmentation fault.
0x106bd414 in get_personality_function (decl=0x0)
at /share1/devel/gcc-testing/lto/gcc/gcc/expr.h:806
806   tree personality = DECL_FUNCTION_PERSONALITY (decl);
(gdb) bt
#0  0x106bd414 in get_personality_function (decl=0x0)
at /share1/devel/gcc-testing/lto/gcc/gcc/expr.h:806
#1  0x106c9a10 in output_call_frame_info (for_eh=0)
at /share1/devel/gcc-testing/lto/gcc/gcc/dwarf2out.c:2914
#2  0x106cae70 in dwarf2out_frame_finish ()
at /share1/devel/gcc-testing/lto/gcc/gcc/dwarf2out.c:3351
#3  0x111d3058 in compile_file ()
at /share1/devel/gcc-testing/lto/gcc/gcc/toplev.c:1023
#4  0x111d5cf8 in do_compile ()
at /share1/devel/gcc-testing/lto/gcc/gcc/toplev.c:2220
#5  0x111d5d8c in toplev_main (argc=34, argv=0xbfc4c3a4)
at /share1/devel/gcc-testing/lto/gcc/gcc/toplev.c:2252
#6  0x102dd048 in main (argc=34, argv=0xbfc4c3a4)
at /share1/devel/gcc-testing/lto/gcc/gcc/main.c:35


-- 
   Summary: lto bootstrap failure on ppc-linux
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andreast at gcc dot gnu dot org
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-01-28 20:54 
---
This needs to be dealt from within the frontend, possibly like Mark suggested
by inventing another predicate (I assume that CLASSTYPE_EMPTY_P is used for
some C++ standard stuff so we cannot just change that).  It may still be ok
for the expr_size langhook to return true for this kind of type:

struct empty {};
struct still_empty { empty x; };


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|REOPENED|NEW


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

[Bug fortran/38852] [Fix pending] UBOUND fails for negative stride triplets

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2009-01-28 20:52 ---
Created an attachment (id=17204)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17204&action=view)
Updated patch

Following discussion on fortran list and #gfortran, a more restrictive test is
needed.


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #17182|0   |1
is obsolete||


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-28 20:49 
---
# VUSE  { D.86121 }
# vis_224 = VDEF  { vis }
vis = D.86121;

cp_expr_size returns 1 for the objects.

 
unit size 
align 8 symtab 0 alias set 80 canonical type 0xb62bfbc8
fields 
used nonlocal decl_3 QI file t.ii line 51866 col 11 size
 unit size 
align 8 offset_align 128
offset 
bit offset  context  chain > context

   needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  reference_to_this
 chain >
used ignored QI file t.ii line 51892 col 9 size 
unit size 
align 8 context  abstract_origin >

calling it on the m_vis member yields zero.

We change dfs_visitors empty flag to false in check_field_decls.

Short testcase:

struct empty {};

struct dfs_visitor {
dfs_visitor() { }
empty m_vis;
};

void bar(const dfs_visitor&);
void foo(void)
{
  dfs_visitor vis;
  dfs_visitor vis2 = vis;
  bar (vis2);
}

Note that we also end up generating code for the copy.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||diagnostic, missed-
   ||optimization


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

[Bug middle-end/39010] New: [LTO] Memory corruption on gcc.c-torture/compile/limits-fndefn.c

[hjl dot tools at gmail dot com]

On Linux/x86-64, revision 143741

# valgrind --tool=memcheck /export/gnu/import/svn/gcc-test/bld/gcc/cc1 -quiet
-v -imultilib 32 -iprefix
/export/gnu/import/svn/gcc-test/bld/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/
-isystem /export/gnu/import/svn/gcc-test/bld/gcc/include -isystem
/export/gnu/import/svn/gcc-test/bld/gcc/include-fixed
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c
-quiet -dumpbase limits-fndefn.c -m32 -mtune=generic -auxbase limits-fndefn -w
-version -flto -o limits-fndefn.s
zsh: correct 'limits-fndefn.c' to 'limits-fndefn.s' [nyae]? 
==5452== Memcheck, a memory error detector.
==5452== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==5452== Using LibVEX rev 1804, a library for dynamic binary translation.
==5452== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==5452== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==5452== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==5452== For more details, rerun with: -v
==5452== 
ignoring nonexistent directory
"/export/gnu/import/svn/gcc-test/bld/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include"
ignoring nonexistent directory
"/export/gnu/import/svn/gcc-test/bld/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed"
ignoring nonexistent directory
"/export/gnu/import/svn/gcc-test/bld/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /export/gnu/import/svn/gcc-test/bld/gcc/include
 /export/gnu/import/svn/gcc-test/bld/gcc/include-fixed
 /usr/local/include
 /usr/include
End of search list.
GNU C (lto merged with rev 143693) version 4.4.0 20090127 (experimental) [lto
revision 143741] (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090127 (experimental) [lto revision
143741], GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 422ba1b8d5a8cc825fd0dfb4279ac4e7
==5452== Invalid read of size 1
==5452==at 0xB908AF: htab_hash_string (hashtab.c:812)
==5452==by 0xB90F0B: htab_expand (hashtab.c:540)
==5452==by 0xB91269: htab_find_slot_with_hash (hashtab.c:619)
==5452==by 0xB23D54: output_string (lto-function-out.c:275)
==5452==by 0xB242AE: output_tree_flags (lto-function-out.c:532)
==5452==by 0xB27E9D: output_local_vars (lto-function-out.c:1283)
==5452==by 0xB2D0A9: lto_output (lto-function-out.c:1968)
==5452==by 0x667AC8: ipa_write_summaries_2 (passes.c:1403)
==5452==by 0x66899C: ipa_write_summaries_1 (passes.c:1428)
==5452==by 0x668A63: ipa_write_summaries (passes.c:1449)
==5452==by 0x8E3A62: cgraph_optimize (cgraphunit.c:1266)
==5452==by 0x416732: c_write_global_declarations (c-decl.c:8045)
==5452==  Address 0x4d2625e is 0 bytes after a block of size 6 alloc'd
==5452==at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==5452==by 0xB928A7: xmalloc (xmalloc.c:147)
==5452==by 0xB23DD9: output_string (lto-function-out.c:283)
==5452==by 0xB27DCC: output_local_vars (lto-function-out.c:1241)
==5452==by 0xB2D0A9: lto_output (lto-function-out.c:1968)
==5452==by 0x667AC8: ipa_write_summaries_2 (passes.c:1403)
==5452==by 0x66899C: ipa_write_summaries_1 (passes.c:1428)
==5452==by 0x668A63: ipa_write_summaries (passes.c:1449)
==5452==by 0x8E3A62: cgraph_optimize (cgraphunit.c:1266)
==5452==by 0x416732: c_write_global_declarations (c-decl.c:8045)
==5452==by 0x70FD6C: toplev_main (toplev.c:991)
==5452==by 0x3A0D01E575: (below main) (in /lib64/libc-2.9.so)


-- 
   Summary: [LTO] Memory corruption on gcc.c-torture/compile/limits-
fndefn.c
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: dnovillo at google dot com
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/39009] [LTO] ICE: in make_decl_rtl, at varasm.c:1288

[dnovillo at google dot com]

--- Comment #1 from dnovillo at google dot com  2009-01-28 20:36 ---
Subject: Re:  New: [LTO] ICE: in make_decl_rtl, at 
varasm.c:1288

Thanks for the bug reports.

At this stage, I'm not sure if it's useful to file a bug report for
every test in the GCC testsuite.  These failures are highly visible
already and there are about 1,200 of them, so having a separate bug
report for each of them may be excessive.


Diego.


-- 


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

[Bug libstdc++/37907] [c++0x] support for std::is_standard_layout

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2009-01-28 20:35 ---

Adjust summary, change to enhancement. 

I would really like to use std::is_standard_layout in the testsuite, so that
these requirements for , , and  can be
validated for libstdc++ sources. The requirements/limitations for standard
layout types limits some designs, like derived mutexes. Tracking it in the
testsuite would be optimal.

I don't see a way to use existing C++0x type_traits to accomplish the same
thing.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
   Severity|normal  |enhancement
Summary|type_trait: missing |[c++0x] support for
   |is_standard_layout  |std::is_standard_layout


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

[Bug middle-end/39009] New: [LTO] ICE: in make_decl_rtl, at varasm.c:1288

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 143741 gave

/export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/2822-1.c
 -w  -O0 -flto   -lm   -m32 -o
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gcc/2822-1.x0(timeout
= 300)
In file included from :1:^M
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/2822-1.c:
In function 'f2':^M
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/2822-1.c:8:
internal compiler error: in make_decl_rtl, at varasm.c:1288^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M
lto-wrapper: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc returned 1 exit
status


-- 
   Summary: [LTO] ICE: in make_decl_rtl, at varasm.c:1288
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: dnovillo at google dot com
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/39008] New: [LTO] ICE: in output_tree_with_context, at lto-function-out.c:3210

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 143741 gave

Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/   -O0 -flto  -w -c  -m32 -o
920428-4.o
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/compile/920428-4.c
   (timeout = 300)
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/compile/920428-4.c:1:
internal compiler error: in output_tree_with_context, at
lto-function-out.c:3210^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M


-- 
   Summary: [LTO]  ICE: in output_tree_with_context, at lto-
function-out.c:3210
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: dnovillo at google dot com
ReportedBy: hjl dot tools at gmail dot com


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

[Bug target/39000] internal compiler error: in output_expr_operand, at lto-function-out.c:1200

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-01-28 20:11 ---
On Linux/ia32, I got

Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/   -O1 -flto  -w -c  -m32 -o
20021204-1.o
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c
   (timeout = 300)
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c:
In function 'foo':^M
/export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c:16:
internal compiler error: in output_expr_operand, at lto-function-out.c:1200^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|ia64-*-*|
   Last reconfirmed|-00-00 00:00:00 |2009-01-28 20:11:25
   date||


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

[Bug tree-optimization/39007] New: -ftree-loop-distribution ICEs

[kazu at gcc dot gnu dot org]

Consider:

void
foo (int *__restrict__ p, int *__restrict__ q, int count)
{
  while (--count >= 0)
{
  *p++ = 0;
  *q++ = 0;
}
}

I get:

$ ./cc1 -quiet -O2 -ftree-loop-distribution min.c
min.c: In function 'foo':
min.c:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This is as of Revision 143741, which is after the fix for PR
tree-optimization/38997 has gone in:

http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00752.html

FWIW, if I try:

void
foo (int *__restrict__ p, int *__restrict__ q, int count)
{
  int i;
  for (i = 0; i < count; i++)
{
  *p++ = 0;
  *q++ = 0;
}
}

I get:

*** glibc detected *** ./cc1: malloc(): memory corruption: 0xf7efd160 ***

I am guessing that depending on the exact memory allocation pattern,
different parts of memory get corrupted.


-- 
   Summary: -ftree-loop-distribution ICEs
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

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

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2009-01-28 19:44 ---
Subject: Re:  [4.4 Regression] g++.dg/init/const7.C XFAILed

On Wed, 28 Jan 2009, jason at redhat dot com wrote:

> Subject: Re:  [4.4 Regression] g++.dg/init/const7.C XFAILed
> 
> rguenther at suse dot de wrote:
> >> Why do it in the FE?  This seems like a language-independent optimization.
> > 
> > Do it in the FE if the FE wants it to be optimized to a constant.
> > Otherwise sure - it is a language-independent optimization.  But fold
> > isn't a proper optimizer ;)
> 
> I don't understand the distinction you're making; it seems to me that 
> reducing expressions to simpler forms that are more easily optimized is 
> exactly what fold is for.  I don't see the difference between this and, 
> say, reducing "1 + 2" to "3".
> 
> The FE doesn't especially want this to be a constant; it isn't a valid 
> constant expression in C++, because it involves a subtraction of two 
> pointers.

I'll bootstrap / test my fold patch.

Richard.


-- 


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

[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented

[richard dot guenther at gmail dot com]

--- Comment #5 from richard dot guenther at gmail dot com  2009-01-28 19:42 
---
Subject: Re:  [4.3/4.4 Regression] life passes dump 
option still documented

On Wed, Jan 28, 2009 at 5:03 PM, Kenneth Zadeck
 wrote:
> rguenth at gcc dot gnu dot org wrote:
>> --- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-24 10:20 
>> ---
>> GCC 4.3.3 is being released, adjusting target milestone.
>>
>>
>>
> This may be more a change than is acceptable right now for 4.4.   If so
> I will sit on this patch until 4.5 opens up.   The patch is basically a
> complete rewrite of the part of invoke.texi that deals with dump options
> for the rtl pass.   This section had badly rotted.
>
> I started from a grep of the sources looking for "rtl_opt_pass" and
> documented all of the passes that i found in mostly alphabetical
> order.   Where the old version documented several passes together, I
> kept that unless things had changed.   In total there were about a half
> dozen passes that were no longer there and about a dozen new passes that
> had not been documented.
>
> I did make some changes in the code, which is the reason that this may
> not be acceptable to 4.4.  The changes are pretty harmless:  all of them
> involve either removing the pass name or changing it.
>
> 1) Pass names that contained dashes had the dashes changed to
> underscores.   About half used slashes and half underscores and I went
> with underscores to avoid a possible ambiguity with the options parsing.
>
> 2) I also removed the pass name from 6 passes that do not print anything
> or dump the code.

I think this change is agains what was asked for in the past.  We want to have
pass names for all passes.

> 3) Files that contained multiple passes with names of the form xx,
> xx2... were renamed xx1,xx2.
> This later change causes a test suit failure which was fixed.
>
> All of these changes are pretty minor.  The only possible failure these
> can cause are in the test suite where dump files are scanned.
>
> I tested this on x86 and ppc both 32 and 64.  It is possible that there
> are platform specific regression tests that scan for dump files that
> were not caught on these four targets.
>
> I also left in lreg and greg.These are at the end and need to be
> deleted along with those passes.
>
> I have enclosed a copy of the new text.  The diff is unreadable.
>
> ok for 4.4 or should i wait for 4.5?

This is ok for 4.4 if you remove the parts that remove pass names.  Please
wait a day for comments from others.

Thanks,
Richard.

> Kenny
>
>
> 2009-01-28  Kenneth Zadeck 
>
>PR middle-end/35854
>* doc/invoke.texi (rtl debug options): Complete rewrite.
>* auto-inc-dec.c (pass_inc_dec): Rename pass from "auto-inc-dec"
>to auto_inc_dec".
>* df-core.c (df_pass_initialize_opt, df_pass_initialize_no_opt,
>df_pass_finish): Removed pass name.
>* mode-switching.c (pass_mode_switching): Rename pass from
>"mode-sw" to "mode_sw".
>* except.c (pass_convert_to_eh_ranges): Rename pass from
>"eh-ranges" to "eh_ranges".
>* regclass.c (pass_regclass_init, pass_subregs_of_mode_init,
>pass_subregs_of_mode_finish): Removed pass name.
>* lower-subreg.c (pass_lower_subreg): Renamed pass from "subreg"
>to "subreg1".
>
>
> 2009-01-28  Kenneth Zadeck 
>
>PR middle-end/35854
>* gcc.dg/lower-subreg-1.c: Renamed dump pass from "subreg" to
> "subreg1"
>
>
> ==
> @item -...@var{letters}
> @itemx -fdump-r...@var{pass}
> @opindex d
> Says to make debugging dumps during compilation at times specified by
> @var{letters}.This is used for debugging the RTL-based passes of the
> compiler.  The file names for most of the dumps are made by appending a
> pass number and a word to the @var{dumpname}.  @var{dumpname} is generated
> from the name of the output file, if explicitly specified and it is not
> an executable, otherwise it is the basename of the source file. These
> switches may have different effects when @option{-E} is used for
> preprocessing.
>
> Debug dumps can be enabled with a @option{-fdump-rtl} switch or some
> @option{-d} option @var{letters}.  Here are the possible
> letters for use in @var{pass} and @var{letters}, and their meanings:
>
> @table @gcctabopt
>
> @item -fdump-rtl-alignments
> @opindex fdump-rtl-alignments
> Dump after branch alignments have been computed.
>
> @item -fdump-rtl-asmcons
> @opindex fdump-rtl-asmcons
> Dump after fixing rtl statements that have unsatisfied in/out constraints.
>
> @item -fdump-rtl-auto_inc_dec
> @opindex fdump-rtl-auto_inc_dec
> Dump after auto-inc-dec discovery.  This pass is only run on
> architectures that have auto inc or auto dec instructions.
>
> @item -fdump-rtl-barriers
> @opindex fdump-rtl-barriers
> Dump after cleaning up the barrier instructions.
>
> @item -fdump-rtl-bbpart
> @opindex fdump-rtl-bbpart
> Dump after partitioning hot and cold basic blocks.
>
> @item -fdump-rtl-bbro
> @opindex fdump-rtl-bbro
> Dump 

[Bug testsuite/39005] [LTO]: Not all testcases support LTO

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-01-28 19:27 ---
I changed to configure lto branch with --enable-languages=c,c++,lto.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/38996] [LTO] lto1 doesn't work on RHEL5

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-01-28 19:26 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #13 from r dot emrich at de dot tecosim dot com  2009-01-28 
19:06 ---
The changes in revision 143118 to revesion 143120 are causing the fault.


-- 


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

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[dnovillo at google dot com]

--- Comment #7 from dnovillo at google dot com  2009-01-28 18:56 ---
Subject: Re:  [LTO] Bootstrap failed on RHEL5/ia32 and 
RHEL5/ia64

On Wed, Jan 28, 2009 at 13:49, hjl dot tools at gmail dot com
 wrote:

> I bootstrapped it on RHEL5/ia32, RHEL5/ia64 and Fedora 10/x86-64.
> There are many failures in testsuite. I don't believe they are
> caused by my patch.  Fixed.

Thanks.  The testsuite is rather messy at the moment, so the best way
to detect new failures is to compare against an unpatched tree.  I
post daily builds on x86 to gcc-testresults, so you could use those.


Diego.


-- 


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

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-01-28 18:49 ---
I bootstrapped it on RHEL5/ia32, RHEL5/ia64 and Fedora 10/x86-64.
There are many failures in testsuite. I don't believe they are
caused by my patch.  Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-01-28 18:21 ---
Subject: Bug 38992

Author: hjl
Date: Wed Jan 28 18:21:19 2009
New Revision: 143741

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

2009-01-28  H.J. Lu  

PR bootstrap/38992
* configure.ac: Add AC_CHECK_GELF.

* config.in: Regenerated.
* configure: Likewise.

gcc/lto/

2009-01-28  H.J. Lu  

PR bootstrap/38992
* lto-elf.c: Include gelf.h instead of libelf.h.
(lto_elf_file_close): Replace elfx_update_shstrndx with
gelf_getehdr, elf_getscn, gelf_getshdr, gelf_update_shdr and
gelf_update_ehdr.

Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/config.in
branches/lto/gcc/configure
branches/lto/gcc/configure.ac
branches/lto/gcc/lto/ChangeLog
branches/lto/gcc/lto/lto-elf.c


-- 


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

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[vapier at gentoo dot org]

--- Comment #19 from vapier at gentoo dot org  2009-01-28 18:20 ---
are corresponding changes needed for hppa/sparc considering this bug discussed
them originally ?


-- 


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

[Bug tree-optimization/38997] -ftree-loop-distribution ICEs

[kazu at gcc dot gnu dot org]

--- Comment #4 from kazu at gcc dot gnu dot org  2009-01-28 18:18 ---
Patch committed.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/38997] -ftree-loop-distribution ICEs

[kazu at gcc dot gnu dot org]

--- Comment #3 from kazu at gcc dot gnu dot org  2009-01-28 18:17 ---
Subject: Bug 38997

Author: kazu
Date: Wed Jan 28 18:17:13 2009
New Revision: 143740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143740
Log:
gcc/
PR tree-optimization/38997
* tree-loop-distribution.c (generate_memset_zero): Use
POINTER_PLUS_EXPR for a pointer addition.

gcc/testsuite/
PR tree-optimization/38997
* gcc.dg/tree-ssa/pr38997.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr38997.c


-- 


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

[Bug tree-optimization/38997] -ftree-loop-distribution ICEs

[kazu at gcc dot gnu dot org]

--- Comment #2 from kazu at gcc dot gnu dot org  2009-01-28 18:17 ---
Subject: Bug 38997

Author: kazu
Date: Wed Jan 28 18:16:57 2009
New Revision: 143739

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143739
Log:
gcc/
PR tree-optimization/38997
* tree-loop-distribution.c (generate_memset_zero): Use
POINTER_PLUS_EXPR for a pointer addition.

gcc/testsuite/
PR tree-optimization/38997
* gcc.dg/tree-ssa/pr38997.c: New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c


-- 


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

[Bug fortran/38993] better error needed for incompatible f90 modules

[mikael at gcc dot gnu dot org]

--- Comment #1 from mikael at gcc dot gnu dot org  2009-01-28 18:14 ---


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


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/38259] Add version number to .mod file

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2009-01-28 18:14 ---
*** Bug 38993 has been marked as a duplicate of this bug. ***


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||colinlee at cray dot com


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #12 from r dot emrich at de dot tecosim dot com  2009-01-28 
18:04 ---
fault came up between 2nd and 9th of January.
With visual c++ 2005 there is no problem.


-- 


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

[Bug target/29141] static constructors beyond 64k fail

[aesok at gcc dot gnu dot org]

--- Comment #6 from aesok at gcc dot gnu dot org  2009-01-28 17:53 ---
Fixed.


-- 

aesok at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/38852] [Fix pending] UBOUND fails for negative stride triplets

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2009-01-28 17:33 ---
Marked up the severity to that of PR39006.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical


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

[Bug fortran/39006] Wrong result for array(:,ny:1:-1)) as actual argument (inverting order by negative strides)

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2009-01-28 17:31 ---
This is the same as PR38852 and the fix for that one works for this too.

Paul

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


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/38852] [Fix pending] UBOUND fails for negative stride triplets

[pault at gcc dot gnu dot org]

--- Comment #9 from pault at gcc dot gnu dot org  2009-01-28 17:31 ---
*** Bug 39006 has been marked as a duplicate of this bug. ***


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[bangerth at gmail dot com]

--- Comment #10 from bangerth at gmail dot com  2009-01-28 17:28 ---
Re-open


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

[bangerth at gmail dot com]

--- Comment #9 from bangerth at gmail dot com  2009-01-28 17:27 ---
Created an attachment (id=17203)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17203&action=view)
Failing testcase

Richard,
I hate to break the news to you but there are even more cases. Attached
is a file that produces this warning:

dof_renumbering.ii:51892: warning: '' may be used uninitialized in
this function
dof_renumbering.ii:51892: note: '' was declared here

The warning comes from using the unnamed object 'dfs_visitor()', which is
of this type:

  struct empty
  {};


  struct dfs_visitor {
dfs_visitor() { }
dfs_visitor(empty vis) : m_vis(vis) { }
empty m_vis;
  };
---

I wished I could come up with a smaller testcase, this one is fairly
lengthy, though everything of importance happens in the last 20 or so lines.

Best
 Wolfgang


-- 


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

[Bug fortran/39006] New: Wrong result for array(:,ny:1:-1)) as actual argument (inverting order by negative strides)

[burnus at gcc dot gnu dot org]

Reported by Clive Page, http://gcc.gnu.org/ml/fortran/2009-01/msg00335.html

Fails with gfortran 4.1, 4.2, 4.3 and 4.4, but works with NAG f95, g95, ifort
(9.1, 11.0), openf95.

The proper result of the test program is:
--
 normal
   1   2   3   4
  10  20  30  40
 100 200 300 400
 y-inverted
 100 200 300 400<<<  These lines
  10  20  30  40<<<  are missing
   1   2   3   4<<<  with gfortran
--

The program:

!-
module testy_mod
implicit none
contains
subroutine mysub(text, array)
character(len=*), intent(in) :: text
integer, intent(in) :: array(:,:)
integer :: j
print *, text
do j = 1, ubound(array,2)
   print '(1i4)', array(:,j)
end do
end subroutine mysub
end module testy_mod

program testy
use testy_mod
implicit none
integer, parameter :: nx = 4, ny = 3
integer :: array(nx,ny)
data array / 1,2,3,4, 10,20,30,40, 100,200,300,400 /
call mysub('normal', array)
call mysub('y-inverted', array(:,ny:1:-1))
end program


-- 
   Summary: Wrong result for  array(:,ny:1:-1))  as actual argument
(inverting order by negative strides)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

[doko at ubuntu dot com]

--- Comment #5 from doko at ubuntu dot com  2009-01-28 17:08 ---
PR38292 shows similiar error messages


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #11 from r dot emrich at de dot tecosim dot com  2009-01-28 
17:06 ---
I vote for P1 because it's a secondary platform.


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #10 from r dot emrich at de dot tecosim dot com  2009-01-28 
17:01 ---
Created an attachment (id=17202)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17202&action=view)
assembler source


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #9 from r dot emrich at de dot tecosim dot com  2009-01-28 
17:01 ---
Created an attachment (id=17201)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17201&action=view)
preproccesed source


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #8 from r dot emrich at de dot tecosim dot com  2009-01-28 
16:52 ---
Created an attachment (id=17200)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17200&action=view)
self contained testcase

cross compiled to target x86_64-pc-mingw32 segfaults.
commandline: x86_64-pc-mingw32-g++ -Wall -pedantic -g0 -O3 -o segfault
segfault.cpp


-- 


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

[Bug preprocessor/38990] preprocessing different in g++ -E and regular compiling.

[kkylheku at gmail dot com]

--- Comment #2 from kkylheku at gmail dot com  2009-01-28 16:30 ---
(In reply to comment #1)
> Confirmed.

Thanks. By the way, I started looking at patching this. My suspicions were
confirmed that this is a case of pasting together invalid tokens. The compiler
sees the tokens individually, because it's closely integrated with the
preprocessor. But when the tokens are converted to text, they resemble a valid
string literal. The embedded newlines are gone.

What's happening is that the input:

"Hello,\n  %s!",\n  "world");

is being tokenized like this:

{"Hello,}{%}{s}{",}{"world"}{)}

The "Hello, and ", are assigned the special lexical category CPP_OTHER, because
they are improper tokens. Of course % is an operator and s is a CPP_NAME
identifier.  Also note how everything becomes one argument to the macro, since
the comma is never seen as a independent token.

A possible way to fix this bug would be in the function lex_string to not back
up over the \n that is found in the middle of a string literal, so that the
newline becomes part of the CPP_OTHER token.  This behavior might have to be
language-dependent, though. It looks like assembly language programs may be
depending on the current behavior, hence this test in lex_string:

  if (type == CPP_OTHER && CPP_OPTION (pfile, lang) != CLK_ASM)
cpp_error (pfile, CPP_DL_PEDWARN, "missing terminating %c character",
   (int) terminator);

Or maybe CPP_OTHER tokens should never be pasted together with anything that
follows them because even inserting a space is not good enough; maybe a newline
should be emitted between CPP_OTHER and the next token instead of a space, if
the language is other than CLK_ASM.

Will experiment.


-- 


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

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

[jason at redhat dot com]

--- Comment #7 from jason at redhat dot com  2009-01-28 16:29 ---
Subject: Re:  [4.4 Regression] g++.dg/init/const7.C XFAILed

rguenther at suse dot de wrote:
>> Why do it in the FE?  This seems like a language-independent optimization.
> 
> Do it in the FE if the FE wants it to be optimized to a constant.
> Otherwise sure - it is a language-independent optimization.  But fold
> isn't a proper optimizer ;)

I don't understand the distinction you're making; it seems to me that 
reducing expressions to simpler forms that are more easily optimized is 
exactly what fold is for.  I don't see the difference between this and, 
say, reducing "1 + 2" to "3".

The FE doesn't especially want this to be a constant; it isn't a valid 
constant expression in C++, because it involves a subtraction of two 
pointers.

Jason


-- 


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

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

--- Comment #18 from jakub at gcc dot gnu dot org  2009-01-28 16:06 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2009-01-28 16:05 ---
Subject: Bug 38740

Author: jakub
Date: Wed Jan 28 16:05:41 2009
New Revision: 143733

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143733
Log:
PR rtl-optimization/38740
* reorg.c (gate_handle_delay_slots): Avoid dbr scheduling
if !optimize.
* config/mips/mips.c (mips_reorg): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c
trunk/gcc/reorg.c


-- 


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

[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented

[zadeck at naturalbridge dot com]

--- Comment #4 from zadeck at naturalbridge dot com  2009-01-28 16:03 
---
Subject: Re:  [4.3/4.4 Regression] life passes dump
 option still documented

rguenth at gcc dot gnu dot org wrote:
> --- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-24 10:20 
> ---
> GCC 4.3.3 is being released, adjusting target milestone.
>
>
>   
This may be more a change than is acceptable right now for 4.4.   If so
I will sit on this patch until 4.5 opens up.   The patch is basically a
complete rewrite of the part of invoke.texi that deals with dump options
for the rtl pass.   This section had badly rotted. 

I started from a grep of the sources looking for "rtl_opt_pass" and
documented all of the passes that i found in mostly alphabetical
order.   Where the old version documented several passes together, I
kept that unless things had changed.   In total there were about a half
dozen passes that were no longer there and about a dozen new passes that
had not been documented.  

I did make some changes in the code, which is the reason that this may
not be acceptable to 4.4.  The changes are pretty harmless:  all of them
involve either removing the pass name or changing it.  

1) Pass names that contained dashes had the dashes changed to
underscores.   About half used slashes and half underscores and I went
with underscores to avoid a possible ambiguity with the options parsing.

2) I also removed the pass name from 6 passes that do not print anything
or dump the code. 

3) Files that contained multiple passes with names of the form xx,
xx2... were renamed xx1,xx2.
This later change causes a test suit failure which was fixed.

All of these changes are pretty minor.  The only possible failure these
can cause are in the test suite where dump files are scanned.  

I tested this on x86 and ppc both 32 and 64.  It is possible that there
are platform specific regression tests that scan for dump files that
were not caught on these four targets.

I also left in lreg and greg.These are at the end and need to be
deleted along with those passes.

I have enclosed a copy of the new text.  The diff is unreadable. 

ok for 4.4 or should i wait for 4.5?

Kenny


2009-01-28  Kenneth Zadeck 

PR middle-end/35854
* doc/invoke.texi (rtl debug options): Complete rewrite.
* auto-inc-dec.c (pass_inc_dec): Rename pass from "auto-inc-dec"
to auto_inc_dec".
* df-core.c (df_pass_initialize_opt, df_pass_initialize_no_opt,
df_pass_finish): Removed pass name.
* mode-switching.c (pass_mode_switching): Rename pass from
"mode-sw" to "mode_sw".
* except.c (pass_convert_to_eh_ranges): Rename pass from
"eh-ranges" to "eh_ranges".
* regclass.c (pass_regclass_init, pass_subregs_of_mode_init,
pass_subregs_of_mode_finish): Removed pass name.
* lower-subreg.c (pass_lower_subreg): Renamed pass from "subreg"
to "subreg1".


2009-01-28  Kenneth Zadeck 

PR middle-end/35854
* gcc.dg/lower-subreg-1.c: Renamed dump pass from "subreg" to
"subreg1"   


==
@item -...@var{letters}
@itemx -fdump-r...@var{pass}
@opindex d
Says to make debugging dumps during compilation at times specified by
@var{letters}.This is used for debugging the RTL-based passes of the
compiler.  The file names for most of the dumps are made by appending a
pass number and a word to the @var{dumpname}.  @var{dumpname} is generated
from the name of the output file, if explicitly specified and it is not
an executable, otherwise it is the basename of the source file. These
switches may have different effects when @option{-E} is used for
preprocessing.

Debug dumps can be enabled with a @option{-fdump-rtl} switch or some
@option{-d} option @var{letters}.  Here are the possible
letters for use in @var{pass} and @var{letters}, and their meanings:

@table @gcctabopt

@item -fdump-rtl-alignments
@opindex fdump-rtl-alignments
Dump after branch alignments have been computed.

@item -fdump-rtl-asmcons
@opindex fdump-rtl-asmcons
Dump after fixing rtl statements that have unsatisfied in/out constraints.

@item -fdump-rtl-auto_inc_dec
@opindex fdump-rtl-auto_inc_dec
Dump after auto-inc-dec discovery.  This pass is only run on
architectures that have auto inc or auto dec instructions.

@item -fdump-rtl-barriers
@opindex fdump-rtl-barriers
Dump after cleaning up the barrier instructions.

@item -fdump-rtl-bbpart
@opindex fdump-rtl-bbpart
Dump after partitioning hot and cold basic blocks.

@item -fdump-rtl-bbro
@opindex fdump-rtl-bbro
Dump after block reordering.

@item -fdump-rtl-btl1
@itemx -fdump-rtl-btl2
@opindex fdump-rtl-btl2
@opindex fdump-rtl-btl2
@option{-fdump-rtl-btl1} and @option{-fdump-rtl-btl2} enable dumping
after the two branch
target load optimization passes.

@item -fdump-rtl-bypass
@opindex fdump-rtl-bypass
Dump after jump bypassing and control flow optimizations.

@item -fdump-rtl-combine
@opindex fdump-rtl-combine
Dump after the RTL instruction combination pass.

@item -fdump-rtl-compgo

[Bug testsuite/39005] New: [LTO]: Not all testcases support LTO

[hjl dot tools at gmail dot com]

I got many

f951: warning: command line option "-flto" is valid for C/C++ but not for
Fortran
f951: warning: command line option "-fwhopr" is valid for C/C++ but not for
Fortran

Can we don't test LTO on testcases which don't support it?


-- 
   Summary: [LTO]:  Not all testcases support LTO
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: dnovillo at google dot com
ReportedBy: hjl dot tools at gmail dot com


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

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2009-01-28 15:20 ---
The problem is -O0 together with -fdelayed-branch.  Shouldn't we just reject it
or silently not do dbr at !optimize?  If it is really important to support (I
don't see any rationale for it), then the problem is that ira.c only calls
df_analyze after RA if -O1 and above:
  df_finish_pass (true);
  if (optimize > 1)
df_live_add_problem ();
  df_scan_alloc (NULL);
  df_scan_blocks ();

  if (optimize)
df_analyze ();

  timevar_pop (TV_IRA);
}

No other -O0 pass in between ira and dbr calls df_analyze and dbr itself can't
call it, as the cfg is gone.  So, if we really want to support this, either
ira.c could
  /* -O0 -fdelayed-branch uses dataflow info during dbr pass, but uses it after
 the cfg is gone.  Ensure it is updated even in that case.  */
  if (optimize || flag_delayed_branch)
df_analyze ();
or we could have some pass right before pass_free_cfg that would be gated on
!optimize && flag_delayed_branch and would call df_analyze ().


-- 


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

[Bug middle-end/39004] Revision 143730 breaks LTO

[dnovillo at gcc dot gnu dot org]

--- Comment #2 from dnovillo at gcc dot gnu dot org  2009-01-28 15:17 
---

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01367.html


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39004] Revision 143730 breaks LTO

[dnovillo at gcc dot gnu dot org]

--- Comment #1 from dnovillo at gcc dot gnu dot org  2009-01-28 15:05 
---
Subject: Bug 39004

Author: dnovillo
Date: Wed Jan 28 15:05:16 2009
New Revision: 143731

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

PR middle-end/39004
* lto-function-in.c (input_local_var_decl): Remove unused
locals CONTEXT_TAG and CONTEXT.


Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/lto-function-in.c


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #7 from r dot emrich at de dot tecosim dot com  2009-01-28 
14:57 ---
Anyway I will try to create a self contained small testcase.


-- 


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

[Bug middle-end/39004] New: Revision 143730 breaks LTO

[hjl dot tools at gmail dot com]

I got

cc1: warnings being treated as errors
../../src-lto/gcc/lto-function-in.c: In function âinput_local_var_declâ:
../../src-lto/gcc/lto-function-in.c:1135: error: unused variable âcontext_tagâ
../../src-lto/gcc/lto-function-in.c:1134: error: unused variable âcontextâ
make[5]: *** [lto-function-in.o] Error 1


-- 
   Summary: Revision 143730 breaks LTO
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: dnovillo at google dot com
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/39001] lto branch doesn't build

[ramana dot r at gmail dot com]

--- Comment #2 from ramana dot r at gmail dot com  2009-01-28 14:49 ---

(In reply to comment #0)
> It doesn't build on SLES10 either, libelf0-0.8.10-36, it ICEs during
> build of libgcc:
> 
> ...
> /gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: internal
> compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> 
> libelf shouldn't come into play while building, no?
> 
> Program received signal SIGSEGV, Segmentation fault.
> output_call_frame_info (for_eh=0)
>at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
> 806   tree personality = DECL_FUNCTION_PERSONALITY (decl);
> 
> #0  output_call_frame_info (for_eh=0)
>at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
> #1  0x004ccf37 in dwarf2out_frame_finish ()
>at /gcc/spec/sb-haydn-df-64/gcc/gcc/dwarf2out.c:3351
> #2  0x00630dd6 in toplev_main (argc=, argv=0x0)
>at /gcc/spec/sb-haydn-df-64/gcc/gcc/toplev.c:1023
> #3  0x2ae177b25154 in __libc_start_main () from /lib64/libc.so.6
> #4  0x00404199 in _start ()
> 
> this is on x86_64, the above ICE is with -m32.
> 
> Richard.
> 

The same trouble appears on x86_64 Debian etch. 


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #6 from r dot emrich at de dot tecosim dot com  2009-01-28 
14:45 ---
(In reply to comment #3)
> We need the preprocessed source of a *complete* (including main) program to be
> able to reproduce this.
> 

That's a little bit difficult here. It's a really large application.
But what I see from the assembler source is the following.

The spnapshot produces:

.globl __Z18calc_tria_height_2P4NODES0_S0_RSoRiS2_RdS3_S3_
.def__Z18calc_tria_height_2P4NODES0_S0_RSoRiS2_RdS3_S3_;.scl   
2;  .type   32; .endef
__Z18calc_tria_height_2P4NODES0_S0_RSoRiS2_RdS3_S3_:
subq$8, %rsp
xorpd   %xmm3, %xmm3
.
.
.
L15:
addq$8, %rsp
ret

here the function returns.


trunk produces:

.globl __Z18calc_tria_height_2P4NODES0_S0_RSoRiS2_RdS3_S3_
.def__Z18calc_tria_height_2P4NODES0_S0_RSoRiS2_RdS3_S3_;.scl   
2;  .type   32; .endef
__Z18calc_tria_height_2P4NODES0_S0_RSoRiS2_RdS3_S3_:
subq$88, %rsp
xorpd   %xmm3, %xmm3
.
.
.
movsd   %xmm8, (%rax)
ret

This looks like the stackpointer is no restored.


-- 


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

[Bug c++/39002] codegen bug?

[falk at debian dot org]

--- Comment #5 from falk at debian dot org  2009-01-28 14:44 ---
(In reply to comment #4)
> What I can try is finding the revision which causes the fault.

While that would certainly be helpful, it's unlikely that anybody would be
willing to debug this without a usable testcase.


-- 


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

[Bug c++/39003] internal compiler error: in output_parm_decl, at lto-function-out.c:2652

[rubidium at openttd dot org]

--- Comment #1 from rubidium at openttd dot org  2009-01-28 14:42 ---
Created an attachment (id=17199)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17199&action=view)
result of gcc -save-temps


-- 


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

[Bug c++/39003] New: internal compiler error: in output_parm_decl, at lto-function-out.c:2652

[rubidium at openttd dot org]

Bug in lto revision 143731 (gcc 4.4 revision 143712 works fine)

Using built-in specs.
COLLECT_GCC=g++lto-
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --program-suffix=lto- --with-arch=pentium-m
--enable-threads --enable-languages=lto,c,c++
Thread model: posix
gcc version 4.4.0 20090127 (experimental) (lto merged with rev 143693)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-fomit-frame-pointer' '-flto'
'-DUNIX' '-Wall' '-Wno-multichar' '-Wsign-compare' '-Wundef' '-Wwrite-strings'
'-Wpointer-arith' '-Wno-uninitialized' '-W' '-Wno-unused-parameter'
'-Wformat=2' '-Wredundant-decls' '-fno-strict-aliasing' '-fno-strict-overflow'
'-DWITH_ALLEGRO' '-I/usr/include' '-DWITH_SDL' '-I/usr/include/SDL'
'-D_REENTRANT' '-DWITH_ZLIB'
'-I/home/rubidium/openttd/clean3/src/3rdparty/squirrel/include'
'-DNO_GARBAGE_COLLECTOR' '-DWITH_PNG' '-I/usr/include/libpng12'
'-DWITH_FONTCONFIG' '-DWITH_FREETYPE' '-I/usr/include/freetype2' '-DWITH_ICU'
'-D_REENTRANT' '-I/usr/include' '-DENABLE_NETWORK' '-DWITH_PERSONAL_DIR'
'-DPERSONAL_DIR=".openttd"'
'-DGLOBAL_DATA_DIR="/usr/local/share/games/openttd"' '-I'
'/home/rubidium/openttd/clean3/objs/release' '-I'
'/home/rubidium/openttd/clean3/objs/lang' '-c' '-o' 'ai/ai_scanner.o'
'-shared-libgcc' '-mtune=generic' '-march=pentium-m'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -E -quiet -v
-I/usr/include -I/usr/include/SDL
-I/home/rubidium/openttd/clean3/src/3rdparty/squirrel/include
-I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include -I
/home/rubidium/openttd/clean3/objs/release -I
/home/rubidium/openttd/clean3/objs/lang -D_GNU_SOURCE -DUNIX -DWITH_ALLEGRO
-DWITH_SDL -D_REENTRANT -DWITH_ZLIB -DNO_GARBAGE_COLLECTOR -DWITH_PNG
-DWITH_FONTCONFIG -DWITH_FREETYPE -DWITH_ICU -D_REENTRANT -DENABLE_NETWORK
-DWITH_PERSONAL_DIR -DPERSONAL_DIR=".openttd"
-DGLOBAL_DATA_DIR="/usr/local/share/games/openttd"
/home/rubidium/openttd/clean3/src/ai/ai_scanner.cpp -mtune=generic
-march=pentium-m -Wall -Wno-multichar -Wsign-compare -Wundef -Wwrite-strings
-Wpointer-arith -Wno-uninitialized -W -Wno-unused-parameter -Wformat=2
-Wredundant-decls -fomit-frame-pointer -flto -fno-strict-aliasing
-fno-strict-overflow -O2 -fpch-preprocess -o ai_scanner.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
  as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "/usr/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/SDL
 /home/rubidium/openttd/clean3/src/3rdparty/squirrel/include
 /usr/include/libpng12
 /usr/include/freetype2
 /home/rubidium/openttd/clean3/objs/release
 /home/rubidium/openttd/clean3/objs/lang
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0

/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu

/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-fomit-frame-pointer' '-flto'
'-DUNIX' '-Wall' '-Wno-multichar' '-Wsign-compare' '-Wundef' '-Wwrite-strings'
'-Wpointer-arith' '-Wno-uninitialized' '-W' '-Wno-unused-parameter'
'-Wformat=2' '-Wredundant-decls' '-fno-strict-aliasing' '-fno-strict-overflow'
'-DWITH_ALLEGRO' '-I/usr/include' '-DWITH_SDL' '-I/usr/include/SDL'
'-D_REENTRANT' '-DWITH_ZLIB'
'-I/home/rubidium/openttd/clean3/src/3rdparty/squirrel/include'
'-DNO_GARBAGE_COLLECTOR' '-DWITH_PNG' '-I/usr/include/libpng12'
'-DWITH_FONTCONFIG' '-DWITH_FREETYPE' '-I/usr/include/freetype2' '-DWITH_ICU'
'-D_REENTRANT' '-I/usr/include' '-DENABLE_NETWORK' '-DWITH_PERSONAL_DIR'
'-DPERSONAL_DIR=".openttd"'
'-DGLOBAL_DATA_DIR="/usr/local/share/games/openttd"' '-I'
'/home/rubidium/openttd/clean3/objs/release' '-I'
'/home/rubidium/openttd/clean3/objs/lang' '-c' '-o' 'ai/ai_scanner.o'
'-shared-libgcc' '-mtune=generic' '-march=pentium-m'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -fpreprocessed
ai_scanner.ii -quiet -dumpbase ai_scanner.cpp -mtune=generic -march=pentium-m
-auxbase-strip ai/ai_scanner.o -O2 -Wall -Wno-multichar -Wsign-compare -Wundef
-Wwrite-strings -Wpointer-arith -Wno-uninitialized -W -Wno-unused-parameter
-Wformat=2 -Wredundant-decls -version -fomit-frame-pointer -flto
-fno-strict-aliasing -fno-strict-overflow -o ai_scanner.s
GNU C++ (lto merged with rev 143693) version 4.4.0 20090127 (experimental)
(i686-pc-linux-gnu)
compiled by GNU C version 4.4.0 20090127 (experimental), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8dc3

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #4 from r dot emrich at de dot tecosim dot com  2009-01-28 
14:27 ---
What I can try is finding the revision which causes the fault.


-- 


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

[Bug c++/39002] codegen bug?

[falk at debian dot org]

--- Comment #3 from falk at debian dot org  2009-01-28 14:25 ---
We need the preprocessed source of a *complete* (including main) program to be
able to reproduce this.


-- 

falk at debian dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #2 from r dot emrich at de dot tecosim dot com  2009-01-28 
14:22 ---
Created an attachment (id=17198)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17198&action=view)
assembler source which segfaults

This one segfaults at ret statment at the end.


-- 


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

[Bug c++/39002] codegen bug?

[r dot emrich at de dot tecosim dot com]

--- Comment #1 from r dot emrich at de dot tecosim dot com  2009-01-28 
14:20 ---
Created an attachment (id=17197)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17197&action=view)
assembler source

This one works.


-- 


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

[Bug c++/39002] New: codegen bug?

[r dot emrich at de dot tecosim dot com]

I have a complex C++ application, which used to work at least until gcc-4.4.0
snapshot 20081219, which now segfaults in a strange way.

double distance_2(NODE *P_node1, NODE *P_node2)
{
  return
sqrt(((*P_node1).globalx-(*P_node2).globalx)*((*P_node1).globalx-(*P_node2).globalx)+
 
((*P_node1).globaly-(*P_node2).globaly)*((*P_node1).globaly-(*P_node2).globaly)+
 
((*P_node1).globalz-(*P_node2).globalz)*((*P_node1).globalz-(*P_node2).globalz));
}


void calc_tria_height_2(NODE *n1, NODE *n2, NODE *n11,ostream &out_info,int
&xerror,int &xwarning,double &x,double &y,double &z)
{
  if( distance_2(n1,n2) == 0.0 )
{
  x = (*n11).globalx;
  y = (*n11).globaly;
  z = (*n11).globalz;
  return;
}
  if( distance_2(n1,n11) == 0.0 )
{
  x = (*n11).globalx;
  y = (*n11).globaly;
  z = (*n11).globalz;
  return;
}
  if( distance_2(n2,n11) == 0.0 )
{
  x = (*n11).globalx;
  y = (*n11).globaly;
  z = (*n11).globalz;
  return;
}

  double a1, b1 , c1, la1, la1max;
  double dx, dy, dz, dxyz;
  double dxa1;


  a1 = (*n2).globalx - (*n1).globalx;
  b1 = (*n2).globaly - (*n1).globaly;
  c1 = (*n2).globalz - (*n1).globalz;

  la1max = sqrt (a1 * a1 + b1 * b1 + c1 * c1);

  a1 = a1 / la1max;
  b1 = b1 / la1max;
  c1 = c1 / la1max;

  dx = (*n1).globalx - (*n11).globalx;
  dy = (*n1).globaly - (*n11).globaly;
  dz = (*n1).globalz - (*n11).globalz;

  dxyz = dx * dx + dy * dy + dz * dz;

  dxa1 = 2.0 * dx * a1 + 2.0 * dy * b1 + 2.0 * dz * c1;

  la1 = -dxa1 / 2.0;

  x = (*n1).globalx + (a1 * la1);
  y = (*n1).globaly + (b1 * la1);
  z = (*n1).globalz + (c1 * la1);

  return;
}

compiled with -g0 -O3 it segfaults at the last return.

I will upload the assembler files for gcc snapshot and for trunk.


-- 
   Summary: codegen bug?
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-mingw32


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

[Bug middle-end/38996] [LTO] lto1 doesn't work on RHEL5

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2009-01-28 14:05 ---
Subject: Bug 38996

Author: hjl
Date: Wed Jan 28 14:04:52 2009
New Revision: 143729

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143729
Log:
2009-01-28  H.J. Lu  

PR middle-end/38996
* lto-elf.c (DEFINE_INIT_EHDR): Initialize e_version.

Modified:
branches/lto/gcc/lto/ChangeLog
branches/lto/gcc/lto/lto-elf.c


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

--- Comment #40 from rob1weld at aol dot com  2009-01-28 13:52 ---
Notes from 38820: I had "Known to fail" set to 4.4.0 4.3.2

Another 'proof' this is a Bug.

You are allowed to build GCC after you set (reasonable) Environment
variables. Examples are:
export set CC="gcc -v"
export set CC="gcc -mregparm=2"
export set CC="gcc -msseregparm"
export set CC="gcc gcc -ffloat-store -msse4 -mfpmath=sse,387"


Further support for the argument that this is a Bug is shown in "info gcc" :

`-mregparm=NUM'
`-msseregparm'
 *Warning:* if you use this switch, and NUM is nonzero, then you
 must build all modules with the same value, including any
 libraries.  This includes the system libraries and startup modules.

You are allowed to compile GCC in this manner (and may desire to do so
for testing purposes). If you do build GCC this way then GCC_EXEC_PREFIX
must be set correctly (to the newly compiled system libraries and startup
modules).

Rob


-- 


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

[Bug bootstrap/39001] lto branch doesn't build

[dnovillo at gcc dot gnu dot org]

--- Comment #1 from dnovillo at gcc dot gnu dot org  2009-01-28 13:41 
---

Additional information on the failure and a suggestion on a possible fix:

http://gcc.gnu.org/ml/gcc/2009-01/msg00074.html


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dnovillo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-28 13:41:30
   date||


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

[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2009-01-28 13:34 ---
Created an attachment (id=17196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17196&action=view)
PR38740.C

Simplified testcase.


-- 


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

[Bug bootstrap/39001] New: lto branch doesn't build

[rguenth at gcc dot gnu dot org]

It doesn't build on SLES10 either, libelf0-0.8.10-36, it ICEs during
build of libgcc:

...
/gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

libelf shouldn't come into play while building, no?

Program received signal SIGSEGV, Segmentation fault.
output_call_frame_info (for_eh=0)
   at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
806   tree personality = DECL_FUNCTION_PERSONALITY (decl);

#0  output_call_frame_info (for_eh=0)
   at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
#1  0x004ccf37 in dwarf2out_frame_finish ()
   at /gcc/spec/sb-haydn-df-64/gcc/gcc/dwarf2out.c:3351
#2  0x00630dd6 in toplev_main (argc=, argv=0x0)
   at /gcc/spec/sb-haydn-df-64/gcc/gcc/toplev.c:1023
#3  0x2ae177b25154 in __libc_start_main () from /lib64/libc.so.6
#4  0x00404199 in _start ()

this is on x86_64, the above ICE is with -m32.

Richard.


-- 
   Summary: lto branch doesn't build
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: bootstrap
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=39001

[Bug target/39000] New: internal compiler error: in output_expr_operand, at lto-function-out.c:1200

[schwab at suse dot de]

/usr/local/gcc/gcc-20090128/Build/gcc/testsuite/g++/../../g++
-B/usr/local/gcc/gcc-20090128/Build/gcc/testsuite/g++/../../
/usr/local/gcc/gcc-20090128/gcc/testsuite/g++.dg/debug/template1.C  -nostdinc++
-I/usr/local/gcc/gcc-20090128/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux
-I/usr/local/gcc/gcc-20090128/Build/ia64-suse-linux/libstdc++-v3/include
-I/usr/local/gcc/gcc-20090128/libstdc++-v3/libsupc++
-I/usr/local/gcc/gcc-20090128/libstdc++-v3/include/backward
-I/usr/local/gcc/gcc-20090128/libstdc++-v3/testsuite/util -fmessage-length=0
-gdwarf-21 -flto   -S  -o template1.s
/usr/local/gcc/gcc-20090128/gcc/testsuite/g++.dg/debug/template1.C:15: internal
compiler error: in output_expr_operand, at lto-function-out.c:1200

 
TI
size 
unit size 
align 128 symtab 0 alias set -1 canonical type 0x2066ac40
pointer_to_this >
unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2066ad00
pointer_to_this >
constant
arg 0 
TI size  unit size 
align 128 symtab 0 alias set -1 canonical type 0x206ac240
method basetype 
arg-types 
chain >>
pointer_to_this >
addressable used nothrow public static weak autoinline no-static-chain
virtual decl_5 DI defer-output file
/usr/local/gcc/gcc-20090128/gcc/testsuite/g++.dg/debug/template1.C line 12 col
11 align 128 initial  abstract_origin 
arguments 
readonly used unsigned DI file
/usr/local/gcc/gcc-20090128/gcc/testsuite/g++.dg/debug/template1.C line 12 col
14 size  unit size 
align 64 context 
abstract_origin  arg-type >
result 
ignored VOID file
/usr/local/gcc/gcc-20090128/gcc/testsuite/g++.dg/debug/template1.C line 12 col
17
align 8 context >
pending-inline-info 0x20535f80 template-info 0x206863d0
saved-insns 0x205823a0
chain 
addressable used nothrow public static weak autoinline
no-static-chain virtual decl_5 DI defer-output file
/usr/local/gcc/gcc-20090128/gcc/testsuite/g++.dg/debug/template1.C line 12 col
11 align 128 initial  abstract_origin  arguments  result

pending-inline-info 0x205361b0 template-info
0x206863d0
saved-insns 0x20582580>>
arg 1  constant 0>>


-- 
   Summary: internal compiler error: in output_expr_operand, at lto-
function-out.c:1200
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: ia64-*-*


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