[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2010-04-05 06:59 ---
Subject: Bug 43519

Author: spop
Date: Mon Apr  5 06:58:46 2010
New Revision: 157963

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157963
Log:
Compute min and max bounds for IVs and infer types.

2010-04-04  Sebastian Pop  

PR middle-end/43519
* Makefile.in (graphite-clast-to-gimple.o): Depends on langhooks.h.
* graphite-clast-to-gimple.c: Include langhooks.h.
(max_signed_precision_type): New.
(max_precision_type): Takes two types as arguments.
(precision_for_value): New.
(precision_for_interval): New.
(gcc_type_for_interval): New.
(gcc_type_for_value): New.
(gcc_type_for_clast_term): New.
(gcc_type_for_clast_red): New.
(gcc_type_for_clast_bin): New.
(gcc_type_for_clast_expr): Split up into several functions.
(gcc_type_for_clast_eq): Rewritten.
(compute_bounds_for_level): New.
(compute_type_for_level_1): New.
(compute_type_for_level): New.
(gcc_type_for_cloog_iv): Removed.
(gcc_type_for_iv_of_clast_loop): Rewritten.
(graphite_create_new_loop): Compute the lower and upper bound types
with gcc_type_for_clast_expr.
(graphite_create_new_loop_guard): Same.
(find_cloog_iv_in_expr): Removed.
(compute_cloog_iv_types_1): Removed.
(compute_cloog_iv_types): Removed.
(gloog): Do not call compute_cloog_iv_types.
* graphite-sese-to-poly.c (new_gimple_bb): Do not initialize
GBB_CLOOG_IV_TYPES.
(free_data_refs_aux): Do not free GBB_CLOOG_IV_TYPES.
* sese.h (struct gimple_bb): Removed field cloog_iv_types.
(GBB_CLOOG_IV_TYPES): Removed.

* gcc.dg/graphite/run-id-pr42644.c: Call abort.

Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/Makefile.in
branches/graphite/gcc/graphite-clast-to-gimple.c
branches/graphite/gcc/graphite-sese-to-poly.c
branches/graphite/gcc/sese.h
branches/graphite/gcc/testsuite/gcc.dg/graphite/run-id-pr42644.c


-- 


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

[Bug debug/42648] [4.5 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n > 0

[aoliva at gcc dot gnu dot org]

--- Comment #3 from aoliva at gcc dot gnu dot org  2010-04-05 07:48 ---
Yeah, fixed (i686-linux-gnu) by revision 156693, from Feb 11.  I couldn't
duplicate it at all on x86_64-linux-gnu.  If the problem is still present on
some other platform, please reopen and specify.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[developer at sandoe-acoustics dot co dot uk]

--- Comment #20 from developer at sandoe-acoustics dot co dot uk  
2010-04-05 08:32 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html


-- 


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

--- Comment #30 from developer at sandoe-acoustics dot co dot uk  
2010-04-05 08:33 ---
(In reply to comment #29)
> Iain,
>Do please post the revised patch to gcc-patches with a changelog. That may
> incite a review from the emutls maintainers.

see: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html


-- 


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

[Bug target/40905] GCC creates invalid executable with auto-imported DLL and __attribute__((cold))

[ktietz at gcc dot gnu dot org]

--- Comment #7 from ktietz at gcc dot gnu dot org  2010-04-05 09:17 ---
(In reply to comment #6)
> I added you to this thread, as you merged new pseudo-relocation code to
> mingw.org's runtime.
> 

As cygwin and mingw.org are supporting now new linker generated
runtime-pseudo-relocation, could you please confirm that your issue is solved.
I tested your issue and for me it works with recent version of cygwin/mingw.org
runtimes.

Kai


-- 


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

[Bug bootstrap/12026] m68k-coff build fails due to undefined references to _EH_FRAME_BEGIN

[schwab at linux-m68k dot org]

--- Comment #5 from schwab at linux-m68k dot org  2010-04-05 09:36 ---
m68k-*-coff is no longer supported.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-05 09:47 ---
You shouldn't be using type_for_size but instead use
build_nonstandard_integer_type.


-- 


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

[Bug debug/43439] Dwarf:Wrong location information of function argument

[tanaka at personal-media dot co dot jp]

--- Comment #1 from tanaka at personal-media dot co dot jp  2010-04-05 
09:57 ---
I'm Sorry.

This binary file can be read correctly, by gdb-7.1.

Unlike gcc-3, the value of DW_OP_fbreg does not express the
offset of arguments from frame pointer directly.


-- 

tanaka at personal-media dot co dot jp changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/42607] add information about how to compile a module

[envite at rolamasao dot org]

--- Comment #8 from envite at rolamasao dot org  2010-04-05 10:00 ---
I do not care particularly about automake and such, but precisely because the
Fortran standard does not say a word about module files the user expects to get
info about them _for his compiler_ in _his compiler documentation_.

That's why I think we must (yes, I included myself, because I've spent so much
time trying to figure out how gfortran module files work) create a
documentation section for them. User has the right to know what module files
are (not necessarily the internals), when they're created, where they're stored
and searched for, and whether they're changed if source code change does not
change the module interface.


-- 


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

[Bug inline-asm/43518] ARM register constraint for ldrd and strd instructions

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2010-04-05 10:02 
---
Please supply a full testcase, and explain precisely the problem you are
seeing.  I cannot determine from your initial post what problem you are seeing.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 GCC target triplet||arm


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

[Bug target/43644] __uint128_t missed optimizations.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-05 10:03 ---
Confirmed.  There may be (a) dup(s) for this bug.  The issue seems to be that
the ra doesn't pessimize the use of callee-saved regs.  Does it?

In example foo1 cprop-hardreg and dce get rid of the %rbx use, but that's
already after pro-/epilogue.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization, ra
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 10:03:09
   date||


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

[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-05 10:06 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 10:06:06
   date||


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

[Bug c/42599] arm-elf-gcc 4.4.2 internal compiler error in expand_expr_addr_1 at expr.c:6835

[rearnsha at gcc dot gnu dot org]

--- Comment #2 from rearnsha at gcc dot gnu dot org  2010-04-05 10:15 
---
Your source code isn't valid.  Naked functions can't just call other C
functions, as they have no prologue/epilogue sequences supplied by the
compiler.

Nevertheless, the compiler shouldn't ICE.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet||arm-elf
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 10:15:17
   date||


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

[Bug c++/43645] New: 32 bit pointer in top half of VM casts to unsigned long long incorrectly

[alangcarter at gmail dot com]

A 32 bit pointer with highest bit set ( >= 0x8000) is incorrectly cast to
unsigned long long. The top 32 bits of the unsigned long long are all set 1,
not 0. The problem does not occur if the pointer is less than 0x8000 or if
it is first cast to unsigned long and that is then cast to unsigned long long. 

Obviously the highest bit would indicate a negative value in a signed int of
the same size. It looks like some signed logic is being invoked inappropriately

Details provided from 4.3.3 on Ubuntu, also seen on 4.4.1 on Ubuntu and 4.1.2
on NetBSD. Exact same behaviour also seen with Microsoft Visual C++ 2008, but
not on Apple's version of 4.0.1.

Here is a small test program which demonstrates the problem, I'll attach the
.ii and gcc output:

#include 
#include 
#include 
using namespace std;

template void dump(string legend, T* data)
{
   // Display the bytes of the supplied type and its cout operator << rendition
   unsigned char* puc = (unsigned char*)data;

   cout << legend << ":" << endl;
   for(unsigned int i = 0; i < sizeof(T); i++)
  cout << hex << setw(2) << setfill('0') << (unsigned int)(puc[i]) << " ";
   cout << endl << hex << setw(16) << setfill('0') << *data << endl << endl;
}

int main(int argc, char **argv)
{
   void* pv1 = (void*)0x12345678;
   void* pv2 = (void*)0x87654321;
   unsigned long long int ulli;

   dump("small void*", &pv1);

   ulli = (unsigned long long int)pv1;
   dump("small void* cast to unsigned long long", &ulli);

   ulli = (unsigned long long int)(unsigned long int)pv1;
   dump("small void* cast to unsigned long cast to unsigned long long", &ulli);

   dump("large void*", &pv2);

   ulli = (unsigned long long int)pv2;
   dump("large void* cast to unsigned long long", &ulli);

   ulli = (unsigned long long int)(unsigned long int)pv2;
   dump("large void* cast to unsigned long cast to unsigned long long", &ulli);
}


-- 
   Summary: 32 bit pointer in top half of VM casts to unsigned long
long incorrectly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alangcarter at gmail dot com


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

[Bug c++/43645] 32 bit pointer in top half of VM casts to unsigned long long incorrectly

[alangcarter at gmail dot com]

--- Comment #1 from alangcarter at gmail dot com  2010-04-05 10:18 ---
Created an attachment (id=20307)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20307&action=view)
Source code of demo program


-- 


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

[Bug c++/43645] 32 bit pointer in top half of VM casts to unsigned long long incorrectly

[alangcarter at gmail dot com]

--- Comment #2 from alangcarter at gmail dot com  2010-04-05 10:19 ---
Created an attachment (id=20308)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20308&action=view)
.ii file from compiling test program


-- 


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

[Bug c++/43645] 32 bit pointer in top half of VM casts to unsigned long long incorrectly

[alangcarter at gmail dot com]

--- Comment #3 from alangcarter at gmail dot com  2010-04-05 10:20 ---
Created an attachment (id=20309)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20309&action=view)
g++ command and console output


