[Bug c++/42697] ice-on-legal-code: template class template function local objects

[bisqwit at iki dot fi]

--- Comment #11 from bisqwit at iki dot fi  2010-01-18 07:59 ---
Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new
regressions?


-- 


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

[Bug libstdc++/42788] New: Segafult in gcc/unwind-dw2.c

[sushants at yahoo-inc dot com]

We fork a pthread for some Xalan transformation and then wait for a given time
out period. The thread is started with the default cancellation policy that is
"deferred cancellation". If the thread does not finish we call pthread_cancel
on the thread.  Here is the partial stack trace when it crashes.

#0  0x002a95e9f25d in raise () from /lib64/tls/libc.so.6
#1  0x002a95ea0a5e in abort () from /lib64/tls/libc.so.6
#2  0x0238072d in _Unwind_SetGR (context=0x47d6, index=18443, val=6)
at
/usr/releng/tools/gcc/build-4.1.1_libstdcxx_debug/gcc-4.1.1/gcc/unwind-dw2.c:179
#3  0x0237a543 in __gxx_personality_v0 (version=, 
actions=, exception_class=, 
ue_header=0x4dc15d80, context=0x4dc12c40)
at
/usr/releng/tools/gcc/build-4.1.1_libstdcxx_debug/gcc-4.1.1/libstdc++-v3/libsupc++/eh_personality.cc:672
#4  0x002ab20249e5 in ?? () from /lib64/libgcc_s.so.1
#5  0x002ab2024afc in _Unwind_ForcedUnwind () from /lib64/libgcc_s.so.1
#6  0x002a95adcdd0 in __pthread_unwind () from /lib64/tls/libpthread.so.0
#7  0x002a95f6b918 in __pthread_unwind () from /lib64/tls/libc.so.6
#8  0x002a95f43ddb in __libc_enable_asynccancel ()
   from /lib64/tls/libc.so.6
#9  0x002a95f2ac43 in open () from /lib64/tls/libc.so.6
#10 0x002a95ed5188 in _IO_new_file_fopen () from /lib64/tls/libc.so.6
#11 0x002a95ecbf34 in __fopen_internal () from /lib64/tls/libc.so.6
#12 0x020c025b in xercesc_2_7::XMLPlatformUtils::openFile ()

I tried to debug this a bit and see why this is happening. This is crashing in 
the following function:

/* Overwrite the saved value for register REG in CONTEXT with VAL.  */

inline void
_Unwind_SetGR (struct _Unwind_Context *context, int index, _Unwind_Word val)
{
  int size;
  void *ptr;

  index = DWARF_REG_TO_UNWIND_COLUMN (index);
  gcc_assert (index < (int) sizeof(dwarf_reg_size_table));
  size = dwarf_reg_size_table[index];
  ptr = context->reg[index];

  if (size == sizeof(_Unwind_Ptr))
* (_Unwind_Ptr *) ptr = val;
  else
{
  gcc_assert (size == sizeof(_Unwind_Word));
  * (_Unwind_Word *) ptr = val;
}
}

While running under gdb I found that all entries in dwarf_reg_size_table is 0
and so size becomes 0. When it is compared with  sizeof(_Unwind_Word) i.e., it
causes gcc asserts.

Looking in unwind-dw2.c it seems the table should be initialized before any
calls to the function and my feeling is that the initialization is not
happening.


It is a deterministic bug and I can reproduce it easily. I do not know much
about gcc and so I do not know what all pertinent information is needed. So let
me know what all information you need. 


System: Linux 2.6.9-67.0.15.ELsmp #1 SMP Tue Apr 22 13:58:43 EDT 2008 x86_64
x86_64 x86_64 GNU/Linux


-- 
   Summary: Segafult in gcc/unwind-dw2.c
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sushants at yahoo-inc dot com


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

[Bug c/42787] Failed to "make all-target"

[monaka at monami-software dot com]

--- Comment #1 from monaka at monami-software dot com  2010-01-18 06:27 
---
The origin of this issue is gengtype doesn't create gt-m32r.h.


-- 


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

[Bug c/42787] New: Failed to "make all-target"

[monaka at monami-software dot com]

In case "make all-target" after "make all-gcc", the build is failed.

/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/./gcc/xgcc
-B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/./gcc/
-nostdinc
-B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/m32r-elf/newlib/
-isystem
/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/m32r-elf/newlib/targ-include
-isystem /Users/monaka/git/sourceforge.jp/pf3gnuchains4x/newlib/libc/include
-B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/m32r-elf/libgloss/m32r
-L/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/m32r-elf/libgloss/libnosys
-L/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/libgloss/m32r
-B/pizza/m32r-elf/bin/ -B/pizza/m32r-elf/lib/ -isystem /pizza/m32r-elf/include
-isystem /pizza/m32r-elf/sys-include
-L/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m32r-elf/build/i386/./ld
   -c  -g -Os  -mmodel=medium -msdata=sdata -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../../../gcc -I../../../../../gcc/. -I../../../../../gcc/../include
-I./../intl -I../../../../../gcc/../libcpp/include -I/opt/gcc4build/include
-I/opt/gcc4build/include  -I../../../../../gcc/../libdecnumber
-I../../../../../gcc/../libdecnumber/dpd -I../libdecnumber \
../../../../../gcc/config/m32r/m32r.c -o m32r.o
In file included from ../../../../../gcc/config/m32r/m32r.c:22:0:
../../../../../gcc/system.h:199:22: fatal error: strings.h: No such file or
directory
compilation terminated.


-- 
   Summary: Failed to "make all-target"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: monaka at monami-software dot com
 GCC build triplet: i386-apple-darwin10.2.0
  GCC host triplet: i386-apple-darwin10.2.0
GCC target triplet: m32r-elf


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

[Bug bootstrap/42786] Athlon SSE3 and Fx processors not supported by configure

[felyza at gmail dot com]

--- Comment #2 from felyza at gmail dot com  2010-01-18 05:54 ---
Can't edit original post. Email client added line breaks where they shouldn't
be. Please use patch attached to issue, and not one orginally submitted in
description.


-- 


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

[Bug bootstrap/42786] Athlon SSE3 and Fx processors not supported by configure

[felyza at gmail dot com]

--- Comment #1 from felyza at gmail dot com  2010-01-18 05:52 ---
Created an attachment (id=19644)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19644&action=view)
Didn't have option on submission, its now attached.


-- 


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

[Bug bootstrap/42786] New: Athlon SSE3 and Fx processors not supported by configure

[felyza at gmail dot com]

The athlon64-sse3, opteron-sse3, k8-sse3, and athlon-fx processors are
supported in the code itself, however support for the sse3 series was missing,
and the fx series was partially implemented in the configure scripts. 

This patch will add support for the sse3 series as well as correct the fx
entry. 

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 156000)
+++ gcc/config.gcc  (working copy)
@@ -1144,7 +1144,7 @@
tmake_file="${tmake_file} i386/t-linux64"
need_64bit_hwint=yes
case X"${with_cpu}" in
-  
Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
+  
Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx|Xathlon64-sse3|Xk8-sse3|Xopteron-sse3)
;;
X)
if test x$with_cpu_64 = x; then
@@ -1153,7 +1153,7 @@
;;
*)
echo "Unsupported CPU used in
--with-cpu=$with_cpu, supported values:" 1>&2
-   echo "generic atom core2 nocona x86-64 amdfam10
barcelona k8 opteron athlon64 athlon-fx" 1>&2
+   echo "generic atom core2 nocona x86-64 amdfam10
barcelona k8 opteron athlon64 athlon-fx athlon64-sse3 k8-sse3 opteron-sse3"
1>&2
exit 1
;;
esac
@@ -1260,7 +1260,7 @@
need_64bit_hwint=yes
use_gcc_stdint=wrap
case X"${with_cpu}" in
-  
Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
+  
Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx|Xathlon64-sse3|Xk8-sse3|Xopteron-sse3)
;;
X)
if test x$with_cpu_64 = x; then
@@ -1269,7 +1269,7 @@
;;
*)
echo "Unsupported CPU used in --with-cpu=$with_cpu,
supported values:" 1>&2
-   echo "generic atom core2 nocona x86-64 amdfam10
barcelona k8 opteron athlon64 athlon-fx" 1>&2
+   echo "generic atom core2 nocona x86-64 amdfam10
barcelona k8 opteron athlon64 athlon-fx athlon64-sse3 k8-sse3 opteron-sse3"
1>&2
exit 1
;;
esac
@@ -1339,7 +1339,7 @@
if test x$enable_targets = xall; then
tm_defines="${tm_defines} TARGET_BI_ARCH=1"
case X"${with_cpu}" in
-  
Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
+  
Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx|Xathlon64-sse3|Xk8-sse3|Xopteron-sse3)
;;
X)
if test x$with_cpu_64 = x; then
@@ -1348,7 +1348,7 @@
;;
*)
echo "Unsupported CPU used in
--with-cpu=$with_cpu, supported values:" 1>&2
-   echo "generic atom core2 nocona x86-64
amdfam10 barcelona k8 opteron athlon64 athlon-fx" 1>&2
+   echo "generic atom core2 nocona x86-64
amdfam10 barcelona k8 opteron athlon64 athlon-fx athlon64-sse3 k8-sse3
opteron-sse3" 1>&2
exit 1
;;
esac
@@ -2629,8 +2629,11 @@
   case ${target_noncanonical} in
 amdfam10-*|barcelona-*)
   with_cpu=amdfam10