-- 


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

[Bug c++/43645] 32 bit pointer in top half of VM casts to unsigned long long incorrectly

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-04-05 10:27 ---
This is implementation-defined.  See
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Arrays-and-pointers-implementation.html#Arrays-and-pointers-implementation


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|32 bit pointer in top half  |32 bit pointer in top half
   |of VM casts to unsigned long|of VM casts to unsigned long
   |long incorrectly|long incorrectly


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

[Bug c++/43646] New: decltype and std::integral_constant

[jwakely dot gcc at gmail dot com]

This was originally sent as an email to gcc-bugs:
http://gcc.gnu.org/ml/gcc-bugs/2010-04/msg00167.html
I'm entering it here on his behalf...

The following translation unit seems to show a bug exhibited by 4.4.3 and 4.5. 

#include  

template struct plus 
: std::integral_constant< 
decltype(X::value + Y::value), 
X::value + Y::value 
> { }; 

int main(int argc, char* argv[]) { 
return 0; 
} 

Compiling this file (test.cpp) with 

g++ -std=c++0x -l stdc++ test.cpp 

yields the following diagnostic: 

test.cpp:7: error: 'decltype ((X::value + Y::value))' 
is not a valid type for a template constant parameter 

Am I missing something? The following works as intended: 

#include  
#include  

template struct plus 
: std::integral_constant< 
typename std::identity::type, 
X::value + Y::value 
> { }; 

int main(int argc, char* argv[]) { 
return 0; 
} 

(i.e. just wrapping the use of decltype with std::identity)


-- 
   Summary: decltype and std::integral_constant
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com


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

[Bug c++/43646] decltype and std::integral_constant

[jwakely dot gcc at gmail dot com]

--- Comment #1 from jwakely dot gcc at gmail dot com  2010-04-05 11:39 
---
Is this related to DR 743 or 950, and so likely to get fixed when N3049 is
supported?


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.4.3 4.5.0


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

[Bug c++/43647] New: "confused by earlier errors, bailing out" for member template explicit specialization

[hovhannes_ter_meliqsetyan at yahoo dot com]

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix

gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) 

GNU C++ (Ubuntu 4.4.1-4ubuntu9) version 4.4.1 (x86_64-linux-gnu)
compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version
2.4.1-p2.

g++ -Wall -v -save-temps src/main.cpp 

src/test.hpp:26: error: specialization of ‘template void N::X::F()’ in
different namespace
src/test.hpp:14: error:   from definition of ‘template void N::X::F()’
src/test.hpp:28: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cc7hr4I6.out file, please attach this to
your bugreport.



namespace N {
 struct X;
}

struct N::X
{
 template < typename T >
 void F();

 template < typename T1, typename T2 >
 struct G
 {};

 template < typename T2 >
 struct G < int, T2 >;

};

template <>
void N::X::F < int >()
{
 std::cout << "F specialization" << std::endl;
}

int main()
{
 N::X x;
 x.F< int >();
 return 0;
}

If I am not wrong, the explicit specialization of "F()" must be defined in
namespace scope, but why gcc "crushes" from this incorrect code ?

Thanks in advance.


-- 
   Summary: "confused by earlier errors, bailing out" for member
template explicit specialization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hovhannes_ter_meliqsetyan at yahoo dot com


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

[Bug c++/43648] New: [4.5 regression] ICE with explicit destructor call and typedef

[bangerth at gmail dot com]

With mainline from 20100107, the following code fails on Mac OS X:
--
namespace dealii
{
  namespace FEValuesViews
  {
template  struct Scalar {};
  }

  template 
  struct X
  {
  FEValuesViews::Scalar scalars[dim*spacedim];

  void f()
{
  typedef dealii::FEValuesViews::Scalar ScalarView;
  scalars[0].ScalarView::~ScalarView ();
}
  };

  template struct X<2,2>;
}
-

>From what I can gather from the person who told me this, the error message
looks along the lines (line numbers/function names/file names are wrong,
though):

source/fe/fe_values.cc: In constructor
‘dealii::internal::FEValuesViews::Cache::Cache(const
dealii::FEValuesBase&) [with int dim = 1, int spacedim =
1]’:
source/fe/fe_values.cc:1486:31:   instantiated from
‘dealii::FEValuesBase::FEValuesBase(unsigned int, unsigned
int, dealii::UpdateFlags, const dealii::Mapping&, const
dealii::FiniteElement&) [with int dim = 1, int spacedim =
1]’
source/fe/fe_values.cc:3941:16:   instantiated from here
source/fe/fe_values.cc:1057:4: error: no type named ‘ScalarView’ in
‘class dealii::FEValuesViews::Scalar<1>’
source/fe/fe_values.cc:1057:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

The problem is that the code was written with the typedef, rather than
explicitly spelling out the full qualified class name, since some other
compilers do not grok it any other way.

Best
 W.


-- 
   Summary: [4.5 regression] ICE with explicit destructor call and
typedef
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com


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

[Bug c++/43647] "confused by earlier errors, bailing out" for member template explicit specialization

[hovhannes_ter_meliqsetyan at yahoo dot com]

--- Comment #1 from hovhannes_ter_meliqsetyan at yahoo dot com  2010-04-05 
12:25 ---
Created an attachment (id=20310)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20310&action=view)
main.ii file

And here is the attached main.ii file for this issue.


-- 


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