+  ;; 
+k8_sse3-*|opteron_sse3-*|athlon64_sse3-*)
+  with_cpu=k8-sse3
   ;;
-k8-*|opteron-*|athlon_64-*)
+k8-*|opteron-*|athlon64-*|athlon_fx-*)
   with_cpu=k8
   ;;
 athlon_xp-*|athlon_mp-*|athlon_4-*)
@@ -2676,7 +2679,10 @@
 amdfam10-*|barcelona-*)
   with_cpu=amdfam10
   ;;
-k8-*|opteron-*|athlon_64-*)
+k8_sse3-*|opteron_sse3-*|athlon64_sse3-*)
+  with_cpu=k8-sse3
+  ;;
+k8-*|opteron-*|athlon64-*|athlon_fx-*)
   with_cpu=k8
   ;;
 nocona-*)
@@ -2970,7 +2976,7 @@
esac
# OK
;;
-   "" | amdfam10 | barcelona | k8 | opteron | athlon64 |
athlon-fx | nocona | core2 | atom | generic)
+   "" | amdfam10 | barcelona | k8-sse3 | o

[Bug fortran/42680] [fortran-dev, Regression] ICE in gimplify_expr, at gimplify.c:7176

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2010-01-18 03:06 
---
Subject: Bug 42680

Author: jvdelisle
Date: Mon Jan 18 03:06:10 2010
New Revision: 156000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156000
Log:
2010-01-17  Jerry DeLisle  

PR fortran/42680
* gfortran.dg/interface_32.f90: New test.

Added:
branches/fortran-dev/gcc/testsuite/gfortran.dg/interface_32.f90
Modified:
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


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

[Bug c++/42738] [C++0x] nested lambda function: Segmentation fault

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-01-18 02:37 
---
I'm resolving this as duplicate of the first nested lambdas PR which came in, I
don't think there is anything more here.

Jason, if you disagree, please take care of re-opening, thanks.

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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/41896] [cxx0x-lambda] Segfault because of a nested lambda function

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-01-18 02:37 
---
*** Bug 42738 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||vimal78 at gmail dot com


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

[Bug fortran/42680] [fortran-dev, Regression] ICE in gimplify_expr, at gimplify.c:7176

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-01-18 02:21 
---
Subject: Bug 42680

Author: jvdelisle
Date: Mon Jan 18 02:21:20 2010
New Revision: 155998

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155998
Log:
2010-01-17  Jerry DeLisle  

PR fortran/42680
* interface.c (check_interface1): Pass symbol name rather than NULL to
gfc_compare_interfaces.(gfc_compare_interfaces): Add assert to
trap MULL. (gfc_compare_derived_types): Revert previous change
incorporated incorrectly during merge from trunk, r155778.
* resolve.c (check_generic_tbp_ambiguity): Pass symbol name rather
than NULL to gfc_compare_interfaces.
* symbol.c (add_generic_specifics): Likewise.

Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
branches/fortran-dev/gcc/fortran/interface.c
branches/fortran-dev/gcc/fortran/resolve.c
branches/fortran-dev/gcc/fortran/symbol.c


-- 


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

[Bug bootstrap/42785] error: impossible constraint in �easm�f

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-18 00:56 ---
If you use -arch ppc, then the host/build is really powerpc-apple-darwin so
obviously you are configuring GCC incorrectly and the error message is correct
as that is x86 inline-asm that is being compiled in that source. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|error: impossible constraint|error: impossible constraint
   |in easmf  |in �easm�f


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

[Bug bootstrap/42785] New: error: impossible constraint in �easm�f

[monaka at monami-software dot com]

I got "error: impossible constraint in easmf" on the build time.
It only happens building with "-arch ppc" option. There is no errors in case I
choice "-arch i386"/"-arch x86_64".

gcc -arch ppc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../../../../gcc -I../../../../../gcc/.
-I../../../../../gcc/../include -I./../intl
-I../../../../../gcc/../libcpp/include -I/opt/gcc4build/include
-I/opt/gcc4build/include  -I../../../../../gcc/../libdecnumber
-I../../../../../gcc/../libdecnumber/dpd -I../libdecnumber -I. -I.
-I../../../../../gcc -I../../../../../gcc/. -I../../../../../gcc/../include
-I./../intl -I../../../../../gcc/../libcpp/include -I/opt/gcc4build/include
-I/opt/gcc4build/include  -I../../../../../gcc/../libdecnumber
-I../../../../../gcc/../libdecnumber/dpd -I../libdecnumber   
../../../../../gcc/config/i386/driver-i386.c
../../../../../gcc/config/i386/driver-i386.c: In function edetect_l2_cachef:
../../../../../gcc/config/i386/driver-i386.c:68: error: impossible constraint
in easmf
make[1]: *** [driver-i386.o] Error 1
make: *** [all-gcc] Error 2


the result of host gcc -v is:
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)


-- 
   Summary: error: impossible constraint in easmf
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: monaka at monami-software dot com
 GCC build triplet: i386-apple-darwin10.2.0
  GCC host triplet: i386-apple-darwin10.2.0
GCC target triplet: i386-elf


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

[Bug fortran/42545] type extension: parent component has wrong accessibility

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2010-01-17 23:46 ---
In addition to the parent component accessibility issue, there is also
something wrong with the error message being thrown in comment #0 and #1.

The check throwing this error resides in 'gfc_find_component', and was moved
there in r138275 by pault. Previously it was in
'gfc_match_structure_constructor', where it was probably more appropriate.

The error message is also thrown wrongly in extends_6.f03, where (again) no
structure constructor is involved.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug fortran/42545] type extension: parent component has wrong accessibility

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-01-17 23:34 ---
Here is a simple patch for setting the parent component accessibility:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 155994)
+++ gcc/fortran/decl.c  (working copy)
@@ -6931,6 +6931,7 @@ gfc_match_derived_decl (void)
   p->ts.type = BT_DERIVED;
   p->ts.u.derived = extended;
   p->initializer = gfc_default_initializer (&p->ts);
+  p->attr.access = extended->attr.access;

   /* Set extension level.  */
   if (extended->attr.extension == 255)

This is probably not enough, since the access. specification of the parent type
may come after the daughter type definition. But this already fixes the exmple
in comment #2.


-- 


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

[Bug debug/42782] VTA missed location: parameter via stack

[jan dot kratochvil at redhat dot com]

--- Comment #1 from jan dot kratochvil at redhat dot com  2010-01-17 23:23 
---
Noticed it is a regression against: gcc (GCC) 4.4.3 20100117 (prerelease)


-- 


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

[Bug fortran/31519] spurious ICE messages when module does not compile

[kargl at gcc dot gnu dot org]

--- Comment #9 from kargl at gcc dot gnu dot org  2010-01-17 23:06 ---
Is this still a problem on ming32.  Can we just drop support
for ming32?


-- 


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

[Bug c++/25994] Using declarations and base function overloading

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-01-17 22:47 
---
*** Bug 42784 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||max at e-soft dot ru


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

[Bug c++/42784] using declaration conflicts with a different declaration in one class.

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-17 22:47 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/42545] type extension: parent component has wrong accessibility

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-01-17 22:42 ---
Another related example. This one is being accepted, although it is invalid.

module mo
  implicit none
  type,private :: tt
integer :: i = 1
  end type
  type, extends(tt) :: ttt
real :: x = 2.0
  end type
end module
program pr
  use mo
  implicit none
  type(ttt) :: obj
  print *,obj%tt%i
end program


The problem clearly is the accessibility of the parent component.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|TBP: Wrongly reject inherite|type extension: parent
   |TBP with types with private |component has wrong
   |components  |accessibility


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

[Bug c++/42784] New: using declaration conflicts with a different declaration in one class.

[max at e-soft dot ru]

g++ doesn't accept this code:

template struct K;

template struct K
{
void f();
};

template struct K : public K
{
using K::f;
typedef const char A[N*I];
void f(const A &) const;
};