[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2010-04-05 12:34 ---
According to comment #6 this works now. Can the OP please confirm?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/43648] [4.5 regression] ICE with explicit destructor call and typedef

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-05 12:42 ---
Confirmed on i?86-linux.

gcc$ ./cc1plus -quiet t.Ct.C: In member function 'void dealii::X::f() [with int dim = 2, int spacedim = 2]':
t.C:20:19:   instantiated from here
t.C:16:8: error: no type named 'ScalarView' in 'struct
dealii::FEValuesViews::Scalar<2, 2>'
t.C:16:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 12:42:10
   date||
   Target Milestone|--- |4.5.0


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

[Bug target/39718] [4.5 Regression][cond-optab] crash on crx in IRA

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet||crx
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 12:43:38
   date||


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

[Bug c++/43647] "confused by earlier errors, bailing out" for member template explicit specialization

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-04-05 12:45 ---
4.5 doesn't get confused by earlier errors


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0
Version|unknown |4.4.1


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

[Bug c++/43648] [4.5 regression] ICE with explicit destructor call and typedef

[bangerth at gmail dot com]

--- Comment #2 from bangerth at gmail dot com  2010-04-05 12:46 ---
Thanks Richard for the quick confirmation.
I should have mentioned that this worked on previous versions up to at least
4.3.3.

W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.3.3


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

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

[steven at gcc dot gnu dot org]

--- Comment #46 from steven at gcc dot gnu dot org  2010-04-05 12:52 ---
What happened with the patch of comment #33?


-- 


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

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

[rguenther at suse dot de]

--- Comment #47 from rguenther at suse dot de  2010-04-05 12:54 ---
Subject: Re:  [4.4/4.5 Regression] 50% performance
 regression

On Mon, 5 Apr 2010, steven at gcc dot gnu dot org wrote:

> --- Comment #46 from steven at gcc dot gnu dot org  2010-04-05 12:52 
> ---
> What happened with the patch of comment #33?

scheduled for stage1 (maybe, after much cleanup)


-- 


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

[Bug c/43633] sizeof returns wrong size for large long long values when using -std=c99

[truedfx at gentoo dot org]

--- Comment #3 from truedfx at gentoo dot org  2010-04-05 12:54 ---
(In reply to comment #2)
> §6.4.4.1 Integer constants:
> 
> If an integer constant cannot be represented by any type in its list, it may
> have an extended integer type, if the extended integer type can represent its
> value. If all of the types in the list for the constant are signed, the
> extended integer type shall be signed.
> 
> Thus 9223372036854775808LL will be of some signed extended type, since it does
> not fit in long long.

It *may* have an extended integer type. If it doesn't (and it doesn't: gcc
doesn't have any of the standard's extended integer types, see
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Integers-implementation.html), such
a constant is simply invalid, and gcc, after reporting that, is free to make
the code behave however it likes. At least, as far as the standard is
concerned.


-- 


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

[Bug ada/37440] [4.4/4.5 Regression] GNAT Bug Box a-ngcefu.adb:397

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-04-05 12:55 ---
Joel, is this still a problem, or not? If so, please reconfirm the bug and
change the bug status back to NEW.


-- 


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

[Bug c++/43646] [C++0x] decltype and std::integral_constant

[bangerth at gmail dot com]

--- Comment #2 from bangerth at gmail dot com  2010-04-05 12:56 ---
I think this should work. I can't see how it would be invalid as template
argument for integral_constant but valid for identity.

W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||bangerth at gmail dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 12:56:39
   date||


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

[Bug ada/37440] [4.4/4.5 Regression] GNAT Bug Box a-ngcefu.adb:397

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2010-04-05 12:56 ---
*** Bug 40775 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

[rguenther at suse dot de]

--- Comment #48 from rguenther at suse dot de  2010-04-05 12:56 ---
Subject: Re:  [4.4/4.5 Regression] 50% performance
 regression

On Mon, 5 Apr 2010, rguenther at suse dot de wrote:

> --- Comment #47 from rguenther at suse dot de  2010-04-05 12:54 ---
> Subject: Re:  [4.4/4.5 Regression] 50% performance
>  regression
> 
> On Mon, 5 Apr 2010, steven at gcc dot gnu dot org wrote:
> 
> > --- Comment #46 from steven at gcc dot gnu dot org  2010-04-05 12:52 
> > ---
> > What happened with the patch of comment #33?
> 
> scheduled for stage1 (maybe, after much cleanup)

No, it even got applied.


-- 


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

[Bug rtl-optimization/40775] [4.4/4.5 Regression] ICE in find_valid_class, at reload.c:701

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2010-04-05 12:56 ---


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


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

[steven at gcc dot gnu dot org]

--- Comment #49 from steven at gcc dot gnu dot org  2010-04-05 13:01 ---
At least the tree-vrp.c bit did not get applied (as of trunk r157950)


-- 


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

[Bug c/36774] -Wmissing-prototypes triggers on nested functions

[pzhao at gcc dot gnu dot org]

--- Comment #5 from pzhao at gcc dot gnu dot org  2010-04-05 13:44 ---
Proposed patch
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00078.html


-- 


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

[Bug gcov-profile/26313] arm-elf-gcc with gcov option do not work

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2010-04-05 13:48 
---
Only just come across this report as the 'target' field was not set.

Have you tried a more recent compiler?

I suspect that gcov will need support from your C library in order to work
correctly, have you made sure that the code there is compiled with the
appropriate hooks?


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 GCC target triplet||arm


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

[Bug target/34064] ARM: missed optimization (conditional store)

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet||arm
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 13:52:04
   date||


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

[Bug target/33413] Please provide __sync_lock_test_and_set builtin for ARM using swap insn

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2010-04-05 13:53 
---
SWP is deprecated in the ARM architecture.  It would be a really bad idea to
get gcc to generate that by default as it will break compatibility.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 GCC target triplet||arm
 Resolution||WONTFIX


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

[Bug target/34523] configure does not recognize --with-cpu=arm926ejs but --with-cpu=arm926ej-s

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2010-04-05 13:55 
---
No, the canonical name for the CPU is correct -- with a dash.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 GCC target triplet||arm
 Resolution||INVALID


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

[Bug target/33123] internal compiler error: in decode_addr_const ( arm-linux-gcc 3.4.6)

[rearnsha at gcc dot gnu dot org]

--- Comment #4 from rearnsha at gcc dot gnu dot org  2010-04-05 13:59 
---
We cannot use unpreprocessed C file to replicate bugs -- you need to generate
pre-processed output (.i).  Use -save-temps as an extra option when
compiling.

Also, 3.4.6 is no-longer being maintained.  Can you reproduce this problem on a
more recent, maintained, version of the compiler (4.3.0 or later)?


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 GCC target triplet||arm-linux


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

[Bug target/33413] Please provide __sync_lock_test_and_set builtin for ARM using swap insn

[spam_from_gcc_bugzilla at chezphil dot org]

--- Comment #2 from spam_from_gcc_bugzilla at chezphil dot org  2010-04-05 
14:10 ---
Hi Richard,

This is obviously less of an issue than it was in 2007.

I think there are enough pre-ARMv6 systems still deployed that they cannot be
ignored, though.  For example, I believe that the Android native development
kit assumes that the hardware is >= ARMv5.

Currently, portable code need to do something like:

#if v6 or newer
...use gcc builtins, which generate ldx/stx...
#else
...use asm statements that generate swp...
#endif

It would be a bit less clunky if gcc builtins could be used in both cases. 
Personally, I use asm sufficiently rarely that it takes me a while to work out
the syntax each time (both the actual assembler syntax and the gcc asm
statement syntax).  The builtins are much easier to use.


Regards,  Phil.


-- 


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

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #50 from rguenth at gcc dot gnu dot org  2010-04-05 14:23 
---
(In reply to comment #49)
> At least the tree-vrp.c bit did not get applied (as of trunk r157950)
> 

Yup, my fault.  I looked at the wrong patch.  Thus, the first comment
applies - maybe stage1 with lots of cleanups.


-- 


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

[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check

[mckelvey at maskull dot com]

--- Comment #12 from mckelvey at maskull dot com  2010-04-05 14:36 ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > 
> > > cygcheck shows a reference to a sjlj dll, 
> > 
> >   Woah, deja vu!  
> > 
> > > although --disable-sjlj-exceptions is specified:
> > 
> >   So, you must still have the related .dll.a file in /usr/local/lib, so it
> > linked against that DLL even though it isn't present.  Get rid of your 
> > entire
> > old /usr/local prefix, or make sure it's not visible when you build.
> > 
> 
> I did that and it's now at stage3, so I believe it's going to be OK. I can't
> wait around for it to finish. I'll see if it works Monday morning.
> Thanks for all of your help.
> 

Looks OK this morning. I think we can close this one.


-- 


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

[Bug c++/41884] diagnostics: error vs. context

[bangerth at gmail dot com]

--- Comment #15 from bangerth at gmail dot com  2010-04-05 15:28 ---
FWIW, let me say that I believe that few people use -Wfatal-errors. Most of
the time, experienced programmers are able to fix multiple bugs in one
go-around
if they get to see all error messages, and the less experienced programmers
likely don't know about -Wfatal-errors.

This said, I quite frequently find it annoying that the actual error message
is so hard to find between the text printed above and below it. A defined
place either at the top or at the bottom would be highly useful in my mind.

W.


-- 


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

[Bug c/43642] FAIL: c-c++-common/raw-string-1.c

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-04-05 15:40 ---
Minimal testcase seems to be:
const char s4[] = R"(??()";
On powerpc64-linux native, compiled with -trigraphs -std=gnu99 -S this yields
the correct:
s4:
.string "??("
but compiled with -std=gnu99 -trigraphs -S it yields:
s4:
.string "??"
.string ""
Couldn't reproduce with a cross compiler though.


-- 


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

[Bug c/43642] FAIL: c-c++-common/raw-string-1.c

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-04-05 15:44 ---
And it shows on the same testcase even with just preprocessing:
gcc -E -std=gnu99 -trigraphs r.c | tail -n 1 | hexdump
000 636f 6e73 7420 6368 6172 2073 345b 5d20
010 3d20 5222 283f 3f00 2922 3b0a  
01c
gcc -E -trigraphs -std=gnu99 r.c | tail -n 1 | hexdump
000 636f 6e73 7420 6368 6172 2073 345b 5d20
010 3d20 5222 283f 3f28 2922 3b0a  
01c

Note 0x00 vs. 0x28 (the latter is correct).


-- 


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

[Bug c++/43647] "confused by earlier errors, bailing out" for member template explicit specialization

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2010-04-05 15:52 ---
Fixed by the fix for PR38089.


-- 


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

[Bug c++/43649] New: Nested Class inherits indirectly or Compiler interprets command wrongly

[in10semotions at googlemail dot com]

Nested Class inherits indirectly or Compiler interprets command wrongly


-- 
   Summary: Nested Class inherits indirectly or Compiler interprets
command wrongly
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: in10semotions at googlemail dot com


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

[Bug preprocessor/43642] FAIL: c-c++-common/raw-string-1.c

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|c   |preprocessor
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 15:55:46
   date||


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

[Bug preprocessor/43642] FAIL: c-c++-common/raw-string-1.c

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-04-05 15:57 ---
Created an attachment (id=20311)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20311&action=view)
gcc45-pr43642.patch

Untested fix.


-- 


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

[Bug c++/43649] Nested Class inherits indirectly or Compiler interprets command wrongly

[in10semotions at googlemail dot com]

--- Comment #1 from in10semotions at googlemail dot com  2010-04-05 15:59 
---
Created an attachment (id=20312)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20312&action=view)
Testcase


-- 


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

[Bug preprocessor/43642] FAIL: c-c++-common/raw-string-1.c

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-04-05 16:00 ---
Note that a few lines before that is if (_cpp_trigraph_map[note->type])
and _cpp_trigraph_map is [UCHAR_MAX + 1] sized array, so note->type surely must
be an unsigned char and nothing else (well, it will be only one of the 9
special char values), despite the type of note->type being actually unsigned
int.


-- 


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

[Bug preprocessor/43642] FAIL: c-c++-common/raw-string-1.c

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2010-04-05 16:14 ---
The patch is OK if it passes testing.  Though you might use "uchar" rather than
"unsigned char".


-- 


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

[Bug c++/43648] [4.5 regression] ICE with explicit destructor call and typedef

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-04-05 12:42:10 |2010-04-05 16:16:47
   date||


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

Re: [Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[Sebastian Pop]

On Mon, Apr 5, 2010 at 04:47, rguenth at gcc dot gnu dot org
 wrote:
> You shouldn't be using type_for_size but instead use
> build_nonstandard_integer_type.

I copied this from another LNO pass, should I also update that pass?
What about this patch?

Sebastian
From 504de7abe45a6b5f663c22e1fef54964c19d7528 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Mon, 5 Apr 2010 12:16:22 -0500
Subject: [PATCH] Use build_nonstandard_integer_type.

---
 gcc/graphite-clast-to-gimple.c |4 ++--
 gcc/tree-ssa-loop-ivopts.c |2 +-
 gcc/tree-ssa-loop-manip.c  |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 66089ae..3866eec 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -233,7 +233,7 @@ max_signed_precision_type (tree type1, tree type2)
   int p1 = TYPE_PRECISION (type1);
   int p2 = TYPE_PRECISION (type2);
   int precision = p1 > p2 ? p1 : p2;
-  tree type = lang_hooks.types.type_for_size (precision, false);
+  tree type = build_nonstandard_integer_type (precision, false);
 
   if (!type)
 {
@@ -485,7 +485,7 @@ gcc_type_for_interval (Value low, Value up, tree old_type)
   prec_int = precision_for_interval (low, up);
   precision = prec_up > prec_int ? prec_up : prec_int;
 
-  type = lang_hooks.types.type_for_size (precision, unsigned_p);
+  type = build_nonstandard_integer_type (precision, unsigned_p);
   if (!type)
 {
   gloog_error = true;
diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index e6565db..486243f 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -2291,7 +2291,7 @@ static void
 add_standard_iv_candidates_for_size (struct ivopts_data *data,
  unsigned int size)
 {
-  tree type = lang_hooks.types.type_for_size (size, true);
+  tree type = build_nonstandard_integer_type (size, true);
   add_candidate (data, build_int_cst (type, 0), build_int_cst (type, 1),
 		 true, NULL);
 }
diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index 7818f5b..c09a2ed 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -1207,7 +1207,7 @@ canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
 	precision = TYPE_PRECISION (TREE_TYPE (res));
 }
 
-  type = lang_hooks.types.type_for_size (precision, 1);
+  type = build_nonstandard_integer_type (precision, 1);
 
   if (original_precision != precision)
 {
-- 
1.6.3.3

[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[sebpop at gmail dot com]

--- Comment #3 from sebpop at gmail dot com  2010-04-05 17:30 ---
Subject: Re:  [graphite] Bootstrap with Graphite enabled 
fails in Java libs

On Mon, Apr 5, 2010 at 04:47, rguenth at gcc dot gnu dot org
 wrote:
> You shouldn't be using type_for_size but instead use
> build_nonstandard_integer_type.

I copied this from another LNO pass, should I also update that pass?
What about this patch?

Sebastian


--- Comment #4 from sebpop at gmail dot com  2010-04-05 17:30 ---
Created an attachment (id=20313)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20313&action=view)


-- 


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

[Bug debug/42648] [4.5 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n > 0

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2010-04-05 18:02 ---
(In reply to comment #3)
> Yeah, fixed (i686-linux-gnu) by revision 156693, from Feb 11.  I couldn't
> duplicate it at all on x86_64-linux-gnu.  If the problem is still present on
> some other platform, please reopen and specify.

Still fails on alpha, see [1]. One exaple fails with:

Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe
^[[?1034hReading symbols from
/space/uros/gcc-build/gcc/testsuite/gcc/pr41353-1.exe...done.^M
Breakpoint 1 at 0x12690: file
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 39.^M
^M
Breakpoint 1, f3 (i=)^M
at /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c:40^M
40  }^M
$1 = ^M
$2 = 12^M
A debugging session is active.^M
^M
Inferior 1 [process 14733] will be killed.^M
^M
Quit anyway? (y or n) [answered Y; input not from terminal]^M
 != 12
FAIL: gcc.dg/guality/pr41353-1.c  -O1  line 39 i == 12


[1] http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00388.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug tree-optimization/43650] New: "-fcompare-debug failure" with "-O2 -fpeel-loops -fgraphite-identity"

[zsojka at seznam dot cz]

Command line:
gcc -O2 -fpeel-loops -fgraphite-identity -fcompare-debug testcase.c

Tested revisions:
r157965 - fail
r157877 - OK


-- 
   Summary: "-fcompare-debug failure" with "-O2 -fpeel-loops -
fgraphite-identity"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/43650] "-fcompare-debug failure" with "-O2 -fpeel-loops -fgraphite-identity"

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 18:17 ---
Created an attachment (id=20314)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20314&action=view)
reduced testcase

Command line:
gcc -O2 -fpeel-loops -fgraphite-identity -fcompare-debug pr43650.c


-- 


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

[Bug c/43651] New: add warning for duplicate qualifier

[manu at gcc dot gnu dot org]

The C front end does not warn for a duplicate qualifier:

static const char const * stdin_name = "";
static const char * const stdout_name = "";

while ICC does:

main-hv.c(54): warning #83: type qualifier specified more than once
  static const char const * stdin_name = "";
^ 

G++ gives an error in this case but the column number is wrong:

test.c:1:1: error: duplicate ‘const’


-- 
   Summary: add warning for duplicate qualifier
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org


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

[Bug c++/43652] New: wrong column number for duplicate qualifier

[manu at gcc dot gnu dot org]

static const char const * stdin_name = "";

g++ -c test.cc

test.cc:1:1: error: duplicate 'const'


-- 
   Summary: wrong column number for duplicate qualifier
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org


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

[Bug c++/43652] wrong column number for duplicate qualifier

[manu at gcc dot gnu dot org]

-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-05 19:22:37
   date||


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

[Bug rtl-optimization/43653] New: ICE: in reload, at reload1.c:1188 with -O2 -ftree-vectorize and empty struct

[zsojka at seznam dot cz]

Command line:
gcc -O2 -ftree-vectorize testcase.c

Tested versions:
r157965 - crash
alpha20100401 - crash (disabled checking)
4.4.3, 4.3.4 - crash (gentoo, disabled checking)
4.2.4, 4.1.2 - OK (gentoo, disabled checking)

Compiler output - with checking:
$ gcc -O2 -ftree-vectorize testcase.c
testcase.c: In function 'foo':
testcase.c:10:1: internal compiler error: in reload, at reload1.c:1188

Without checking:
$ gcc-4.5.0-alpha20100401 -O2 -ftree-vectorize testcase.c
testcase.c: In function 'foo':
testcase.c:10:1: error: unrecognizable insn:
(insn 38 37 8 2 testcase.c:4 (set (reg:DI 22 xmm1)
(plus:DI (reg:DI 22 xmm1)
(mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [4 S8 A64])))
-1 (expr_list:REG_EQUIV (plus:DI (reg/f:DI 7 sp)
(mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [4 S8 A64]))
(nil)))
testcase.c:10:1: internal compiler error: in extract_insn, at recog.c:2103


-- 
   Summary: ICE: in reload, at reload1.c:1188 with -O2 -ftree-
vectorize and empty struct
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug rtl-optimization/43653] ICE: in reload, at reload1.c:1188 with -O2 -ftree-vectorize and empty struct

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 20:11 ---
Created an attachment (id=20315)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20315&action=view)
reduced testcase

-O1 is enough for this testcase:

$ gcc -O1 -ftree-vectorize pr43653.c
pr43653.c: In function 'foo':
pr43653.c:10:1: internal compiler error: in reload, at reload1.c:1188


-- 


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

[Bug middle-end/43654] New: Very long compile time with -O2 -floop-block

[zsojka at seznam dot cz]

Tested revisions:
r157965 - fail (~140s)
r153685 - crash
4.4 r157895 - OK (~0.2s)

Executed on a 1.6GHz CPU, CLooG-PPL 0.15.8, PPL 0.10.2:
$ /mnt/svn/gcc-trunk/binary-157965-lto/bin/gcc -O2 -floop-block testcase.c
-ftime-report -c

Execution times (seconds)
 Graphite loop transforms: 135.75 (100%) usr   0.88 (100%) sys 137.88 (100%)
wall  26 kB ( 1%) ggc
 Graphite data dep analysis:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 Graphite code generation:   0.05 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall 
59 kB ( 3%) ggc
 tree iv optimization  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 151 kB ( 8%) ggc
 tree STMT verifier:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 loop invariant motion :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   5 kB ( 0%) ggc
 branch prediction :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   2 kB ( 0%) ggc
 reload:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   4 kB ( 0%) ggc
 TOTAL : 135.87 0.88   137.99  
1961 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

Disabling checking doesn't help.


-- 
   Summary: Very long compile time with -O2 -floop-block
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug middle-end/43654] Very long compile time with -O2 -floop-block

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 20:49 ---
Created an attachment (id=20316)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20316&action=view)
reduced testcase

When the loop body is changed to:
x[i][j][k] = i + j + k;
compilation finishes in ~85s


-- 


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

[Bug tree-optimization/43655] New: [4.5 Regression] -ftree-ter causes FAIL: g++.old-deja/g++.law/temps5.C execution test

[zsojka at seznam dot cz]

Command line:
g++ -ftree-ter temps5.C && ./a.out

Tested revisions:
r157965 - fail
r153685 - fail
4.4 r157895 - OK
4.4.3, 4.3.4, 4.2.4, 4.1.2 - OK

Compiler output:
$ /mnt/svn/gcc-trunk/binary-157965-lto/bin/g++ -ftree-ter temps5.C && ./a.out
FAIL


-- 
   Summary: [4.5 Regression] -ftree-ter causes FAIL: g++.old-
deja/g++.law/temps5.C execution test
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/43655] [4.5 Regression] -ftree-ter causes FAIL: g++.old-deja/g++.law/temps5.C execution test

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 21:23 ---
Created an attachment (id=20317)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20317&action=view)
g++.old-deja/g++.law/temps5.C