template struct Q : public K, public K
{
using K::f;
using K::f; // error: using declaration ‘using K<4, 4>::f’ conflicts
with a previous using declaration
};

int main()
{
Q<5> v;
char a5x3[15];
v.f(a5x3);
char a4x2[8];
v.f(a4x2);
}


-- 
   Summary: using declaration conflicts with a different declaration
in one class.
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: max at e-soft dot ru
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/42697] ice-on-legal-code: template class template function local objects

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2010-01-17 22:41 
---
Not a regression means that as far as we know no previous release worked, it's
a long standing issue (as you can see gcc4.1.2 already failed). Thus, in
general, at this Stage in the release process toward gcc4.5.0 will not be
fixed.


-- 


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

[Bug c++/42697] ice-on-legal-code: template class template function local objects

[bisqwit at iki dot fi]

--- Comment #9 from bisqwit at iki dot fi  2010-01-17 22:37 ---
Out of curiosity... What does it mean it's not a regression, and what are its
practical implications?


-- 


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

[Bug fortran/42545] TBP: Wrongly reject inherite TBP with types with private components

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-01-17 22:35 ---
This problem is not specific to TBPs. It also appears for data components of
the parent type, as the following example shows:

module mo
  implicit none
  type :: tt
integer :: i = 1
  end type
  type, extends(tt) :: ttt
private ! <<<
real :: x = 2.0
  end type
end module
program pr
  use mo
  implicit none
  type(ttt) :: obj
  print *,obj%tt%i
end program


This is incorrectly rejected with:

  print *,obj%tt%i
1
Error: All components of 'ttt' are PRIVATE in structure constructor at (1)


-- 


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