-- 


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

[Bug middle-end/43656] New: "-fcompare-debug failure" with "-O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity"

[zsojka at seznam dot cz]

Command line:
gcc -O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity
-fcompare-debug testcase.c

Tested revisions:
r157965 - fail
r157877 - fail
r153685 - fail


-- 
   Summary: "-fcompare-debug failure" with "-O2 -fschedule-insns -
fsched-pressure -funroll-loops -fgraphite-identity"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug middle-end/43656] "-fcompare-debug failure" with "-O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity"

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 22:31 ---
Created an attachment (id=20318)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20318&action=view)
reduced testcase

Command line:
gcc -O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity
-fcompare-debug pr43656.c


-- 


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

[Bug tree-optimization/43657] New: [4.3/4.4/4.5 Regression] -ftree-loop-linear causes FAIL: gcc.dg/vect/vect-cond-5.c execution test

[zsojka at seznam dot cz]

Compiler output:
$ gcc -O1 -ftree-loop-linear vect-cond-5.c && ./a.out
Aborted

Tested revisions:
r157985 - fail
4.4.3, 4.3.4 - fail
4.2.4, 4.1.2 - OK


-- 
   Summary: [4.3/4.4/4.5 Regression] -ftree-loop-linear causes FAIL:
gcc.dg/vect/vect-cond-5.c execution test
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/43657] [4.3/4.4/4.5 Regression] -ftree-loop-linear causes FAIL: gcc.dg/vect/vect-cond-5.c execution test

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 23:02 ---
Created an attachment (id=20319)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20319&action=view)
slightly reduced testcase, showing computed data

$ gcc-4.5.0-alpha20100401 -O1 -ftree-loop-linear pr43657.c && ./a.out
0 6 2
1 5 2
2 4 2
3 3 2
4 2 2
5 0 0
6 0 0
7 0 0
8 0 0
9 0 0
10 0 0
11 0 0
12 0 0
13 0 0
14 0 0
15 0 0
16 0 0
17 0 0
18 0 0
19 0 0
20 0 0
21 0 0
22 0 0
23 0 0
24 0 0
25 0 0
26 0 0
27 0 0
28 0 0
29 0 0
30 0 0
31 0 0
Aborted

$ gcc-4.2.4 -O1 -ftree-loop-linear pr43657.c && ./a.out
0 2 2
1 2 2
2 2 2
3 2 2
4 2 2
5 0 0
6 0 0
7 0 0
8 0 0
9 0 0
10 0 0
11 0 0
12 0 0
13 0 0
14 0 0
15 0 0
16 0 0
17 0 0
18 0 0
19 0 0
20 0 0
21 0 0
22 0 0
23 0 0
24 0 0
25 0 0
26 0 0
27 0 0
28 0 0
29 0 0
30 0 0
31 0 0


-- 


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

[Bug lto/43658] New: ICE: SIGSEGV with -flto in aggregate_value_p (function.c:1859)

[zsojka at seznam dot cz]

Command line:
g++ -flto testcase.C

Tested revisions:
r157965 - crash
r157805 - crash