[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized

[schwab at linux-m68k dot org]

-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

  Known to fail||4.3.4 4.4.3
   Target Milestone|--- |4.4.4


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[mikpe at it dot uu dot se]

--- Comment #9 from mikpe at it dot uu dot se  2010-01-17 22:32 ---
Uros' proposed fix for 4.4 and 4.3 fixes the ICE on both branches.

The original report stated that 4.3 doesn't ICE. A vanilla 4.3-20100103
definitely ICEs for me on the reduced test case.


-- 


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

[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized

[schwab at linux-m68k dot org]

--- Comment #13 from schwab at linux-m68k dot org  2010-01-17 22:27 ---
The bug exists since the dawn of time.  The problem is that cse thinks that
(zero_extract:SI (mem:QI ...) ...) is zero if (mem:QI ...) is known to be zero,
but the first argument of zero_extract is only a base address if it is a memory
address.  On m68k this is only generated when STRICT_ALIGNMENT, and the bug was
hidden until e2496245b8453f49bb4428f281af7686be09ddf8:

2000-07-17  Zack Weinberg  
(simplify_ternary_operation):  Do not examine MODE_BITSIZE of
   a CONST_INT, it will always be zero.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization
 Ever Confirmed|0   |1
 GCC target triplet|m68k-*-*|m68k-*-elf
   Last reconfirmed|-00-00 00:00:00 |2010-01-17 22:27:47
   date||
Summary|[m68k] Wrong code generated |(zero_extract:SI (mem:QI)
   |with -O2/-O3|...) misoptimized


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

[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2010-01-17 22:11 
---
(In reply to comment #7)
> Btw, if you know more about data types than nothing then do not use the
> __m128* types for data but build your vector types yourself with an
> appropriate base type like
> 
> typedef T m128T __attribute__((__vector_size__(16)));

It isn't a bad idea.

> It seems that the Intel intrinsics API at no point follows type-based
> aliasing rules (they even have vectors of characters, so restricting
> types based on possible data types is not going to work out).
> 

That is true.


-- 


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

[Bug fortran/42783] [4.5 Regression] Bogus Array bounds violation with optional array argument

[anlauf at gmx dot de]

--- Comment #1 from anlauf at gmx dot de  2010-01-17 21:58 ---
Created an attachment (id=19643)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19643&action=view)
Bug demo code (fails at runtime)


-- 


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

[Bug fortran/42769] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

--- Comment #15 from janus at gcc dot gnu dot org  2010-01-17 21:58 ---
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html

Just for completeness: With trunk r152525 you get the same ICE (with a
different line number) on comment #8/#14:

internal compiler error: in resolve_typebound_procedure, at
fortran/resolve.c:9668

So, r152526 is definitely not the culprit. And this is another hint that this
bug was probably always present in 4.5.


-- 


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

[Bug fortran/42783] New: [4.5 Regression] Bogus Array bounds violation with optional array argument

[anlauf at gmx dot de]

Hi,

when compiled with -fbounds-check, the attached code fails at runtime
with the following error:

At line 8 of file gfcbug99.f90
Fortran runtime error: Actual string length does not match the declared one for
dummy argument 'mnem_list' (0/8)

No problem with 4.4.0 or earlier.


-- 
   Summary: [4.5 Regression] Bogus Array bounds violation with
optional array argument
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anlauf at gmx dot de


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2010-01-17 21:50 ---
Created an attachment (id=19642)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19642&action=view)
Patch for 4.3 and 4.4 branch.


-- 


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

[Bug fortran/30676] Incomplete warning on non-conforming code with -fopenmp

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2010-01-17 21:48 ---
http://gcc.gnu.org/news.html

shows

June 6, 2008
An implementation of the OpenMP v3.0 parallel programming interface for C,
C++ and Fortran has been added. Code was contributed by Jakub Jelinek, Richard
Henderson and Ulrich Drepper of Red Hat, Inc.

A scan of the gcc.info files shows that the -fopenmp option cannot select
the older 2.5 spec, so only the 3.0 spec is now relevant.  Comment #3
states the code is valid under 3.0 and indeed it compiles with both 
4.4.3 and 4.5.0.

I'm closing this with WONTFIX and setting the target to 4.4.3.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.4.3


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

[Bug tree-optimization/42781] [4.5 Regression] ICE in pt_solutions_same_restrict_base, at tree-ssa-structalias.c:5072

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-01-17 21:22:30 |2010-01-17 21:37:56
   date||


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2010-01-17 21:36 ---
Uros' proposed patch fixes the ICE in gcc-4.5. It doesn't apply to 4.4 though.


-- 


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

[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks

[rguenther at suse dot de]

--- Comment #9 from rguenther at suse dot de  2010-01-17 21:35 ---
Subject: Re:  [C++0x] Variadic templates + lambdas =
 extremely poor code quality, __m128i and aliasing sucks

On Sun, 17 Jan 2010, piotr dot wyderski at gmail dot com wrote:

> --- Comment #8 from piotr dot wyderski at gmail dot com  2010-01-17 21:29 
> ---
> It would be great to use my own vector data
> types, as in simple cases it allows GCC to
> automaticly vectorize them in a portable way,
> but in more complex cases it would mean a lot
> of explicit type casts => even more unreadable
> code, which even now is hard to follow.

I don't think you have a choice.


-- 


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

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

--- Comment #14 from janus at gcc dot gnu dot org  2010-01-17 21:34 ---
(In reply to comment #10)
> mod1
> 1
> Error: Unclassifiable statement at (1)

Sorry, this is due to a wrapped comment in comment #8. Let's try it again:

module mod1
  type :: t1
  contains
procedure, nopass :: get => my_get
  end type
contains 
  logical function my_get()
  end function
end module

module mod2
contains 
  logical function my_get()
  end function
end module

module mod3
contains
  subroutine sub(a)
use mod2, only: my_get
use mod1, only: t1
type(t1) :: a
  end subroutine
end module


use mod2, only: my_get
use mod3, only: sub
end 


This fails with the same error message as comment #1 (with "use psb_error_mod"
removed). PLUS, it ICEs also with 4.4. So, no regression.


-- 


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

[Bug debug/42782] New: VTA missed location: parameter via stack

[jan dot kratochvil at redhat dot com]

gcc (GCC) 4.5.0 20100117 (experimental)
x86_64-unknown-linux-gnu running -m32
Reproduced on Fedora 12: gcc-4.4.2-20.fc12.x86_64

extern void g (void);

int
f (int a)
{
  g ();

  return a;
}

gcc -o 1.o -c -Wall 1.c -m32 -O1 -g -Wall

   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   83 ec 08sub$0x8,%esp
   6:   e8 fc ff ff ff  call   7 
   b:   8b 45 08mov0x8(%ebp),%eax
   e:   c9  leave  
   f:   c3  ret

Contents of the .debug_info section:
 <2><40>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<41>   DW_AT_name: a
<49>   DW_AT_location: 0x38 (location list)

Contents of the .debug_loc section:
Offset   BeginEnd  Expression
0038  000a (DW_OP_fbreg: 0)
0038 

Offsets 0xb .. 0xf miss the A location.
The function must know it when it returns A.

Practical impact:
Backtrace missed parameters of elf_lookup_lib_symbol() in:
https://bugzilla.redhat.com/show_bug.cgi?id=556310


-- 
   Summary: VTA missed location: parameter via stack
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: i386-unknown-linux-gnu


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

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2010-01-17 21:31 ---
(In reply to comment #10)
> I got
>
> pr42769-2.f90:14:
>
> mod1
> 1
> Error: Unclassifiable statement at (1)

The two lines

>   logical function my_get() ! must have the same name as the function in
> mod1

have to be merged in a single one: "...!...the function in mod1".


-- 


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

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

--- Comment #12 from janus at gcc dot gnu dot org  2010-01-17 21:29 ---
I'd argue this is not even a regression. Sure, the code in comment #1 fails to
compile with 4.4 since it contains lots of CLASS declarations. But on comment
#8, gfortran 4.4 fails with (almost) the same error:

internal compiler error: in resolve_typebound_procedure, at
fortran/resolve.c:8505

Salvatore, are you sure this worked with 4.5 at some point, or is this sudden
failure rather due to changes in your code?

Daniel, since you were the one who implemented most of the TBP stuff in 4.4,
could you maybe have a look at this? Seems like there is a problem with equal
names in different namespaces ...


-- 


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

[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks

[piotr dot wyderski at gmail dot com]

--- Comment #8 from piotr dot wyderski at gmail dot com  2010-01-17 21:29 
---
It would be great to use my own vector data
types, as in simple cases it allows GCC to
automaticly vectorize them in a portable way,
but in more complex cases it would mean a lot
of explicit type casts => even more unreadable
code, which even now is hard to follow.


-- 


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

[Bug tree-optimization/42781] [4.5 Regression] ICE in pt_solutions_same_restrict_base, at tree-ssa-structalias.c:5072

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-17 21:22 ---
Confirmed.  Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|fortran |tree-optimization
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-17 21:22:30
   date||
   Target Milestone|--- |4.5.0


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

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-01-17 21:21 
---
(In reply to comment #9)
> (In reply to comment #5)
> > It is very likely caused by revision :
> > http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
> 
> Actually I don't see how this bug could be caused by r152526. That patch was
> about SELECT TYPE and (ideally) should have no effect on TBPs at all. Also, at
> first sight, I don't see anything suspicious in the patch. Is there any
> evidence for the above claim?


With original testcase, removing all "use psb_error_mod", I got

[...@gnu-34 rrs]$ /export/gnu/import/rrs/152525/usr/bin/gcc  -S pr42769.f90
pr42769.f90:1309.36:

class is (psb_s_base_sparse_mat)
1
Error: CLASS IS specification at (1) is not yet supported
pr42769.f90:1310.22:

  call b%cp_to_coo(tmp,info)
  1
Error: 'cp_to_coo' at (1) is not a member of the 'psb_base_sparse_mat'
structure
pr42769.f90:2919.36:

class is (psb_d_base_sparse_mat)
1
Error: CLASS IS specification at (1) is not yet supported
pr42769.f90:2920.22:

  call b%cp_to_coo(tmp,info)
  1
Error: 'cp_to_coo' at (1) is not a member of the 'psb_base_sparse_mat'
structure
pr42769.f90:3894.24:

  use psb_d_base_mat_mod
1
Fatal Error: Can't open module file 'psb_d_base_mat_mod.mod' for reading at
(1): No such file or directory
[...@gnu-34 rrs]$ /export/gnu/import/rrs/152525/usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/export/gnu/import/rrs/152525/usr/bin/gcc
COLLECT_LTO_WRAPPER=/export/gnu/import/rrs/152525/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --prefix=/export/gnu/import/rrs/152525/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking
--enable-languages=c,c++,fortran --with-ppl=/ --with-cloog=/
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091007 (experimental) [trunk revision 152525] (GCC)
[...@gnu-34 rrs]$ /export/gnu/import/rrs/152526/usr/bin/gcc  -S pr42769.f90
pr42769.f90:1309.36:

class is (psb_s_base_sparse_mat)
1
Error: CLASS IS specification at (1) is not yet supported
pr42769.f90:180:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-34 rrs]$ /export/gnu/import/rrs/152526/usr/bin/gcc  -v
Using built-in specs.
COLLECT_GCC=/export/gnu/import/rrs/152526/usr/bin/gcc
COLLECT_LTO_WRAPPER=/export/gnu/import/rrs/152526/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --prefix=/export/gnu/import/rrs/152526/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking
--enable-languages=c,c++,fortran --with-ppl=/ --with-cloog=/
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091007 (experimental) [trunk revision 152526] (GCC)
[...@gnu-34 rrs]$


-- 


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

[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-17 21:19 ---
Btw, if you know more about data types than nothing then do not use the
__m128* types for data but build your vector types yourself with an
appropriate base type like

typedef T m128T __attribute__((__vector_size__(16)));

It seems that the Intel intrinsics API at no point follows type-based
aliasing rules (they even have vectors of characters, so restricting
types based on possible data types is not going to work out).


-- 


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

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2010-01-17 21:18 
---
(In reply to comment #8)
> Here is a reduced test case:
> 
> module mod1
>   type :: t1
>   contains
> procedure, nopass :: get => my_get
>   end type
> contains 
>   logical function my_get()
>   end function
> end module
> 
> module mod2
> contains 
>   logical function my_get() ! must have the same name as the function in
> mod1
>   end function
> end module
> 
> module mod3
> contains
>   subroutine sub(a)
> use mod2, only: my_get
> use mod1, only: t1  ! order of use statements is important
> type(t1) :: a   ! 'a' must be dummy
>   end subroutine
> end module
> 
> 
> use mod2, only: my_get
> use mod3, only: sub ! order of use statements is important
> end 
> 

I got

pr42769-2.f90:14:

mod1
1
Error: Unclassifiable statement at (1)
pr42769-2.f90:21.26:

use mod2, only: my_get
  1
Fatal Error: Can't open module file 'mod2.mod' for reading at (1): No such file
or directory


-- 


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

[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-17 21:08 ---
If you fix that issue (simply remove all __may_alias__ attributes from
preprocessed source) you get

.L62:
addl$1, %edx
movdqa  (%ebx,%eax), %xmm0
pand(%esi,%eax), %xmm0
movdqa  %xmm0, (%edi,%eax)
addl$16, %eax
cmpl%edx, %ecx
jne .L62

for the innermost loop.  Maybe not 100% perfect but reasonable (that's -O2).


-- 


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

[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-17 21:05 ---
Well, indeed - it would be far more useful to have a less convoluted testcase
where unrelated functions and source make analysis hard.

Please provide a testcase with a _single_ computation kernel applying it in
a single way (I'm trying to follow op_and ...).

>From an inlining perspective it doesn't look so bad - early inlining turns 
the innermost loop into

:
  D.15257_17 = thisD.13894_4(D)->m_DataD.13729;
  D.15256_19 = iD.15246_18 * 16;
  D.15255_20 = D.15257_17 + D.15256_19;
  D.15254_21 = v2D.13892_5(D)->m_DataD.13729;
  D.15256_22 = iD.15246_18 * 16;
  D.15253_23 = D.15254_21 + D.15256_22;
  D.15252_24 = *D.15253_23;
  D.15251_25 = *D.15236_2;
  D.15256_26 = iD.15246_18 * 16;
  D.15250_27 = D.15251_25 + D.15256_26;
  D.15249_28 = *D.15250_27;
  D.15247_29 = __builtin_ia32_pand128D.1150 (D.15249_28, D.15252_24);
  *D.15255_20 = D.15247_29;
  iD.15246_30 = iD.15246_18 + 1;

:
  # iD.15246_18 = PHI <0(6), iD.15246_30(7)>
  if (max_idxD.15245_16 != iD.15246_18)
goto ;

already (_ZN10bit_vector6op_andERKS_S1_).

Now the main issue why the redundant loads are not hoisted is that all
data pointers are ref-all:

  chunk_typeD.13721 * {ref-all} D.15255;

thus you tell the compiler that the store

  *D.15255_20 = D.15247_29;

might possibly clobber all loads in that loop.  Of course chunk_type is
just __m128i and I always complained that this is ref-all which makes
optimization of pointers to __m128i practically useless.

This is really a target header problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org,
   ||rguenth at gcc dot gnu dot
   ||org, hjl at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |target
 Ever Confirmed|0   |1
   Keywords||alias, missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-01-17 21:05:55
   date||
Summary|[C++0x] Variadic templates +|[C++0x] Variadic templates +
   |lambdas = extremely poor|lambdas = extremely poor
   |code quality|code quality, __m128i and
   ||aliasing sucks


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

[Bug fortran/42781] [4.5 Regression] ICE in pt_solutions_same_restrict_base, at tree-ssa-structalias.c:5072

[anlauf at gmx dot de]

--- Comment #1 from anlauf at gmx dot de  2010-01-17 21:02 ---
Created an attachment (id=19641)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19641&action=view)
Source code for demo


-- 


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

[Bug fortran/42781] New: [4.5 Regression] ICE in pt_solutions_same_restrict_base, at tree-ssa-structalias.c:5072

[anlauf at gmx dot de]

Hi,

the following error occurs only at -O1, not at -O0 or -O2 or -O3:

gfcbug98.f90: In function ‘convert_cof’:
gfcbug98.f90:36:0: internal compiler error: in pt_solutions_same_restrict_base,
at tree-ssa-structalias.c:5072

This error does not occur with 4.3.x or 4.4.0


-- 
   Summary: [4.5 Regression] ICE in pt_solutions_same_restrict_base,
at tree-ssa-structalias.c:5072
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anlauf at gmx dot de
  GCC host triplet: i686-pc-linux-gnu


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

[Bug fortran/42550] Unable to give initial value 2**0.5 to a real varable

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2010-01-17 20:54 ---
Fixed on trunk.  Not backport.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2010-01-17 20:53 ---
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html

Actually I don't see how this bug could be caused by r152526. That patch was
about SELECT TYPE and (ideally) should have no effect on TBPs at all. Also, at
first sight, I don't see anything suspicious in the patch. Is there any
evidence for the above claim?


-- 


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

[Bug tree-optimization/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-01-17 20:49 
---
Still, please provide a short self-contained snippet, no includes, or in any
case, only the bare minimum. Thanks. Again, no cross-references.


-- 


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

[Bug tree-optimization/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality

[piotr dot wyderski at gmail dot com]

--- Comment #3 from piotr dot wyderski at gmail dot com  2010-01-17 20:46 
---
This is a generic code, as it covers two bug reports.
In fact, it will probably be used as a base for additional
two missing optimization reports. So I thought it would be
good to provide the code of the entire sandbox.

To be more specific: the vectors passed to
combine() are constant. The compiler should
not re-evaluate the base addresses of the
m_Data arrays every iteration, as above:

mov(%edi),%ecx
...
mov0x0(%ebp),%ecx
...
mov(%esi),%ecx

A single base address fetch phase and
index-based addressing with scaled
induction variable (by a factor of 16)
will be more optimal, e.g.:

   // esi = src1
   // edi = src2
   // ebx = dst
   // edx = induction variable

L0:cmpl   %edx, max_index
   je L1:
   movdqa (%esi,%edx,1),%xmm0
   por(%edi,%edx,1),%xmm0
   pxor   %xmm1, %xmm0
   movdqa %xmm0, (%ebx, %edx, 1)
   add$16, %edx
   jmpL0

L1:

as I would have written it by hand in assembler.
An aggresively unrolled version (say, four-way)
with prefetching for longer blocks will also be welcome.


-- 


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

[Bug c++/42780] Incorrect warning message

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-17 20:42 
---
Please provide a stand-alone, minimal testcase for the purpose of showing the
spurious warning. No cross-citations, please.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-01-17 20:25 ---
Created an attachment (id=19640)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19640&action=view)
Patch to teach {,un}aligned_memory_operand about unaligned offsets

Mikael, can you please test attached patch on your target? Unaligned offsets
should be classified as unaligned memory access.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug tree-optimization/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-01-17 20:21 
---
I would suggest providing a snippet *much* smaller and explain more clearly the
issue, for example, providing two small functions (say, below 10, 20 lines),
one using more high-level C++0x features and the other using old style
solutions.

That is, if you hope to have somebody actually working on a fix ;)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|piotr dot wyderski at gmail |
   |dot com |


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

[Bug c++/42780] New: Incorrect warning message

[piotr dot wyderski at gmail dot com]

Uncomment the code of bit_vector::op_not (Attachment #19639)
and compile with 

g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp

an error message will appear:

main.cpp: In function 'long long int __vector__ dump(long long int
__vector__)':
main.cpp:653:1: error: control reaches end of non-void function

but the function dump() is not non-void:

void dump(__m128i v) { ...


-- 
   Summary: Incorrect warning message
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
  GCC host triplet: GCC-trunk(20100107)/Cygwin/WinXP32


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

[Bug tree-optimization/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality

[piotr dot wyderski at gmail dot com]

--- Comment #1 from piotr dot wyderski at gmail dot com  2010-01-17 20:15 
---
Created an attachment (id=19639)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19639&action=view)
Source code


-- 


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

[Bug tree-optimization/42779] New: [C++0x] Variadic templates + lambdas = extremely poor code quality

[piotr dot wyderski at gmail dot com]

The attached code compiled with

g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp

emits code which is, to put it mildly,
far from optimal. For instance, the code of

bit_vector::op_not_or:

combine([](__m128i x, __m128i y) { return _mm_xor_si128(_mm_or_si128(x, y),
g_Mask[128]); }, true, v1, v2);

emits:

00401800 <__ZN10bit_vector9op_not_orERKS_S1_>:
  401800:   55  push   %ebp
  401801:   57  push   %edi
  401802:   56  push   %esi
  401803:   53  push   %ebx
  401804:   83 ec 1csub$0x1c,%esp
  401807:   8b 74 24 30 mov0x30(%esp),%esi
  40180b:   8b 7c 24 34 mov0x34(%esp),%edi
  40180f:   8b 6c 24 38 mov0x38(%esp),%ebp
  401813:   8b 5f 04mov0x4(%edi),%ebx
  401816:   39 ee   cmp%ebp,%esi
  401818:   74 46   je 401860
<__ZN10bit_vector9op_not_orERKS_S1_+0x60>
  40181a:   83 c3 7fadd$0x7f,%ebx
  40181d:   c1 eb 07shr$0x7,%ebx
  401820:   85 db   test   %ebx,%ebx
  401822:   74 30   je 401854
<__ZN10bit_vector9op_not_orERKS_S1_+0x54>
  401824:   31 c0   xor%eax,%eax
  401826:   66 0f 76 c9 pcmpeqd %xmm1,%xmm1
  40182a:   8d b6 00 00 00 00   lea0x0(%esi),%esi
  401830:   8b 0f   mov(%edi),%ecx
  401832:   89 c2   mov%eax,%edx
  401834:   40  inc%eax
  401835:   c1 e2 04shl$0x4,%edx
  401838:   39 c3   cmp%eax,%ebx
  40183a:   66 0f 6f 04 11  movdqa (%ecx,%edx,1),%xmm0
  40183f:   8b 4d 00mov0x0(%ebp),%ecx
  401842:   66 0f eb 04 11  por(%ecx,%edx,1),%xmm0
  401847:   8b 0e   mov(%esi),%ecx
  401849:   66 0f ef c1 pxor   %xmm1,%xmm0
  40184d:   66 0f 7f 04 11  movdqa %xmm0,(%ecx,%edx,1)
  401852:   75 dc   jne401830
<__ZN10bit_vector9op_not_orERKS_S1_+0x30>
  401854:   83 c4 1cadd$0x1c,%esp
  401857:   5b  pop%ebx
  401858:   5e  pop%esi
  401859:   5f  pop%edi
  40185a:   5d  pop%ebp
  40185b:   c3  ret


-- 
   Summary: [C++0x] Variadic templates + lambdas = extremely poor
code quality
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
  GCC host triplet: GCC-trunk(20100107)/Cygwin/WinXP32


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

[Bug tree-optimization/42778] New: Superfluous stack management code is generated

[piotr dot wyderski at gmail dot com]

#include 

int test1(__m128i v) {

   return _mm_cvtsi128_si32(v);
}

compiled with

g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp

emits:

004012e0 <__Z5test1U8__vectorx>:
 4012e0:   83 ec 0csub$0xc,%esp
 4012e3:   66 0f 7e c0 movd   %xmm0,%eax
 4012e7:   83 c4 0cadd$0xc,%esp
 4012ea:   c3  ret

which shows that the stack pointer is being updated
without any purpose.


-- 
   Summary: Superfluous stack management code is generated
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
  GCC host triplet: GCC-trunk(20100107)/Cygwin/WinXP32


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-01-17 19:57 ---
Is this related to PR 39954?


-- 


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-01-17 19:52 ---
Created an attachment (id=19638)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19638&action=view)
reduced test case

I'm attaching a really tiny test case. The trigger appears to be a 2-byte load
from the stack that crosses the boundary between two adjacent 4-byte ints.


-- 


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2010-01-17 19:47 ---
Well, gcc would just generate invalid code without this assert.

Reduced test:

--cut here--
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
typedef uint16_t u16;
typedef uint32_t u32;
typedef uint64_t u64;
enum
{ FSYSHEADKEY_NULL =
0, FSYSHEADKEY_FILESYSTEM, FSYSHEADKEY_MNTPATH, FSYSHEADKEY_BYTESTOTAL,
FSYSHEADKEY_MINFSAVERSION, FSYSHEADKEY_MOUNTINFO, FSYSHEADKEY_ORIGDEV,
FSYSHEADKEY_FSEXTEOPTRAIDSTRIDE };
typedef struct s_dico
{
}
cdico;
struct s_ntfsinfo
{
  u32 bytes_per_sector;
  u64 uuid;
};
enum
{ MSG_FORCE = 0, MSG_VERB1 = 1, MSG_VERB2 = 2, MSG_STACK = 3, MSG_DEBUG1 =
4, MSG_DEBUG2 = 5, MSG_DEBUG3 = 6, MSG_DEBUG4 = 7, MSG_DEBUG5 = 8 };
ntfs_getinfo (cdico * d, char *devname)
{
  struct s_ntfsinfo info;
  char bootsect[512];
  int fd = -1;

  info.bytes_per_sector = ((u16) (*((u16 *) (bootsect + 0xB;

  foo (info.bytes_per_sector);
  info.uuid = ((u64) (*((u64 *) (bootsect + 0x48;
  fsaprintf (MSG_VERB2, 0, MSG_VERB2 >= 3, "fs_ntfs.c", __FUNCTION__, 107,
 "bytes_per_sector=[%lld]\n", (long long) info.bytes_per_sector);
  fsaprintf (MSG_VERB2, 0, MSG_VERB2 >= 3, "fs_ntfs.c", __FUNCTION__, 109,
 "uuid=[%016llX]\n", (long long unsigned int) info.uuid);
  dico_add_u64 (d, 0, FSYSHEADKEY_MINFSAVERSION,
((u64)
 u64) 0 & 0x) << 48) + (((u64) 6 & 0x) << 32) +
  (((u64) 4 & 0x) << 16) + (((u64) 0 & 0x) << 0;
}
--cut here--

Problematic line is bootsect + 0xB that crosses SImode aligned load.


-- 


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-01-17 19:08 ---
Reproduced with an alpha-unknown-linux cross hosted on i686, built from
gcc-4.4-20100112.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/42775] sparc-linux 4.4.2 fails to rebuild itself when using STAGE1_CFLAGS=-O1

[armin76 at gentoo dot org]

--- Comment #2 from armin76 at gentoo dot org  2010-01-17 19:07 ---
(In reply to comment #1)
> Please try to reproduce with the 4.4.3 release candidate.
> 

gcc-4.4.3-RC-20100116 fails the same way.


-- 


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[hjl dot tools at gmail dot com]

--- Comment #28 from hjl dot tools at gmail dot com  2010-01-17 19:00 
---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[hjl at gcc dot gnu dot org]

--- Comment #27 from hjl at gcc dot gnu dot org  2010-01-17 18:57 ---
Subject: Bug 42542

Author: hjl
Date: Sun Jan 17 18:57:33 2010
New Revision: 155990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155990
Log:
Backport ia64 fix for PR target/42542 from mainline.

gcc/

2010-01-17  H.J. Lu  

Backport from mainline:
2010-01-13  Steve Ellcey  

PR target/42542
* config/ia64/ia64.c (ia64_expand_vecint_compare): Convert GTU to GT
for V2SI by subtracting (-(INT MAX) - 1) from both operands to make
them signed.

gcc/testsuite/

2010-01-17  H.J. Lu  

Backport from mainline:
2010-01-13  Steve Ellcey  

PR target/42542
* gcc.target/ia64/pr42542-1.c: New.
* gcc.target/ia64/pr42542-2.c: New.
* gcc.target/ia64/pr42542-3.c: New.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr42542-1.c
  - copied unchanged from r155989,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr42542-2.c
  - copied unchanged from r155989,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-2.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr42542-3.c
  - copied unchanged from r155989,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-3.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/ia64/ia64.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.

[gary at intrepid dot com]

--- Comment #10 from gary at intrepid dot com  2010-01-17 18:56 ---
(In reply to comment #9)
> Since the corresponding binutils bug is fixed, should this PR be closed ?

We ran into this bug recently, running tests against a GCC (4.5 precursor)
snapshot.  Discussion here:
http://gcc.gnu.org/ml/gcc/2010-01/msg00332.html


-- 

gary at intrepid dot com changed:

   What|Removed |Added

 CC||gary at intrepid dot com


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[hjl at gcc dot gnu dot org]

--- Comment #26 from hjl at gcc dot gnu dot org  2010-01-17 18:55 ---
Subject: Bug 42542

Author: hjl
Date: Sun Jan 17 18:55:03 2010
New Revision: 155989

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155989
Log:
Backport ia64 fix for PR target/42542 from mainline.

gcc/

2010-01-17  H.J. Lu  

Backport from mainline:
2010-01-13  Steve Ellcey  

PR target/42542
* config/ia64/ia64.c (ia64_expand_vecint_compare): Convert GTU to GT
for V2SI by subtracting (-(INT MAX) - 1) from both operands to make
them signed.

gcc/testsuite/

2010-01-17  H.J. Lu  

Backport from mainline:
2010-01-13  Steve Ellcey  

PR target/42542
* gcc.target/ia64/pr42542-1.c: New.
* gcc.target/ia64/pr42542-2.c: New.
* gcc.target/ia64/pr42542-3.c: New.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/ia64/pr42542-1.c
  - copied unchanged from r155988,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/ia64/pr42542-2.c
  - copied unchanged from r155988,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/ia64/pr42542-3.c
  - copied unchanged from r155988,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-3.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/ia64/ia64.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[hjl at gcc dot gnu dot org]

--- Comment #25 from hjl at gcc dot gnu dot org  2010-01-17 18:52 ---
Subject: Bug 42542

Author: hjl
Date: Sun Jan 17 18:51:47 2010
New Revision: 155988

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155988
Log:
Backport ia64 fix for PR target/42542 from mainline.

gcc/

2010-01-17  H.J. Lu  

Backport from mainline:
2010-01-13  Steve Ellcey  

PR target/42542
* config/ia64/ia64.c (ia64_expand_vecint_compare): Convert GTU to GT
for V2SI by subtracting (-(INT MAX) - 1) from both operands to make
them signed.

gcc/testsuite/

2010-01-17  H.J. Lu  

Backport from mainline:
2010-01-13  Steve Ellcey  

PR target/42542
* gcc.target/ia64/pr42542-1.c: New.
* gcc.target/ia64/pr42542-2.c: New.
* gcc.target/ia64/pr42542-3.c: New.

Added:
branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr42542-1.c
  - copied unchanged from r155987,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-1.c
branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr42542-2.c
  - copied unchanged from r155987,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-2.c
branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr42542-3.c
  - copied unchanged from r155987,
trunk/gcc/testsuite/gcc.target/ia64/pr42542-3.c
Modified:
branches/ix86/gcc-4_4-branch/gcc/ChangeLog
branches/ix86/gcc-4_4-branch/gcc/config/ia64/ia64.c
branches/ix86/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion

[simartin at gcc dot gnu dot org]

--- Comment #6 from simartin at gcc dot gnu dot org  2010-01-17 17:44 
---
The patch above is not a good idea, since it causes
g++.old-deja/g++.other/overload7.C to fail (the rest of the testsuite is OK)...


-- 


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

[Bug middle-end/42577] [4.4 Regression] array bounds false positive with -O3, goes away with -O2

[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=42577

[Bug tree-optimization/42438] [4.4 Regression] Fix for PR38819 is too conservative

[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=42438

[Bug tree-optimization/41454] [4.4 Regression] DOM miscompiles gcc.c-torture/execute/990513-1.c at -O2 -fno-tree-vrp

[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=41454

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug middle-end/42248] [4.5 Regression] compat test struct-by-value-17 fails execution with -O1 -fschedule-insns

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2010-01-17 17:01 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/42248] [4.5 Regression] compat test struct-by-value-17 fails execution with -O1 -fschedule-insns

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2010-01-17 17:00 
---
Subject: Bug 42248

Author: rguenth
Date: Sun Jan 17 17:00:47 2010
New Revision: 155984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155984
Log:
2010-01-17  Richard Guenther  

PR middle-end/42248
* function.c (split_complex_args): Take a VEC to modify.
(assign_parms_augmented_arg_list): Build a VEC instead of
a chain of PARM_DECLs.
(assign_parms_unsplit_complex): Take a VEC of arguments.
Do not fixup unmodified parms.
(assign_parms): Deal with the VEC.
(gimplify_parameters): Likewise.

* gcc.c-torture/execute/pr42248.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr42248.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/42248] [4.5 Regression] compat test struct-by-value-17 fails execution with -O1 -fschedule-insns

[pthaugen at gcc dot gnu dot org]

--- Comment #15 from pthaugen at gcc dot gnu dot org  2010-01-17 16:54 
---
Updated patch works for testcase and bootstrap/regtest on PPC passed.  Thx.


-- 


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

[Bug middle-end/42777] New: [graphite] loop interchange heuristic is broken

[spop at gcc dot gnu dot org]

Starting from r155273: Fix fall outs from Fix-PR42334.

2009-12-15  Sebastian Pop  

   PR middle-end/42178
   PR middle-end/42334
   * graphite-interchange.c (lst_try_interchange): Do not increment the
   the OUTER index when there is no AFTER kernel.  Do not increment the
   OUTER index for after processing the AFTER kernel.
   (lst_interchange_select_inner): Call lst_try_interchange only on loops.
   (lst_interchange_select_outer): Do not pass in a pointer to the OUTER
   index.  Do not pass to lst_interchange_select_inner the OUTER index.
   (scop_do_interchange): Update use of lst_interchange_select_outer.

   * testsuite/gfortran.dg/graphite/graphite.exp
   (DEFAULT_FLAGS_GRAPHITE_IDENTITY): Remove -fdump-tree-graphite-all.
   * testsuite/gfortran.dg/graphite/interchange-1.f: Add comment.  Clean
   the graphite dump file.
   * testsuite/gfortran.dg/graphite/interchange-2.f: Same.
   * testsuite/gfortran.dg/graphite/pr42334-1.f: New.

and with r155248: Fix PR42334: correct the update of the LST on loop
interchange and distribution.

2009-12-15  Sebastian Pop  

   PR middle-end/42178
   PR middle-end/42334
   * graphite-interchange.c (lst_perfect_nestify): Reset to NULL the LSTs
   that are empty.
   (lst_do_interchange_1): Renamed lst_interchange_select_inner.
   (lst_try_interchange): Reimplemented.
   (lst_interchange_select_inner): Same.
   (lst_do_interchange): Renamed lst_interchange_select_outer.
   Reimplemented.
   (scop_do_interchange): Update use of lst_interchange_select_outer.

   * testsuite/g++.dg/graphite/pr42130.C: Add -fgraphite-identity.
   * testsuite/gcc.dg/graphite/block-0.c: Un-XFAILed.
   * testsuite/gcc.dg/graphite/pr42211.c: New.
   * testsuite/gfortran.dg/graphite/pr42334.f90: New.

we have at least one benchmark in {calculix,gamess,mcf} from the
SPEC2006 that performs more than 20% slower at -O2 than at -O2
-fno-{graphite,loop-interchange,...} on the graphite branch: see the
recent test on http://groups.google.com/group/gcc-graphite-test

I am suspecting the heuristic of loop interchange to be in fault here,
as the above commit was fixing the traversal of the loops where the
interchange is applied.


-- 
   Summary: [graphite] loop interchange heuristic is broken
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: spop at gcc dot gnu dot org
ReportedBy: spop at gcc dot gnu dot org


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

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

[davek at gcc dot gnu dot org]

--- Comment #2 from davek at gcc dot gnu dot org  2010-01-17 16:13 ---
Created an attachment (id=19637)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19637&action=view)
binutils support

This is needed to extend the .section directive in the pe-coff port of gas so
that we can tell it to byte-align the lto sections.  See Bug 40392 for why we
need the sections to be byte-aligned (actually just byte-size-granularitied,
but the way COFF works at the moment in binutils the two are linked) and Bug
40754 for why this would be bad on a risc platform (but it's ok on x86 where we
can do misaligned accesses.)


-- 


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

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

[davek at gcc dot gnu dot org]

--- Comment #1 from davek at gcc dot gnu dot org  2010-01-17 16:09 ---
Created an attachment (id=19636)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19636&action=view)
work in progress patch

should be good for mingw as well.

needs some binutils support - will attach that here too, in case anyone wants
to try this patch out.


-- 


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

[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282

[davek at gcc dot gnu dot org]

--- Comment #14 from davek at gcc dot gnu dot org  2010-01-17 16:07 ---
(In reply to comment #13)

> Maybe.  Or simply store the size of the compressed blob at the beginning?

Yep, of course.  The padding trick is kinda neat because you can do it on the
fly at the end of writing the data without having to rewind the file, but
they'll both serve the job perfectly well.

> (Not that I have spent too much time with looking how zlib works)
> 
> > Apropos this particular patch, I see you've structured things so that the 
> > start
> > of each section is aligned, but the size is one-byte granular.  Is this
> > alignment necessary for any reason apart from allowing RISC machines to read
> > the words and half-words in the lto header struct without any worries about
> > misaligned access when using mmap?
> 
> Yes, that was the reason.  

That's convenient, as it gives me an option for a more minimal change to the
COFF assembler (at least until I want to worry about supporting non-x86 coff
platforms, anyway...)

> There was even a bug about this somewhen
> somewhere ...

  Ah, ITYM Bug 40754.


-- 


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

[Bug target/42775] sparc-linux 4.4.2 fails to rebuild itself when using STAGE1_CFLAGS=-O1

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-17 16:05 ---
Please try to reproduce with the 4.4.3 release candidate.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|bootstrap   |target


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

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- Comment #21 from davek at gcc dot gnu dot org  2010-01-17 16:01 ---
(In reply to comment #20)

> Well.  I suppose we can backport stuff for 4.5.1 if it is LTO specific
> but I don't want to have it before 4.5.0.

Thanks, that's how I'll proceed then.

> Please open an new bugreport for LTO on non-ELF platforms.

FTR: Bug 42776.


-- 


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

[Bug lto/42776] New: LTO doesn't work on non-ELF platforms.

[davek at gcc dot gnu dot org]

As per title, and see also the discussion in bug 41529.

There is no fundamental requirement for ELF to be the object format, as the
object file sections are just used as dumb containers for arbitrary binary
data.  The interface between lto-elf.c and the rest of lto1 needs only the
ability to create sections and to place and retrieve binary data in/from them,
so should be easy to implement for any object format that allows
arbitrarily-named sections; that's everything except a.out I would suppose.

I'm only planning to fix this for the PE-COFF (windows) platforms, but I'll try
and make the code general enough so that it works on other COFF platforms and
just needs enabling by the relevant target maintainer.


-- 
   Summary: LTO doesn't work on non-ELF platforms.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: build, lto
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: davek at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug tree-optimization/42773] [4.4 Regression] ICE with g++ from 4.4.3 20100112 (prerelease)

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-17 15:58 ---
Subject: Bug 42773

Author: rguenth
Date: Sun Jan 17 15:58:08 2010
New Revision: 155982

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155982
Log:
2010-01-17  Richard Guenther  

PR tree-optimization/42773
* tree-ssa-pre.c (phi_translate_set): Fix check for PHI node existence.
(compute_antic_aux): Likewise.
(compute_partial_antic_aux): Likewise.

* g++.dg/torture/pr42773.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr42773.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c


-- 


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

[Bug tree-optimization/42773] [4.4 Regression] ICE with g++ from 4.4.3 20100112 (prerelease)

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-17 15:55 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.3


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

[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2010-01-17 15:54 
---
(In reply to comment #12)
> (In reply to comment #4)
> > The patch is not yet in but I think it's the wrong approach.  Instead
> > uncompression should deal with tail padding.
> 
> I think you're right.  I just ran into this bug on cygwin (x86/PE-COFF) 
> because
> section sizes were being padded to meet the alignment requirements, rather 
> than
> leaving unallocated gaps between them.  A neat solution would be to use
> pkcs-style self-describing padding at the end of each section: you always add
> at least one byte of tail padding (even if that means adding a whole
> alignment-size word), and you put that number of bytes of padding in the final
> pad byte.  It would mean bumping the lto header version and watching out for
> back-compat of course.

Maybe.  Or simply store the size of the compressed blob at the beginning?
(Not that I have spent too much time with looking how zlib works)

> Apropos this particular patch, I see you've structured things so that the 
> start
> of each section is aligned, but the size is one-byte granular.  Is this
> alignment necessary for any reason apart from allowing RISC machines to read
> the words and half-words in the lto header struct without any worries about
> misaligned access when using mmap?

Yes, that was the reason.  There was even a bug about this somewhen
somewhere ...


-- 


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

[Bug bootstrap/42775] New: sparc-linux 4.4.2 fails to rebuild itself when using STAGE1_CFLAGS=-O1

[laurent at guerby dot net]

../gcc-4.4.2/configure --enable-languages=c --disable-werror
--enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib
--prefix=/opt/cfarm/release/4.4.2 --with-cpu=v8
make bootstrap && make install
PATH=/opt/cfarm/release/4.4.2/bin:$PATH
../gcc-4.4.2/configure --enable-languages=c --disable-werror
--enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib
--prefix=/opt/cfarm/release/4.4.2-v2 --with-cpu=v8
make bootstrap STAGE1_CFLAGS=-O1

fails with

/home/guerby/build442/./gcc/xgcc -B/home/guerby/build442/./gcc/
-B/opt/cfarm/release/4.4.2-v3/sparc64-unknown-linux-gnu/bin/
-B/opt/cfarm/release/4.4.2-v3/sparc64-unknown-linux-gnu/lib/ -isystem
/opt/cfarm/release/4.4.2-v3/sparc64-unknown-linux-gnu/include -isystem
/opt/cfarm/release/4.4.2-v3/sparc64-unknown-linux-gnu/sys-include -g -O2 -O2 
-g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include 
-fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I../../../gcc-4.4.2/libgcc -I../../../gcc-4.4.2/libgcc/.
-I../../../gcc-4.4.2/libgcc/../gcc -I../../../gcc-4.4.2/libgcc/../include 
-DHAVE_CC_TLS -o _popcountsi2.o -MT _popcountsi2.o -MD -MP -MF _popcountsi2.dep
-DL_popcountsi2 -c ../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c: In function '__popcountsi2':
../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c:787: internal compiler error: Bus
error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_popcountsi2.o] Error 1
make[3]: Leaving directory
`/home/guerby/build442/sparc64-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/guerby/build442'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build442'
make: *** [bootstrap] Error 2


Without STAGE1_CFLAGS=-O1 bootstrap works.

Note: this is gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=283041


-- 
   Summary: sparc-linux 4.4.2 fails to rebuild itself when using
STAGE1_CFLAGS=-O1
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: sparc-linux
  GCC host triplet: sparc-linux
GCC target triplet: sparc-linux


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

[Bug tree-optimization/42773] [4.4 Regression] ICE with g++ from 4.4.3 20100112 (prerelease)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-17 15:51 ---
Subject: Bug 42773

Author: rguenth
Date: Sun Jan 17 15:50:53 2010
New Revision: 155981

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155981
Log:
2010-01-17  Richard Guenther  

PR tree-optimization/42773
* tree-ssa-pre.c (phi_translate_set): Fix check for PHI node existence.
(compute_antic_aux): Likewise.
(compute_partial_antic_aux): Likewise.

* g++.dg/torture/pr42773.C: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42773.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-pre.c


-- 


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

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenther at suse dot de]

--- Comment #20 from rguenther at suse dot de  2010-01-17 15:48 ---
Subject: Re:  LTO configuration should detect if the
 target is ELF

On Sun, 17 Jan 2010, davek at gcc dot gnu dot org wrote:

> --- Comment #19 from davek at gcc dot gnu dot org  2010-01-17 15:08 
> ---
> Created an attachment (id=19635)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
> lto for cygwin, and probably other coff targets
> 
> FTR.  Well, that turned out to be quite easy.  Needs some support in binutils
> to allow us to override the default section alignment for object files, but
> that's trivial, and I'll send it to the binutils list shortly.
> 
> Sigh, most of this is almost-safe-enough-for-stage-3.  Oh well.

Well.  I suppose we can backport stuff for 4.5.1 if it is LTO specific
but I don't want to have it before 4.5.0.

> Should I reopen this bug, assign it to myself, retarget it to 4.6 and add the
> words "or COFF" to the summary?

Please open an new bugreport for LTO on non-ELF platforms.

Thanks.

> Results from this patch:
> 
> Running /gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/lto.exp ...
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -fwhopr
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -fwhopr
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -flto
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -flto
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -fwhopr
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -flto
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -flto
> 
> === gcc Summary ===
> 
> # of expected passes462
> # of unexpected failures8
> # of unresolved testcases   16
> # of unsupported tests  2
> /gnu/gcc/obj-lto/gcc/xgcc  version 4.5.0 20100116 (experimental) (GCC)
> 
> ... i.e. the only tests that still fail are one that uses visibility and one
> that has an ELF-specific .section directive in an asm, all the rest work and 
> in
> particular the "gcc.dg/lto/20081201-2 
> c_lto_20081201-2_0.o-c_lto_20081201-2_1.o
> execute -O3 -fwhopr" test succeeds which indicates real LTO is taking place 
> :-)
> 
> 
> 


-- 


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

[Bug c/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero

[mnemo at minimum dot se]

--- Comment #3 from mnemo at minimum dot se  2010-01-17 15:39 ---
I tried to attach the output of "gcc -E -O2 sqlite3.c" but it's 1.5MB and
bugzilla rejects anything bigger than 1KB. Even the unmodified source is larger
than this limit, even though you can download it via the sqlite.org URL I
posted.

Since this doesn't repro on gcc 4.4.3, maybe the bug should be closed though?


-- 


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

[Bug c/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero

[mnemo at minimum dot se]

--- Comment #2 from mnemo at minimum dot se  2010-01-17 15:34 ---
Using gcc 4.4.1, I see this:
1. "gcc -O2 sqlite3.c" repros the bug
2. "gcc -E sqlite3.c > pp.c" followed by "gcc -O2 pp.c" does _NOT_ repro the
bug

However, still using gcc 4.4.1, if I do:
1. "gcc -O2 -E sqlite3.c > ppo.c" followed by "gcc -O2 ppo.c" does repro the
bug

Finally, I also tried to upgrade to Ubuntu Lucid today which gave me gcc 4.4.3
and there I can't get the bug to repro at all.


-- 


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

[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282

[davek at gcc dot gnu dot org]

--- Comment #12 from davek at gcc dot gnu dot org  2010-01-17 15:28 ---
(In reply to comment #4)
> The patch is not yet in but I think it's the wrong approach.  Instead
> uncompression should deal with tail padding.

I think you're right.  I just ran into this bug on cygwin (x86/PE-COFF) because
section sizes were being padded to meet the alignment requirements, rather than
leaving unallocated gaps between them.  A neat solution would be to use
pkcs-style self-describing padding at the end of each section: you always add
at least one byte of tail padding (even if that means adding a whole
alignment-size word), and you put that number of bytes of padding in the final
pad byte.  It would mean bumping the lto header version and watching out for
back-compat of course.

Apropos this particular patch, I see you've structured things so that the start
of each section is aligned, but the size is one-byte granular.  Is this
alignment necessary for any reason apart from allowing RISC machines to read
the words and half-words in the lto header struct without any worries about
misaligned access when using mmap?  I think zlib should be pretty easy-going
about byte-aligned data streams, so if this is the only reason, it might be
easiest for cygwin (since x86 handles misaligned accesses) to just pack all the
lto sections with one byte alignment /and/ size granularity, and not worry
about the start of each lto data section being aligned or not.

So, would it be OK not to align the LTO sections to POINTER_SIZE?  Or is there
something elsewhere in LTO that requires it?


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||davek at gcc dot gnu dot org


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

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- Comment #19 from davek at gcc dot gnu dot org  2010-01-17 15:08 ---
Created an attachment (id=19635)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
lto for cygwin, and probably other coff targets

FTR.  Well, that turned out to be quite easy.  Needs some support in binutils
to allow us to override the default section alignment for object files, but
that's trivial, and I'll send it to the binutils list shortly.

Sigh, most of this is almost-safe-enough-for-stage-3.  Oh well.

Should I reopen this bug, assign it to myself, retarget it to 4.6 and add the
words "or COFF" to the summary?

Results from this patch:

Running /gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/lto.exp ...
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -flto

=== gcc Summary ===

# of expected passes462
# of unexpected failures8
# of unresolved testcases   16
# of unsupported tests  2
/gnu/gcc/obj-lto/gcc/xgcc  version 4.5.0 20100116 (experimental) (GCC)

... i.e. the only tests that still fail are one that uses visibility and one
that has an ELF-specific .section directive in an asm, all the rest work and in
particular the "gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o
execute -O3 -fwhopr" test succeeds which indicates real LTO is taking place :-)


-- 


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

[Bug middle-end/42248] [4.5 Regression] compat test struct-by-value-17 fails execution with -O1 -fschedule-insns

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2010-01-17 14:20 
---
Any news on the updated patch?


-- 


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