Valgrind output:
$ valgrind -q --trace-children=yes /mnt/svn/gcc-trunk/binary-157965-lto/bin/g++
-flto testcase.C
==6163== Conditional jump or move depends on uninitialised value(s)
==6163==at 0xDF5175: longest_match (deflate.c:1143)
==6163==by 0xDF573A: deflate_slow (deflate.c:1595)
==6163==by 0xDF66CC: deflate (deflate.c:790)
==6163==by 0xD71E3C: lto_end_compression (lto-compress.c:196)
==6163==by 0xD6EEE4: lto_end_section (lto-section-out.c:192)
==6163==by 0xD6F3DD: lto_destroy_simple_output_block
(lto-section-out.c:556)
==6163==by 0xD6DBC3: lto_output (lto-streamer-out.c:2125)
==6163==by 0x854370: ipa_write_summaries_2 (passes.c:1652)
==6163==by 0x85446E: ipa_write_summaries_1 (passes.c:1678)
==6163==by 0x856EFA: ipa_write_summaries (passes.c:1727)
==6163==by 0xAD4284: cgraph_optimize (cgraphunit.c:1793)
==6163==by 0xAD46E4: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==6163==

...

==6175== Invalid read of size 2
==6175==at 0x5F87AE: aggregate_value_p (function.c:1859)
==6175==by 0x5FD107: allocate_struct_function (function.c:4145)
==6175==by 0x4A58A6: materialize_cgraph (lto.c:114)
==6175==by 0x4A6460: lto_main (lto.c:2080)
==6175==by 0x75C3CC: toplev_main (toplev.c:1053)
==6175==by 0x6586A3C: (below main) (in /lib64/libc-2.10.1.so)
==6175==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6175==
In function 'foo':
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-157965-lto/bin/g++ returned 1 exit
status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: ICE: SIGSEGV with -flto in aggregate_value_p
(function.c:1859)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug lto/43658] ICE: SIGSEGV with -flto in aggregate_value_p (function.c:1859)

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-05 23:52 ---
Created an attachment (id=20320)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20320&action=view)
reduced testcase

Reduced from testsuite/g++.dg/lto/20091219_0.C


-- 


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

[Bug lto/43658] ICE: SIGSEGV with -flto in aggregate_value_p (function.c:1859)

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-04-06 00:06 ---
Created an attachment (id=20321)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20321&action=view)
less reduced testcase

Shows important parts of original code. Needs -fkeep-inline-functions
Command line:
g++ -flto -fkeep-inline-functions demo-unreduced.C


-- 


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

[Bug lto/43659] New: -flto doesn't remember -fPIC

[debian-gcc at lists dot debian dot org]

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

  Matthias

gcc-4.5 with -flto doesn't work with -fPIC properly.

Simple testcase:
int entry(int a)
{
return bar(a)+1;
}

int bar(int a)
{
return a+4;
}

$ gcc-4.5 foo1.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo2.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo1.o foo2.o -flto -shared
/usr/bin/ld: /tmp/ccmA7RCK.lto.o: relocation R_X86_64_PC32 against symbol `bar'
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

This works however:
$ gcc-4.5 foo1.o foo2.o -flto -shared -fPIC

Now -fPIC is something libtool automatically adds, and I it doesn't add it at
linktime (perhaps other build systems don't either).
Could gcc's -flto see that all .o files involved in the link are -fPIC... and
make the resulting file -fPIC too?
Or at least it should see the -shared in the linker line, and automatically use
-fPIC when -flto is used.


-- 
   Summary: -flto doesn't remember -fPIC
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug libstdc++/43660] New: range of random-number generator seems wrong/confusing

[debian-gcc at lists dot debian dot org]

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

  Matthias

The random-number distributions in C++0x  include a special
"one-shot" facility, where the random bounds can be passed to the
generator function.  This is explicitly intended (judging from committee
writings, and source comments in the libstdc++ header files) for use as
a rng generator for std::random_shuffle.

e.g.:
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1933.pdf

As best as I can tell, std::random_shuffle wants its random-number
generating functor to return results in the range [0,N), where N is the
parameter it passes to the functor; i.e., the upper-bound is exclusive
(and the lower-bound inclusive).

The  implementation in libstdc++ also notes this, e.g., in the
comment on the associated operator() method in the
std::uniform_int_distribution template class:

  /**
   * Gets a uniform random number in the range @f$[0, n)@f$.
   *
   * This function is aimed at use with std::random_shuffle.
   */
  template
result_type
operator()(_UniformRandomNumberGenerator& __urng,
   const param_type& __p);

However, in practice, it actually will return the upper-bound as well;
it seems to treat it as a maximum, rather than an exclusive bound.

For instance, compiling the attached test program (at end of message),
"rand-bug.cc", results in the following output:

   $ g++-4.5 -o rand-bug -std=c++0x rand-bug.cc
   $ ./rand-bug
   trying 100 random numbers in range [0,25)...
   returned upper-bound (25) 38394 times (should be 0)

[Note that the same issue exists with other ways of invoking using the
generator (e.g., a std::uniform_real_distribution with bounds of
0 and 1 will indeed return 1); but it's less clear its a bug in those
cases (although, for instance, boost's random implementation never
seems to return the upper bound).]

Thanks,

-Miles


Here's the test program:


#include 
#include 

int main ()
{
  std::mt19937 rng;

  typedef std::uniform_int_distribution dist_type;
  dist_type dist;

  unsigned num_loops = 100;
  unsigned upper_bound = 25;

  std::cout << "trying " << num_loops << " random numbers in range [0,"
<< upper_bound << ")..." << std::endl;

  //
  // According to the function documentation for this, it should never
  // return the upper bound:
  //
  // * Gets a uniform random number in the range @f$[0, n)@f$.
  // *
  // * This function is aimed at use with std::random_shuffle.
  //

  unsigned returned_upper_bound_count = 0;
  for (unsigned i = 0; i < num_loops; i++)
{
  unsigned num = dist (rng, dist_type::param_type (0, upper_bound));
  if (num == upper_bound)
returned_upper_bound_count++;
}

  std::cout << "returned upper-bound (" << upper_bound << ") "
<< returned_upper_bound_count << " times (should be 0)"
<< std::endl;

  return 0;
}


-- 
   Summary: range of random-number generator seems wrong/confusing
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

Re: [Bug lto/43659] New: -flto doesn't remember -fPIC

[Andrew Pinski]

This is done on purpose. The -fpic is needed on the link line too.  
This is a bug in libtool.


Sent from my iPhone

On Apr 5, 2010, at 6:47 PM, "debian-gcc at lists dot debian dot org" > wrote:



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

 Matthias

gcc-4.5 with -flto doesn't work with -fPIC properly.

Simple testcase:
int entry(int a)
{
   return bar(a)+1;
}

int bar(int a)
{
   return a+4;
}

$ gcc-4.5 foo1.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo2.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo1.o foo2.o -flto -shared
/usr/bin/ld: /tmp/ccmA7RCK.lto.o: relocation R_X86_64_PC32 against  
symbol `bar'

can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

This works however:
$ gcc-4.5 foo1.o foo2.o -flto -shared -fPIC

Now -fPIC is something libtool automatically adds, and I it doesn't  
add it at

linktime (perhaps other build systems don't either).
Could gcc's -flto see that all .o files involved in the link are - 
fPIC... and

make the resulting file -fPIC too?
Or at least it should see the -shared in the linker line, and  
automatically use

-fPIC when -flto is used.


--
  Summary: -flto doesn't remember -fPIC
  Product: gcc
  Version: 4.5.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: lto
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug lto/43659] -flto doesn't remember -fPIC

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2010-04-06 03:01 ---
Subject: Re:   New: -flto doesn't remember -fPIC

This is done on purpose. The -fpic is needed on the link line too.  
This is a bug in libtool.

Sent from my iPhone

On Apr 5, 2010, at 6:47 PM, "debian-gcc at lists dot debian dot org"
 wrote:

> [forwarded from http://bugs.debian.org/524176]
>
>  Matthias
>
> gcc-4.5 with -flto doesn't work with -fPIC properly.
>
> Simple testcase:
> int entry(int a)
> {
>return bar(a)+1;
> }
>
> int bar(int a)
> {
>return a+4;
> }
>
> $ gcc-4.5 foo1.c -flto -fPIC -DPIC -c
> $ gcc-4.5 foo2.c -flto -fPIC -DPIC -c
> $ gcc-4.5 foo1.o foo2.o -flto -shared
> /usr/bin/ld: /tmp/ccmA7RCK.lto.o: relocation R_X86_64_PC32 against  
> symbol `bar'
> can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
>
> This works however:
> $ gcc-4.5 foo1.o foo2.o -flto -shared -fPIC
>
> Now -fPIC is something libtool automatically adds, and I it doesn't  
> add it at
> linktime (perhaps other build systems don't either).
> Could gcc's -flto see that all .o files involved in the link are - 
> fPIC... and
> make the resulting file -fPIC too?
> Or at least it should see the -shared in the linker line, and  
> automatically use
> -fPIC when -flto is used.
>
>
> -- 
>   Summary: -flto doesn't remember -fPIC
>   Product: gcc
>   Version: 4.5.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: lto
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: debian-gcc at lists dot debian dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43659
>


-- 


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

[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2010-04-06 03:16 ---
Subject: Bug 43519

Author: spop
Date: Tue Apr  6 03:15:58 2010
New Revision: 157976

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157976
Log:
Use POINTER_PLUS_EXPR for pointer types.

2010-04-04  Sebastian Pop  

PR middle-end/43519
* graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Use
POINTER_PLUS_EXPR for pointer types.

* gcc.dg/graphite/id-19.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/id-19.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-clast-to-gimple.c


--- Comment #6 from spop at gcc dot gnu dot org  2010-04-06 03:16 ---
Subject: Bug 43519

Author: spop
Date: Tue Apr  6 03:16:04 2010
New Revision: 157977

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

2010-04-05  Sebastian Pop  

PR middle-end/43519
* graphite-clast-to-gimple.c (max_signed_precision_type): Use
build_nonstandard_integer_type.
(gcc_type_for_interval): Same.

Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-clast-to-gimple.c


-- 


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

[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2010-04-06 03:16 ---
Subject: Bug 43519

Author: spop
Date: Tue Apr  6 03:15:58 2010
New Revision: 157976

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157976
Log:
Use POINTER_PLUS_EXPR for pointer types.

2010-04-04  Sebastian Pop  

PR middle-end/43519
* graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Use
POINTER_PLUS_EXPR for pointer types.

* gcc.dg/graphite/id-19.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/id-19.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-clast-to-gimple.c


--- Comment #6 from spop at gcc dot gnu dot org  2010-04-06 03:16 ---
Subject: Bug 43519

Author: spop
Date: Tue Apr  6 03:16:04 2010
New Revision: 157977

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

2010-04-05  Sebastian Pop  

PR middle-end/43519
* graphite-clast-to-gimple.c (max_signed_precision_type): Use
build_nonstandard_integer_type.
(gcc_type_for_interval): Same.

Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-clast-to-gimple.c


-- 


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

[Bug c/43661] New: ice in fold_comparison, at fold-const.c:9579

[regehr at cs dot utah dot edu]

reg...@john-home:~/volatile/bugs/tmp310$ current-gcc -Os small.c -c
small.c: In function ‘func’:
small.c:10:6: internal compiler error: in fold_comparison, at fold-const.c:9579
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

reg...@john-home:~/volatile/bugs/tmp310$ cat small.c

void
func (int *p_51)
{
  int l_174 = 0;
  l_174 |=
0 ? (unsigned short) (0 ? : 1 *
  (signed char) (*p_51
 ^
 *p_51)
  >= 0) : *p_51 < *p_51 > *p_51 < 1;
}

reg...@john-home:~/volatile/bugs/tmp310$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r157975-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r157975-install
--program-prefix=r157975- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100406 (experimental) (GCC)


-- 
   Summary: ice in fold_comparison, at fold-const.c:9579
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 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=43661

Re: [Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[Sebastian Pop]

On Mon, Apr 5, 2010 at 22:16, spop at gcc dot gnu dot org
 wrote:
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157977
> Log:
> Use build_nonstandard_integer_type.

This commit seems to create problems both in chrec_convert and in the
niter estimations: these use unsigned_type_for and signed_type_for
that fail by returning NULL_TREE when the type is one that is returned
by build_nonstandard_integer_type.

[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[sebpop at gmail dot com]

--- Comment #7 from sebpop at gmail dot com  2010-04-06 05:54 ---
Subject: Re:  [graphite] Bootstrap with Graphite enabled 
fails in Java libs

On Mon, Apr 5, 2010 at 22:16, spop at gcc dot gnu dot org
 wrote:
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157977
> Log:
> Use build_nonstandard_integer_type.

This commit seems to create problems both in chrec_convert and in the
niter estimations: these use unsigned_type_for and signed_type_for
that fail by returning NULL_TREE when the type is one that is returned
by build_nonstandard_integer_type.


-- 


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

[Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2010-04-06 06:14 ---
Subject: Bug 43519

Author: spop
Date: Tue Apr  6 06:14:26 2010
New Revision: 157978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157978
Log:
Fix 473.astar miscompile.

2010-04-05  Sebastian Pop  

PR middle-end/43519
* graphite-clast-to-gimple.c (max_signed_precision_type): Use
lang_hooks.types.type_for_size instead of
build_nonstandard_integer_type.
When converting an unsigned type to signed, double its precision.
(gcc_type_for_interval): Use lang_hooks.types.type_for_size.
(gcc_type_for_iv_of_clast_loop): Call max_signed_precision_type.
(graphite_create_new_loop_guard): When ub + 1 wraps around, use lb <=
ub.

Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-clast-to-gimple.c


-- 


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