[Bug middle-end/46675] [4.6 Regression] profiledbootstrap failed

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.27 07:01:34
 CC||ubizjak at gmail dot com
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak  2010-11-27 07:01:34 
UTC ---
Continuing from [1]:

>> Any info what this verification error means?
>
> Either
>
> a.  A file (GtkComponentPeer.class) has been corrupted
>
> or
>
> b.  verify-* in gcc/java has been miscompiled by gcc.
>
> or
>
> c.  something used by verify-* in gcc/java has changed, and now
> verify-* is broken.

Right on spot, It is verify_instructions_0 from verify-impl.c that is
miscompiled. Following patch avoids these failures and enables
profiledbootstrap to finish:

Index: gcc/java/verify-impl.c
===
--- gcc/java/verify-impl.c(revision 167188)
+++ gcc/java/verify-impl.c(working copy)
@@ -2211,6 +2211,7 @@ initialize_stack (void)
 }

 static void
+__attribute__((__optimize__(1)))
 verify_instructions_0 (void)
 {
   int i;

[1] http://gcc.gnu.org/ml/gcc/2010-11/msg00615.html

[Bug c++/46680] Suboptimal code generated for bool comparisons

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

 CC||d.g.gorbachev at gmail dot
   ||com

--- Comment #1 from Dmitry Gorbachev  
2010-11-27 05:51:15 UTC ---
> Am I missing something?

-O1 / -O2 / -O3 / -Os option.

> but I think this is a strange behavior
> even for non-initialized variables.

http://en.wikipedia.org/wiki/Undefined_behavior

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #4 from Jack Howarth  2010-11-27 
05:40:07 UTC ---
(In reply to comment #3)
> no luck with ulimit -- I should have known since it is mmap
> trying w/o -disable-bootstra

Using the bash shell, try using...

ulimit -s `ulimit -s`

[Bug c++/46682] New: __sync_bool_compare_and_swap generates wrong code

[us15 at os dot inf.tu-dresden.de]

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

   Summary: __sync_bool_compare_and_swap generates wrong code
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: u...@os.inf.tu-dresden.de


Created attachment 22544
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22544
Testcase

Compile testcase with:

gcc-4.5.1  -MP -MMD -pipe -m32 -Os -march=i686 -mpreferred-stack-boundary=2
-mregparm=3 -fdata-sections -ffunction-sections -fomit-frame-pointer
-freg-struct-return -freorder-blocks -funit-at-a-time -fno-exceptions -fno-rtti
-fno-stack-protector -fvisibility-inlines-hidden -Wall -Wextra
-Waggregate-return -Wcast-align -Wcast-qual -Wconversion
-Wdisabled-optimization -Wformat=2 -Wmissing-format-attribute
-Wmissing-noreturn -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow
-Wwrite-strings -Wabi -Wctor-dtor-privacy -Wno-non-virtual-dtor
-Wold-style-cast -Woverloaded-virtual -Wsign-promo -Wframe-larger-than=64
-Wlogical-op -Wstrict-null-sentinel -Wstrict-overflow=5 -Wvolatile-register-var
-c testcase.cc -o testcase.o

This results in:

 :
   0:   53  push   %ebx
   1:   b8 01 00 00 00  mov$0x1,%eax
   6:   e8 fc ff ff ff  call   7 
   b:   31 d2   xor%edx,%edx
   d:   31 c9   xor%ecx,%ecx
   f:   6a 00   push   $0x0
  11:   6a 00   push   $0x0
  13:   6a 00   push   $0x0
  15:   89 c3   mov%eax,%ebx
  17:   e8 fc ff ff ff  call   18 
  1c:   8b 15 00 00 00 00   mov0x0,%edx
  22:   31 c0   xor%eax,%eax
  24:   f0 0f b1 1a lock cmpxchg %ebx,(%edx)
  28:   83 c4 0cadd$0xc,%esp
  2b:   74 07   je 34 
  2d:   b8 01 00 00 00  mov$0x1,%eax
  32:   eb 02   jmp36 
  34:   31 c0   xor%eax,%eax
  36:   e8 fc ff ff ff  call   37 

The "add" at offset 28 is messing up the flags for the "je" at offset 2b.

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  2010-11-27 
04:20:08 UTC ---
> I'm going to try removing assert.
> 
> It should be noted that on 32-bit HP-UX we create multiple unamed "sections"
> (subspaces) in an object.

Doesn't work.  Section handling is seriously broken:

libtool: link: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/
opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.6/hppa2.0w-h
p-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.11/include
-is
ystem /opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.11/sys-include-shared -fPIC
-W
l,+h -Wl,libgomp.sl.1 -Wl,+b -Wl,/opt/gnu/gcc/gcc-4.6/lib -o
.libs/libgomp.sl.1.
0  .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o
.lib
s/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o
.libs/pa
rallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o 
.libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o 
.libs/time.o .libs/fortran.o .libs/affinity.o   -lrt -lc  -pthread  
/usr/ccs/bin/ld: Internal Error 4012 (invalid subspace in symbol_value)
collect2: ld returned 1 exit status

[Bug fortran/46678] [4.6 Regression] Wrong code with strings

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #3 from Jerry DeLisle  2010-11-27 
03:11:11 UTC ---
Here is a reduced test case:

program test
   implicit none
   integer a(2)
   call sub(a,5)
end program test

subroutine sub(a,n)
   implicit none
   integer n
   integer a(n)
   character(size(a)) :: string
   print *, size(a)
   string = '1234567890'
   write(*,'(a)') string
end subroutine sub 

I think the problem is related to the declaration of string.  The size(a) used
for length is unknown until run time.

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  2010-11-27 
02:07:08 UTC ---
Backtrace:

Breakpoint 1, default_no_named_section (name=0x7afad8f0 ".text.startup",
flags=2097408, decl=0x7afa6900) at ../../gcc/gcc/varasm.c:5994
5994  gcc_unreachable ();
(gdb) bt
#0  default_no_named_section (name=0x7afad8f0 ".text.startup", flags=2097408,
decl=0x7afa6900) at ../../gcc/gcc/varasm.c:5994
#1  0x013c6334 in switch_to_section (new_section=0x7afad8e0) at
../../gcc/gcc/varasm.c:6863
#2  0x013ace1c in assemble_start_function (decl=0x7afa6900, fnname=0x7af53da0
"@main") at ../../gcc/gcc/varasm.c:1591
#3  0x01a583b0 in rest_of_handle_final () at ../../gcc/gcc/final.c:4227
#4  0x00d364e0 in execute_one_pass (pass=0x400219ac) at
../../gcc/gcc/passes.c:1564
#5  0x00d367d8 in execute_pass_list (pass=0x400219ac) at
../../gcc/gcc/passes.c:1619
#6  0x00d367fc in execute_pass_list (pass=0x400197a4) at
../../gcc/gcc/passes.c:1620
#7  0x00d367fc in execute_pass_list (pass=0x40019770) at
../../gcc/gcc/passes.c:1620
#8  0x025a4564 in tree_rest_of_compilation (fndecl=0x7afa6900) at
../../gcc/gcc/tree-optimize.c:422
#9  0x01492700 in cgraph_expand_function (node=0x7afb5000) at
../../gcc/gcc/cgraphunit.c:1508
#10 0x01492994 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1567
#11 0x014933c4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1823
#12 0x014906ac in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1031
#13 0x000c6300 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9837
#14 0x00ec1c38 in compile_file () at ../../gcc/gcc/toplev.c:819
#15 0x00ec5b28 in do_compile () at ../../gcc/gcc/toplev.c:2207
#16 0x00ec5dd0 in toplev_main (argc=17, argv=0x7eff055c) at
../../gcc/gcc/toplev.c:2270
#17 0x003866d4 in main (argc=17, argv=0x7eff055c) at ../../gcc/gcc/main.c:36

ICE doesn't occur at -O0.  Occurs at -O1 and above.  

I'm going to try removing assert.

It should be noted that on 32-bit HP-UX we create multiple unamed "sections"
(subspaces) in an object.

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

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

--- Comment #3 from Jay  2010-11-27 01:39:30 UTC 
---
no luck with ulimit -- I should have known since it is mmap
trying w/o -disable-bootstra

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

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

--- Comment #2 from Jay  2010-11-27 01:14:57 UTC 
---
Trying again with ulimit -d unlimited.
I wonder if something like can/should be automated, like with some wrapper
executable.
Notice I'm using -enable-checking.

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

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

--- Comment #1 from Jay  2010-11-27 01:09:47 UTC 
---
Actually running make again doesn't fix it.
And machine is nearly single-tasking at the moment.
I'll try without -disable-bootstrap.

[Bug middle-end/46681] New: insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

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

   Summary: insn-recog.c is too taxing on bootstrap compiler
(Apple gcc 4.0.1)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


gcc -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual \
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute \
-Wold-style-definition -fno-common  -DHAVE_CONFIG_H -I. -I. \
-I/src/gcc-trunk/gcc -I/src/gcc-trunk/gcc/. \
-I/src/gcc-trunk/gcc/../include -I/src/gcc-trunk/gcc/../libcpp/include
\
-I/src/gcc-trunk/gcc/../libdecnumber \
-I/src/gcc-trunk/gcc/../libdecnumber/dpd -I../libdecnumber   \
insn-recog.c -o insn-recog.o
cc1(5564) malloc: *** mmap(size=453095424) failed (error code=12)


This is on trunk with -disable-bootstrap.
I got something similar with 4.5.1, also -disable-bootstrap.


jbook2:~ jay$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)


jbook2:~ jay$ uname -a
Darwin jbook2 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386


jbook2:~ jay$ head /obj/gcc-trunk/config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /src/gcc-trunk/configure -prefix=/usr/local/gcc-trunk
-enable-checking=assert,df,fold,misc,rtl,rtlflag,runtime,tree
-disable-bootstrap -disable-intl -disable-nls -disable-libmudflap
-disable-libssp -disable-libgomp


jbook2:~ jay$ head /obj/gcc-4.5.1/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /src/gcc-4.5.1/configure -prefix=/usr/local/gcc-4.5.1
-enable-checking=assert,df,fold,misc,rtl,rtlflag,runtime,tree
-disable-bootstrap -disable-intl -disable-nls -disable-libmudflap
-disable-libssp -disable-libgomp


Running make a second time seems to work.
Machine has 4GB but isn't necessarily single tasking.

[Bug c++/46680] New: Suboptimal code generated for bool comparisons

[adriano.rezende at openbossa dot org]

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

   Summary: Suboptimal code generated for bool comparisons
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adriano.reze...@openbossa.org


Hi,

Take as reference the code below (compiled using gcc-4.4.1 on linux. command
line: g++ main.cpp):

int main()
{
bool value = true;

if (value) printf("true\n");
if (!value) printf("false\n");

return 0;
}

The first 'if' generates the following block:

cmpb$0, 31(%esp)
je.L2
movl$.LC0, (%esp)
callputs

While the second 'if' generates the following:

.L2:
movzbl31(%esp), %eax
xorl$1, %eax
testb%al, %al
je.L3
movl$.LC1, (%esp)
callputs

I think this:

movzbl31(%esp), %eax
xorl$1, %eax
testb%al, %al
je.L3

Could be replaced by this:

cmpb$0, 31(%esp)
jne.L3


Is there a reason to be like this? Am I missing something?

This change will remove two instructions per comparison and also solve a
strange behavior, which was the original reason for me to investigate it;

Take as an example a non-initialized bool variable, containing the value 0x8
(trash memory). The two lines below will be printed:

if (value) printf("true");
if (!value) printf("also true");

since the second 'if' will compute (0x1 xor 0x8) resulting in 0x9 (also true).

Maybe the spec doesn't care about this, but I think this is a strange behavior
even for non-initialized variables.

Br,
Adriano

[Bug middle-end/46679] New: fold_binary changes types in divisionm breaking configure -enable-checking

[jay.krell at cornell dot edu]

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

   Summary: fold_binary changes types in divisionm breaking
configure -enable-checking
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


fold_binary seemingly changes the types of division inputs (but not the
output),
leading to configure -enable-checking to fail.


My code is something like this (using a different frontend
and slightly patched 4.5.1 but I don't think relevantly):


long a;

long F(void)
{
 return a / a;
}

configure -enable-checking=fold,...:

gcc-4.5
fold-const.c

fold_binary_loc(code = FLOOR_DIV_EXPR,
op0, op1, type all int_64


arg0, arg1 become word_64
(not op0, op1, but arg0, arg1)


and then we end up here:

  if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
  && multiple_of_p (type, arg0, arg1))
return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);


and then:


error: type mismatch in binary expression
int_64
word_64
word_64


D.1003 = D.1001 /[ex] D.1002;


multiple_of_p is true because the operands are the same.
 (This would optimize to 1, unless the operands might be 0.)


I'll see if I can reproduce with unpatched C 4.5.1 and trunk.


 - Jay

[Bug fortran/46678] [4.6 Regression] Wrong code with strings

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2010-11-27 
00:35:04 UTC ---
(In reply to comment #1)
> testing:  r162217  (589550ff51f6645a92a0538f31953b94e40585b4)
> testing:  r162219  (c5faa79924f2b5c58fd21b6bd2416836985dfc25)

Forgot to change that: The first is working, the second is failing.


If one looks at the original dump, the only difference is nesting:


While the working version has:

sub (integer(kind=1)[0:D.1600] * restrict a, integer(kind=4) & restrict n)
{
  
  {
 // setup .string and other initialization
  }
  {
 // memmove etc.
  }
  {
 // write
  }
}


While the failing version uses:

sub (integer(kind=1)[0:D.1600] * restrict a, integer(kind=4) & restrict n)
{
  
  {
 // setup .string and other initialization
{
   // memmove etc.
}
{
   // write
}
  }
}

[Bug fortran/46678] [4.6 Regression] Wrong code with strings

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||domob at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Target Milestone|--- |4.6.0

--- Comment #1 from Tobias Burnus  2010-11-27 
00:27:19 UTC ---
testing:  r162217  (589550ff51f6645a92a0538f31953b94e40585b4)
testing:  r162219  (c5faa79924f2b5c58fd21b6bd2416836985dfc25)


That's the commit (for TRY_FINALLY?):

Date: Thu Jul 15 12:23:47 2010
New Revision: 162219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162219

2010-07-15  Daniel Kraft  
PR fortran/44709


My impression is that the issue is related to how the string length is stored
for the variable-length strings.

CC: Paul as the issue is quite similar to the issues one sees for character
deferred-type parameter.

[Bug fortran/46678] New: [4.6 Regression] Wrong code with strings

[burnus at gcc dot gnu.org]

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

   Summary: [4.6 Regression] Wrong code with strings
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Blocks: 46641


Related to PR 46641. Part of
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1b907e3b7b6f3461


Test case:
http://groups.google.com/group/comp.lang.fortran/msg/cb8e13e6226bc6c5

gfortran mishandles strings. The program should - and does with GCC 4.5 - print 
...
Calling sub with N = 9
123456789
...

However, GCC 4.6 prints garbage such as:
...
Calling sub with N = 124
|P���1234|>|3456789012345678{�R@@V���
...


working: GCC 4.5.1 20101116
working: 2010-07-12-r162074
working:r162209 (cff02494c6064641537dbe3d76430c6a6d7b5c49)

failing:r162225 (4fc1631a745b296a00a1c12167f4bbe7e93b047d)
failing:r162275 (cb885d9b457451ef64ec3dc093ef6c78545fb199)
failing:r162276 (540a8975b511546901446f43b79d46e52690b4f3)
failing: 2010-07-16-r162255 (segfault), 2010-08-28-r163612 (bogus characters)
failing: GCC 4.6.0 20101116 and 20101124

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  2010-11-26 23:45:16 UTC ---
On Fri, 26 Nov 2010, amylaar at gcc dot gnu.org wrote:

> > * All the macros relating to the sizes of various C types in bits should 
> > be replaced by hooks that are only called to create the associated tree 
> > nodes; elsewhere they should be replaced by TYPE_PRECISION 
> > (integer_type_node) etc.
> 
> You are not making this easier for LTO to optimize this back to a constant.

These don't need to be optimized back to a constant at all.

The C type sizes are essentially a front end matter.  Most places in the 
front ends already use TYPE_PRECISION anyway, e.g. when checking if a type 
is narrower than int so should be promoted to int.  Some front-end things 
are expensive, e.g. C++ parsing; checks of type precisions aren't.  The 
*only* uses of these macros in the C and C++ front ends are uses of 
CHAR_TYPE_SIZE in c_common_to_target_charset which is used in a few places 
in builtins.c (via lang_hooks.to_target_charset) and is not 
performance-sensitive.

Optimizers should be checking the precisions of the particular types they 
are dealing with and not care about what's "int" or "char" at all.

> What about the floating-point types?  Or would we rather have an
> enum type_kind?  Although that might be confused with what we used to
> have for varargs before gimple, i.e. a kind of type.

I'd guess a separate hook; they tend to vary somewhat independently from 
integer types.  bool would probably also be separate.  So you might have 
hooks for: general integer types; bool; binary floating-point; decimal 
floating-point; fixed-point; hook definitions would all have a 
gcc_unreachable (); default case to catch inappropriate enum values being 
passed in.  And another hook for ADA_LONG_TYPE_SIZE (defaulting to 
calling targetm.integer_type_size (itk_long)), I guess.

> >  (Many targets might define that hook to integer_type_size_il32 or 
> > integer_type_size_i32l64 or integer_type_size_i16l32 as default versions 
> > defined for common cases, rather than having their own function.)
> 
> New targets might do that, but I don't see why we would want to rewrite
> every target now; we could define the new hook in terms of the old macros.

Yes, you could as a temporary transitional measure, like for other hooks, 
but certainly I think all definitions of hooks in terms of the old macros 
should be considered temporary with the aim being to convert all targets 
and poison the macro names.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2010-11-26 
23:08:50 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> 
> > No.  The optimization passes that are remotely related do not work
> > flow or context sensitive, so we don't know whether the initialization
> > takes place unless it is a static initializer.
> 
> What about the case where there is a static initializer and another assignment
> that assigns the same value as the static initializer?

We don't currently handle this case - we'd need to remove the store as
dead to be able to promote the static variable to const (only then we
will be able to optimize reads from it).  The pass that is doing the
related work is ipa-reference.c.

[Bug middle-end/46488] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization -O3

[lk0946 at att dot com]

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

--- Comment #13 from Lance Kinley  2010-11-26 22:57:08 
UTC ---
-O and -O2 are broken in 4.5.1 but work in the 4.5 and 4.6 snapshots.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[amylaar at gcc dot gnu.org]

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

--- Comment #7 from Jorn Wolfgang Rennecke  
2010-11-26 22:34:08 UTC ---
(In reply to comment #6)

> No.  The optimization passes that are remotely related do not work
> flow or context sensitive, so we don't know whether the initialization
> takes place unless it is a static initializer.

What about the case where there is a static initializer and another assignment
that assigns the same value as the static initializer?

[Bug middle-end/46488] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.5.2   |---
Summary|[4.5 regression]|server/core_filters.c from
   |server/core_filters.c from  |apache httpd 2.2.17
   |apache httpd 2.2.17 |miscompiled with
   |miscompiled with|optimization -O3
   |optimization|
  Known to fail||4.5.1, 4.6.0

--- Comment #12 from Richard Guenther  2010-11-26 
22:22:12 UTC ---
I you can't confirm that it worked with 4.4.x or earlier versions with the
options that break with 4.5 and 4.6 this isn't a regression.

Btw, in the original report it sounds like -O2 is broken as well, but in
reality only -O3 is broken?  Both for 4.5 and 4.6 snapshots?

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2010-11-26 
22:18:23 UTC ---
(In reply to comment #5)
> (In reply to comment #3)
> > * Modifiable members of targetm are a bad idea and make LTO-based 
> > devirtualization harder (I'd rather targetm was const for single-target 
> > builds), and these values depend on command-line options so function 
> > members are more appropriate.
> 
> But if these members are only ever assigned a single constant, wouldn't
> LTO be able to figure this out?

No.  The optimization passes that are remotely related do not work
flow or context sensitive, so we don't know whether the initialization
takes place unless it is a static initializer.

> > * All the macros relating to the sizes of various C types in bits should 
> > be replaced by hooks that are only called to create the associated tree 
> > nodes; elsewhere they should be replaced by TYPE_PRECISION 
> > (integer_type_node) etc.
> 
> You are not making this easier for LTO to optimize this back to a constant.

True.  LTO won't be able to figure out TYPE_PRECISION (char_type_node).

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization

[lk0946 at att dot com]

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

--- Comment #11 from Lance Kinley  2010-11-26 22:10:16 
UTC ---
Works with -O and -O2 on the 4.5 snapshot and the 4.6 snapshot.

-O3 is the culprit.

I have not tested with any other versions other than 4.5.1 and the two
snapshots mentioned.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[amylaar at gcc dot gnu.org]

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

--- Comment #5 from Jorn Wolfgang Rennecke  
2010-11-26 22:08:11 UTC ---
(In reply to comment #3)
> * Modifiable members of targetm are a bad idea and make LTO-based 
> devirtualization harder (I'd rather targetm was const for single-target 
> builds), and these values depend on command-line options so function 
> members are more appropriate.

But if these members are only ever assigned a single constant, wouldn't
LTO be able to figure this out?

> * All the macros relating to the sizes of various C types in bits should 
> be replaced by hooks that are only called to create the associated tree 
> nodes; elsewhere they should be replaced by TYPE_PRECISION 
> (integer_type_node) etc.

You are not making this easier for LTO to optimize this back to a constant.

> - certainly, it should be fine to replace uses of 
> the macros in the front ends by using TYPE_PRECISION right now.  If the 
> tree optimizers are using these macros, they probably shouldn't be; to my 
> mind, it's a bug in a tree optimizer if it depends on details such as what 
> C "int" happens to be, as opposed to e.g. information about how efficient 
> computations on particular precisions happen to be.  (Thus, existing uses 
> of TYPE_PRECISION (integer_type_node) in tree optimizers would also be 
> suspicious.)

That might well be true, but by the time all such places are fixed up,
the hookization project might be forgotten.

> * I already said in  what 
> I thought hooks for *_TYPE_SIZE should look like; I strongly advise paying 
> attention to such comments.  There might be a case for separating the 
> standard C integer types from the fixed-point types, say, but I think one 
> hook for all the standard types is better than separate hooks for each 
> type.

Sorry, that had slipped my mind.

What about the floating-point types?  Or would we rather have an
enum type_kind?  Although that might be confused with what we used to
have for varargs before gimple, i.e. a kind of type.

>  (Many targets might define that hook to integer_type_size_il32 or 
> integer_type_size_i32l64 or integer_type_size_i16l32 as default versions 
> defined for common cases, rather than having their own function.)

New targets might do that, but I don't see why we would want to rewrite
every target now; we could define the new hook in terms of the old macros.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[amylaar at gcc dot gnu.org]

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

--- Comment #4 from Jorn Wolfgang Rennecke  
2010-11-26 21:53:40 UTC ---
Created attachment 22543
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22543
patch using DEFHOOKPOD

For the record, this is the patch using DEFHOOKPOD.

[Bug middle-end/46499] [4.5 Regression] gcc.c-torture/execute/20051021-1.c FAILs with -fno-tree-dominator-opts -fno-tree-ccp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.5/4.6 Regression]|[4.5 Regression]
   |gcc.c-torture/execute/20051 |gcc.c-torture/execute/20051
   |021-1.c FAILs with  |021-1.c FAILs with
   |-fno-tree-dominator-opts|-fno-tree-dominator-opts
   |-fno-tree-ccp   |-fno-tree-ccp

--- Comment #6 from Jakub Jelinek  2010-11-26 
21:46:57 UTC ---
Fixed on the trunk so far.

[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  2010-11-26 21:32:39 
UTC ---

Notes:  

(temporary work-arounds)

1. for Fortran, one can effect a fix by altering the dsymutil spec in
config/darwin.h and config/darwin9.h thus:

.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03:

2. The generic 'failing' is that the spec is looking at only the last item on
the c/l -- if that happens to be a source file, the dSYM will be generated.  
There isn't a generic facility to recognize *any* source file and post a flag
(perhaps something worth considering in 4.7).

So, you need to make at least one of your source files the last entry on the
c/l.

3. To avoid the need for the dSYM at all -- if all you want to do is to debug
locally -- just use "-save-temps".

4. Note that there are incompatibilities between the current debug output of
FSF gcc and dsymutil  - we cannot 'fix' dsymutil as it is closed source.  At
present, these cause irritating but harmless warnings.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  2010-11-26 21:28:52 UTC ---
On Fri, 26 Nov 2010, dave at hiauly1 dot hia.nrc.ca wrote:

> I needed to add __float128 type and some builtins.  To do this, I

__float128 should only be present where it is distinct from long double; 
it just confuses things to add it on other architectures.

> essentially copied stuff from ia64.  As things stand now, it seems
> the fortran front end uses the 'l' math functions in preference to
> the 'q' functions in libquadmath.
> 
> It appears the configure for libgfortran checks for the presence
> of all the 'l' math functions.  However, it might be better to map
> 'l' to 'q' in a quadmath header, so libquadmath doesn't depend on
> libgfortran (i.e., make it usable from C, etc).
> 
> Does this make sense?

No.  The purpose of libquadmath is to provide functions for the __float128 
type which is not a standard C type, for targets where it is present as a 
fourth floating-point type.  It is not to substitute for deficiencies in 
the system libm regarding functions for the standard three types.

If you wish to create a substitute or add-on libm for standard functions 
for the standard types where system libm is missing them, discuss that on 
the mailing lists, not in a Bugzilla PR.  It should not be libquadmath; it 
should be called something else, although it might share some source 
files.  The source files would in that case be adapted to abstract away 
the name of the type involved, so they can be built for either __float128 
or long double.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2010-11-26 21:24:05 UTC ---
On Fri, 26 Nov 2010, amylaar at gcc dot gnu.org wrote:

> The frontends and tree optimizers use the *_TYPE_SIZE and POINTER_SIZE
> target macros.
> 
> They should instead use to-be-created data members of targetm.

No, they shouldn't.

* POINTER_SIZE and ADA_LONG_TYPE_SIZE I haven't looked at in detail - 
though I'm aware of the comment in cppbuiltin.c about why it uses 
POINTER_SIZE (incorrectly divided by BITS_PER_UNIT rather than 
TYPE_PRECISION (char_type_node)) rather than ptr_type_node.

* WCHAR_TYPE_SIZE should go away completely (it's only used for Ada); this 
size should be determined from WCHAR_TYPE.

* Modifiable members of targetm are a bad idea and make LTO-based 
devirtualization harder (I'd rather targetm was const for single-target 
builds), and these values depend on command-line options so function 
members are more appropriate.

* All the macros relating to the sizes of various C types in bits should 
be replaced by hooks that are only called to create the associated tree 
nodes; elsewhere they should be replaced by TYPE_PRECISION 
(integer_type_node) etc. - certainly, it should be fine to replace uses of 
the macros in the front ends by using TYPE_PRECISION right now.  If the 
tree optimizers are using these macros, they probably shouldn't be; to my 
mind, it's a bug in a tree optimizer if it depends on details such as what 
C "int" happens to be, as opposed to e.g. information about how efficient 
computations on particular precisions happen to be.  (Thus, existing uses 
of TYPE_PRECISION (integer_type_node) in tree optimizers would also be 
suspicious.)

* I already said in  what 
I thought hooks for *_TYPE_SIZE should look like; I strongly advise paying 
attention to such comments.  There might be a case for separating the 
standard C integer types from the fixed-point types, say, but I think one 
hook for all the standard types is better than separate hooks for each 
type.  (Many targets might define that hook to integer_type_size_il32 or 
integer_type_size_i32l64 or integer_type_size_i16l32 as default versions 
defined for common cases, rather than having their own function.)

[Bug tree-optimization/46651] ICE with graphite enabled in cairo-1.8.10

[bjackson at inavia dot net]

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

--- Comment #6 from Brad Jackson  2010-11-26 
21:19:17 UTC ---
It happens for me compiling Firefox from trunk source on 32-bit Intel/Linux
using -march=core2, but this doesn't appear to be specific to an architecture.
I'm available for applying test patches to snapshot builds if GCC developers
aren't able to reproduce.

[Bug tree-optimization/46651] ICE with graphite enabled in cairo-1.8.10

[saellaven at gmail dot com]

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

--- Comment #5 from saellaven at gmail dot com 2010-11-26 21:10:50 UTC ---
(In reply to comment #4)
> Created attachment 22540 [details]
> preprocessed source without -march or -mtune
> 
> compiled with
> 
> ./doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I.
> -I/usr/include/pixman-1  -I/usr/include/freetype2  
> -I/usr/include/libpng14 -O2  -save-temps -ggdb
> -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity
> -finline-limit=1200 -MT cairo-cff-subset.lo -MD -MP -MF
> .deps/cairo-cff-subset.Tpo -c -o cairo-cff-subset.lo cairo-cff-subset.c

to clarify, I got the same error when compiling without native optimizations

cairo-cff-subset.c: In function 'cff_index_write':
cairo-cff-subset.c:313:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-26 21:01:09 UTC ---
(In reply to comment #1)
> Frontends and tree optimizers also use TYPE_SIZE_UNIT and DECL_SIZE_UNIT which
> is calculated by layout_type using target dependent BITS_PER_UNIT.

The use of TYPE_SIZE_UNIT / DECL_SIZE_UNIT is not a problem, because these
are tree fields.

stor-layout.c is not a frontend or tree optimizer.  A multi-target compiler
can work OK with stor-layout being part of the target dependent code, and
I believe so can a front-end plugin.

A back-end plugin would have to include its own version of stor-layout, or
otherwise stor-layout would have to be made entirely independent of target
macros.  But this not in the scope of this PR.

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[dodji at gcc dot gnu.org]

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

--- Comment #38 from Dodji Seketeli  2010-11-26 
20:58:09 UTC ---
Created attachment 22542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22542
A possible patch to kill pedantic warnings of macros defined in system headers

This patch builds on the infrastructure of the patchset we were talking about
earlier. It fixes the problem described in comment 2, 8 et al.

It is hopefully commented enough to explain what it does and how it does it.

[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-11-26 
19:49:58 UTC ---
Frontends and tree optimizers also use TYPE_SIZE_UNIT and DECL_SIZE_UNIT which
is calculated by layout_type using target dependent BITS_PER_UNIT.

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

[mschulze at ivs dot cs.ovgu.de]

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

Michael Schulze  changed:

   What|Removed |Added

 CC||mschulze at ivs dot
   ||cs.ovgu.de

--- Comment #7 from Michael Schulze  2010-11-26 
19:21:00 UTC ---
In my opinion this bug is still pending and not fixed. The proposed fix uses
register r20 but this could be clobbered by constructor that are called,
leading to destructing the exit condition of the __do_global_ctors loop. In new
version of gcc (see bug 45263 but still not confirmed) this is weakly fixed by
pushing and poping r20 around the constructor call.  

I would suggest using a register between r2-r17 instead of r20. According to
the compiler abi this should be a register that the called routine has to save
if it needs to use it.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-11-26 19:04:56 UTC ---
On Fri, 26 Nov 2010, burnus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584
> 
> --- Comment #2 from Tobias Burnus  2010-11-26 
> 08:04:50 UTC ---
> The test case quad_1.f90 does not always use quad precision (despite its name)
> but it uses the highest available floating point type. Depending on the system
> that can be the real kind 8 (64 bits), 10 (80 bits) or 16 (128 bits).
> 
> The FE does the following matching for a REAL type matching sizeof(float) ->
> "sinf", for double -> "sin", for long double -> "sinl", and for __float128 ->
> sinq.
> 
> Thus, on HPPA there seems to be a floating point type which is larger than
> "double" and which matches "long double" while __float128 does not seem to be
> available.
> 
> Hence, the issue seems to rather that we have found a C99 math function which
> is no implemented in HPUX: A long-double complex cosine (ccosl).
> There are some fall-back C99 functions implemented in libgfortran but 
> seemingly
> none of the complex trigonometric ones; cf.
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/c99_functions.c
> 
> The muddle over solution is to change the ccosl function to some other -
> possibly complex - long double function which is implemented - maybe csqrtl 
> is?
> 
> 
> > I have a patch that adds the hooks to build libquadmath on PA HP_UX 
> > targets. 
> > However, I'm not sure what's the best way to map the 'l' C99 builtins like
> > those below to the corresponding 'q' functions in the new library.
> 
> It is not completely clear what your patch is supposed to do. Seemingly PA has
> a hardware >(8 bytes)/double data type. I do not know whether long double is 
> 80
> bits long or 128 bits. If it is not 80 bits, you could consider adding
> __float128 - but if long double is already 128 bits, I do not see why one
> should do so.  If there is no 128 bit type, adding __float128 will
> automatically make a REAL(16) available, which will use libquadmath.

PA has hardware float and double.  The architecture has provision
for long double but this was never implemented in hardware.  HP-UX
has a software support for for basic arithmetic and compares using
long doubles.  However, there are now math routines of any kind.

The original testcase failure occured with the existing long double
support because of the lack of long double math routines (cosl, etc).

Given the recent addition of libquadmath, I thought it might be useful
to try and enable it.  Current patch to enable building libquadmath
is attached.  libquadmath appears to have built successfully on
hppa64-hp-hpux11.11 with this change.

I needed to add __float128 type and some builtins.  To do this, I
essentially copied stuff from ia64.  As things stand now, it seems
the fortran front end uses the 'l' math functions in preference to
the 'q' functions in libquadmath.

It appears the configure for libgfortran checks for the presence
of all the 'l' math functions.  However, it might be better to map
'l' to 'q' in a quadmath header, so libquadmath doesn't depend on
libgfortran (i.e., make it usable from C, etc).

Does this make sense?

Dave

[Bug other/46677] New: frontends and tree optimizers use *_TYPE_SIZE

[amylaar at gcc dot gnu.org]

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

   Summary: frontends and tree optimizers use *_TYPE_SIZE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46489


The frontends and tree optimizers use the *_TYPE_SIZE and POINTER_SIZE
target macros.

They should instead use to-be-created data members of targetm.

[Bug c++/44871] Invalid type mismatches while merging C and C++ sources

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com  2010-11-26 18:40:15 UTC ---
On Fri, 26 Nov 2010, rguenth at gcc dot gnu.org wrote:

> I'd like to hear opinions from C and C++ FE people as to why the current
> state illustrated in comment #6 makes sense and if the behavior can be
> commonized between C and C++.

C++ has special rules about using typedefs for anonymous structure types 
for linkage purposes.  C has no such rules.  Thus, for C you can have

typedef struct { int a; } T1;
void f(T1);

in one translation unit and

typedef struct { int a; } T2;
void f(T2);

in another and they refer to the same function (cross-translation-unit 
struct compatibility rules apply) - for C++ they do not (and are mangled 
differently).

[Bug target/46623] microblaze --enable-werror-always build fails

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-26 17:42:10 UTC ---
Patch has been applied to trunk.

[Bug target/46623] microblaze --enable-werror-always build fails

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-11-26 17:38:24 UTC ---
Author: amylaar
Date: Fri Nov 26 17:38:20 2010
New Revision: 167186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167186
Log:
PR target/46623
* config/microblaze/microblaze.c (microblaze_block_move_straight):
Use XALLOCAVEC.
(microblaze_option_override): Don't use C++ style comments.
(save_restore_insns): Remove unused variable base_offset.
(microblaze_expand_prologue): Remove unused variable insn.
(microblaze_secondary_reload): Adjust type to match target.h .
(microblaze_elf_in_small_data_p): Move declarations to start of block.
(microblaze_expand_move): Likewise.
* config/microblaze/microblaze.h (LARGE_INT):
Avoid signed / unsigned comparisons.
(ASM_OUTPUT_ALIGNED_COMMON, ASM_OUTPUT_ALIGNED_LOCAL): Likewise.
(ASM_FORMAT_PRIVATE_NAME): Make format specifier match printed data.
(ASM_FINISH_DECLARE_OBJECT): Likewise.  Constify name.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/microblaze/microblaze.c
trunk/gcc/config/microblaze/microblaze.h

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2010-11-26 
17:37:33 UTC ---
There are lots of ways to put your program into an invalid state.

Of course there's "no point" to doing it, and noone's asking for the code to
*work*

The question is whether the compiler is expected to diagnose the code and
reject it.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #58 from Jakub Jelinek  2010-11-26 
17:34:23 UTC ---
At least in my cross it seems the r166947 commit just changed default tuning
for -m64, from -mtune=power4 to -mtune=rs64.  Not sure if it was intentional or
not.  Anyway, with explicit -mtune=power4 the result is exactly the same as
before without any tuning options (and with -mtune=rs64 before is the same as
now without any tuning options).

[Bug bootstrap/46650] r167010 breaks --enable-build-with-cxx

[howarth at nitro dot med.uc.edu]

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

--- Comment #5 from Jack Howarth  2010-11-26 
17:28:08 UTC ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02567.html and
tested at http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg02099.html.

[Bug tree-optimization/46651] ICE with graphite enabled in cairo-1.8.10

[saellaven at gmail dot com]

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

--- Comment #4 from saellaven at gmail dot com 2010-11-26 17:20:44 UTC ---
Created attachment 22540
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22540
preprocessed source without -march or -mtune

compiled with

./doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I.
-I/usr/include/pixman-1  -I/usr/include/freetype2  
-I/usr/include/libpng14 -O2  -save-temps -ggdb
-floop-interchange -floop-strip-mine -floop-block -fgraphite-identity
-finline-limit=1200 -MT cairo-cff-subset.lo -MD -MP -MF
.deps/cairo-cff-subset.Tpo -c -o cairo-cff-subset.lo cairo-cff-subset.c

[Bug target/46676] New: ix86_option_override_internal i18n problems

[jsm28 at gcc dot gnu.org]

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

   Summary: ix86_option_override_internal i18n problems
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org
Blocks: 40883
Target: i?86-*-* x86_64-*-*


ix86_option_override_internal contains code

  /* Set up prefix/suffix so the error messages refer to either the command
 line argument, or the attribute(target).  */
  if (main_args_p)
{
  prefix = "-m";
  suffix = "";
  sw = "switch";
}
  else
{
  prefix = "option(\"";
  suffix = "\")";
  sw = "attribute";
}

and later diagnostics inserting sw - the word "switch" or "attribute" - with
%s.  This should use separate diagnostic strings for the two cases instead. 
(Also, the attribute is "target" not "option".)

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[pentek.imre at gmail dot com]

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

--- Comment #12 from Imre Pentek  2010-11-26 
17:18:26 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #2)
> > > > int &a = a;
> > > > i don't believe this is valid code.  i believe g++ should reject the 
> > > > code.
> > > 
> > > I'm not convinced the compiler must reject it. EDG accepts it too.
> > 
> > Without warning? What about clang 2.8?
> 
> Yes, without warning (G++ at least warns)
> I don't know about clang

This code is as valid as unset references are valid. The standards doesn't
allow 'unset' or 'extremal' references. In this way there's no point to query
the reference from a yet-unset reference, as there's no such a state as unset
reference. If you somehow manage to query the reference from an unset reference
you actually navigated your compiler to a state which doesn't even exist. It's
like division by zero to be accepted without any (runtime/compiletime) error
messages/crashes. Briefly, I consider this code as invalid, as it generates a
state which is invalid, and has no semantic meaning, and doesn't really exist.

[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

Summary|[4.6 Regression]|[4.6 Regression]
   |-freorder-blocks-and-partit |-freorder-blocks-and-partit
   |ion -g failed   |ion -g failed and libstdc++
   ||builds for arm-eabi are
   ||broken.

--- Comment #4 from Ramana Radhakrishnan  2010-11-26 
17:07:54 UTC ---
arm-eabi builds for libstdc++ are still broken. ARM doesn't use
freorder-blocks-and-partition by default thus it's probably more generic than
that ! 

So saying freorder-blocks-and-partition is the only thing broken isn't correct.

Ramana

[Bug c++/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Guenther  2010-11-26 
17:06:25 UTC ---
Testcase:

> cat gcc/testsuite/g++.dg/lto/20101126-1_0.C
typedef struct { int i; } T1;
typedef T1 T2;
extern T1 a;
extern T2 b;
int main() { return a.i + b.i; }

> cat gcc/testsuite/g++.dg/lto/20101126-1_1.c
typedef struct { int i; } T1;
typedef T1 T2;
T1 a;
T2 b;

/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/lto/20101126-1_0.C:3:11:
warning: type of 'a' does not match original declaration [enabled by default]^M
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/lto/20101126-1_1.c:3:4:
note: previously declared here^M
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/lto/20101126-1_0.C:4:11:
warning: type of 'b' does not match original declaration [enabled by default]^M
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/lto/20101126-1_1.c:4:4:
note: previously declared here^M

(gdb) call debug_tree (prevailing->decl)
 
unit size 
align 32 symtab 0 alias set -1 structural equality
fields 
nonlocal SI file t4.ii line 1 col 22 size  unit size 
align 32 offset_align 128
offset 
bit offset  context
>>
public static SI file t4.ii line 3 col 4 size  unit size 
align 32 context >
(gdb) call debug_tree (decl)
 
unit size 
align 32 symtab 0 alias set -1 structural equality
fields 
SI file t3.i line 1 col 22 size 
unit size 
align 32 offset_align 128
offset 
bit offset  context
>>
used public external common SI file t3.i line 3 col 11 size  unit size 
align 32 context >


if we want to have the same canonical type for the above we can simply
disregard all names, which makes sense for canonical type merging, but
that makes the hash functions very weak again (we share the type hashes
for type and canonical type merging).  It also can run foul of too much
merging when facing incomplete types which can happen in various places.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

--- Comment #57 from Dominique d'Humieres  
2010-11-26 16:54:08 UTC ---
> That is an unimportant difference.  It is fine if a different uid is used, as
> long as it used consistently through the whole source.

I understand, but it make the diff of ~200 files impractical.

> You can -fdump-tree-all-nouid and -fdump-rtl-all-nouid alternatively and look
> for differences in that case.

Then I can go a little further to

diff 166946/where_2.f90.025t.ealias 166947/where_2.f90.025t.ealias
23,24c23,24
< D.1218_25 = S.0_1
< D.1218_25 = &NONLOCAL
---
> D.1216_25 = S.0_1
> D.1216_25 = &NONLOCAL
...

diff 166946/where_2.f90.191r.sched1 166947/where_2.f90.191r.sched1
16c16
< ;;  0-->19 r440=0   
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;  0-->19 r440=0:iu1_6xx|iu2_6xx
20c20
< ;;  1-->47 [sfp+0x54]=r440#3 :ppc750_du,lsu_7xx
---
> ;;  1-->47 [sfp+0x54]=r440#3 :lsu_6xx
24c24
< ;;  2--> 9 r435=0xa 
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;  2--> 9 r435=0xa  :iu1_6xx|iu2_6xx
28c28
< ;;  3-->99 r885=[sfp+0x54]   :ppc750_du,lsu_7xx
---
> ;;  3-->13 r437=0x   :iu1_6xx|iu2_6xx
32c32
< ;;  4-->13 r437=0x  
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;  4-->99 r885=[sfp+0x54]   :lsu_6xx
36c36
< ;;  5-->   101 {r485=cmp(zxn(r885),0);clobber
scr:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;  5-->68 r470=0x64 :iu1_6xx|iu2_6xx
40c40
< ;;  6-->68 r470=0x64
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;  6-->   101 {r485=cmp(zxn(r885),0);clobber scr:iu1_6xx|iu2_6xx
...

2697c2697
< (insn 9 47 99 2 (set (reg:SI 435)
---
> (insn 9 47 13 2 (set (reg:SI 435)
2701c2701,2705
< (insn 99 9 13 2 (set (reg:QI 885 [ temp.5+4 ])
---
> (insn 13 9 99 2 (set (reg:SI 437)
> (const_int -1 [0x])) ../where_2.f90:6 353 
> {*movsi_internal1}
>  (nil))
> 
> (insn 99 13 68 2 (set (reg:QI 885 [ temp.5+4 ])
2706,2707c2710,2711
< (insn 13 99 101 2 (set (reg:SI 437)
< (const_int -1 [0x])) ../where_2.f90:6 353
{*movsi_internal1}
---
> (insn 68 99 101 2 (set (reg:SI 470)
> (const_int 100 [0x64])) ../where_2.f90:11 353 {*movsi_internal1}
2710c2714
< (insn 101 13 68 2 (parallel [
---
> (insn 101 68 5 2 (parallel [
2718,2722c2722
< (insn 68 101 5 2 (set (reg:SI 470)
< (const_int 100 [0x64])) ../where_2.f90:11 353 {*movsi_internal1}
<  (nil))
< 
< (insn 5 68 25 2 (set (reg:V4SI 433)
---
> (insn 5 101 25 2 (set (reg:V4SI 433)
3189c3189
< (insn 160 879 181 14 (set (reg:SI 243 [ mask.16+-3 ])
---
> (insn 160 879 161 14 (set (reg:SI 243 [ mask.16+-3 ])
3195c3195,3203
< (insn 181 160 195 14 (set (reg:SI 893 [ reduce+8 ])
---
> (insn 161 160 181 14 (parallel [
> (set (reg:SI 513)
> (and:SI (reg:SI 241 [ cond.15+-3 ])
> (reg:SI 243 [ mask.16+-3 ])))
> (clobber (scratch:CC))
> ]) ../where_2.f90:11 161 {andsi3_mc}
>  (nil))
> 
> (insn 181 161 195 14 (set (reg:SI 893 [ reduce+8 ])
3230c3238
< (insn 279 265 161 14 (set (reg:SI 871 [ reduce+36 ])
---
> (insn 279 265 295 14 (set (reg:SI 871 [ reduce+36 ])
3235,3241c3243,3247
< (insn 161 279 880 14 (parallel [
< (set (reg:SI 513)
< (and:SI (reg:SI 241 [ cond.15+-3 ])
< (reg:SI 243 [ mask.16+-3 ])))
< (clobber (scratch:CC))
< ]) ../where_2.f90:11 161 {andsi3_mc}
<  (nil))
---
> (insn 295 279 880 14 (set (reg:CC 609)
> (compare:CC (reg:SI 513)
> (const_int 0 [0]))) ../where_2.f90:11 451 {*cmpsi_internal1}
>  (expr_list:REG_DEAD (reg:SI 513)
> (nil)))
...

[Bug c++/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2010-11-26 
16:29:53 UTC ---
I'd like to hear opinions from C and C++ FE people as to why the current
state illustrated in comment #6 makes sense and if the behavior can be
commonized between C and C++.

I might be that the current difference in behavior is mandated by some
standards.

We can now also fix this in LTO by making sure we at least get the
same TYPE_CANONICAL.  I will try to look at how difficult that would
be.

[Bug lto/44865] Compiling a single file with -O3 -march=pentium4 -flto ICEs

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2010-11-26 
16:23:17 UTC ---
I can't reproduce this anymore, it has been likely fixed.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #56 from Jakub Jelinek  2010-11-26 
16:20:18 UTC ---
That is an unimportant difference.  It is fine if a different uid is used, as
long as it used consistently through the whole source.
You can -fdump-tree-all-nouid and -fdump-rtl-all-nouid alternatively and look
for differences in that case.

[Bug lto/46648] [4.6 Regression] type mismatch in array reference; verify_stmts failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2010-11-26 
16:14:13 UTC ---
Fixed.

[Bug lto/46648] [4.6 Regression] type mismatch in array reference; verify_stmts failed

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-11-26 
16:12:57 UTC ---
Author: rguenth
Date: Fri Nov 26 16:12:49 2010
New Revision: 167183

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167183
Log:
2010-11-26  Richard Guenther  

PR lto/46648
* gimple.c (gtc_visit): Do not return true for members of an
SCC still being processed but the current lattice value of
the member.  Treat SCC members comparison state as lattice,
starting at equal, eventually dropping to unequal.
(gimple_types_compatible_p_1): Likewise.

* gcc.dg/lto/20101125-1_0.c: New testcase.
* gcc.dg/lto/20101125-1_1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20101125-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20101125-1_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/46651] ICE with graphite enabled in cairo-1.8.10

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.11.26 16:08:02
 Ever Confirmed|0   |1

--- Comment #3 from H.J. Lu  2010-11-26 16:08:02 
UTC ---
Please don't use "-march=native -mtune=native" when
reporting bugs since we have no idea what they are.

[Bug middle-end/46559] libstdc++ link FAILs with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2010-11-26 
16:01:47 UTC ---
Fixed.

[Bug middle-end/46559] libstdc++ link FAILs with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-11-26 
16:01:33 UTC ---
Author: rguenth
Date: Fri Nov 26 16:01:26 2010
New Revision: 167181

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167181
Log:
2010-11-26  Richard Guenther  

PR middle-end/46559
* dwarf2out.c (dwarf2out_finish): Use comp_unit_die as root
for location list processing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%ppc()

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.26 16:01:20
 Ever Confirmed|0   |1

--- Comment #5 from Tobias Burnus  2010-11-26 
16:01:20 UTC ---
(In reply to comment #4)
> While gfortran rejects TBP, it accepts PPC (proc pointer components)
>
>   CALL polymorphic%abstract_type%PPC()

To make it a bit clearer:

R1221 procedure-designator is ... or proc-component-ref or ...
R739  proc-component-ref is scalar-variable % procedure-component-name

where "variable" can be a "designator" which can be a "structure-component"
which is a "data-ref". Thus, we are back at C611 which tells that the
right-most part-ref (here: "abstract-type") must not be both abstract and
not-polymorphic.


For TBP the check is done in resolve.c's check_typebound_baseobject; for PPC
the check should be added at update_ppc_arglist -- few lines up.

[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Component|regression  |middle-end
   Target Milestone|--- |4.6.0
Summary|Target arm-unknown-eabi |[4.6 Regression]
   |build results in "causes a  |-freorder-blocks-and-partit
   |section type conflict"  |ion -g failed
   |error in libstdc++  |

--- Comment #3 from H.J. Lu  2010-11-26 15:55:22 
UTC ---
It is caused by revision 167085:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00974.html

[Bug target/43897] [4.4/4.5/4.6 Regression] IA-64 asm clobbers are ignored

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-11-26 
15:51:50 UTC ---
Created attachment 22539
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22539
gcc46-pr43897.patch

So something like this?  Completely untested, appart from the testcase (with a
cross).

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

--- Comment #55 from Dominique d'Humieres  
2010-11-26 15:48:44 UTC ---
> Perhaps try to build with r166946 and r166947 the testcase with 
> -fdump-tree-all
> -fdump-rtl-all, see where the dumps start diverging and what is the difference
> between assembly outputs?

First difference is the following!-(

diff 166946/0/where_2.f90.003t.original 166947/0/where_2.f90.003t.original
183c183
<   integer(kind=4) D.1181;
---
>   integer(kind=4) D.1179;
199c199
<   D.1181 = val.27;
---
>   D.1179 = val.27;
209c209
< temp[S.29 + -1] = temp[S.29 + -1] + D.1181;
---
> temp[S.29 + -1] = temp[S.29 + -1] + D.1179;

How am I supposed to go further?

[Bug c++/46670] ICE with 4.6.0 2010-11-26 with c++0x, in TBB's header

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2010-11-26 15:46:03 
UTC ---
[...@gnu-35 delta]$ cat testcase.cc
extern unsigned char __TBB_ReverseByte(unsigned char src);
extern unsigned char *reversed;
template T __TBB_ReverseBits(T src)
{
  unsigned char *original = (unsigned char *) &src;
  for( int i = sizeof(T)-1; i--; )
reversed[i] = __TBB_ReverseByte( original[sizeof(T)-i-1] );
}
[...@gnu-35 delta]$ /export/gnu/import/rrs/166167/usr/bin/gcc -std=c++0x -S
testcase.cc
testcase.cc: In function \u2018T __TBB_ReverseBits(T)\u2019:
testcase.cc:7:62: internal compiler error: in dependent_type_p, at
cp/pt.c:17553
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-35 delta]$

[Bug target/46481] long double should default to 64bit even for aix6.1

[michael.haubenwallner at salomon dot at]

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

Michael Haubenwallner  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix6.1.0.0
Version|4.2.4   |4.5.1
 Depends on||19115

--- Comment #1 from Michael Haubenwallner  2010-11-26 15:41:40 UTC ---
This is the same problem for any version since gcc-4.2.4.

[Bug middle-end/46675] [4.6 Regression] profiledbootstrap failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug c++/46670] ICE with 4.6.0 2010-11-26 with c++0x, in TBB's header

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.26 15:32:56
 CC||jason at redhat dot com
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-11-26 15:32:56 
UTC ---
It is caused by revision 166167:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html

[Bug c++/36478] [4.3 regression] warning not emitted when code expanded from macro

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Dodji Seketeli  2010-11-26 
15:29:59 UTC ---
Fixed in 4.4+ only as the -Wempty-body patch was reverted.

The underlying problem can be tracked by PR7263.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #54 from Jakub Jelinek  2010-11-26 
15:20:37 UTC ---
Perhaps try to build with r166946 and r166947 the testcase with -fdump-tree-all
-fdump-rtl-all, see where the dumps start diverging and what is the difference
between assembly outputs?

[Bug rtl-optimization/46665] two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  2010-11-26 
15:14:27 UTC ---
Author: hjl
Date: Fri Nov 26 15:14:20 2010
New Revision: 167179

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167179
Log:
Add a testcase for PR tree-optimization/46665.

2010-11-26  H.J. Lu  

PR tree-optimization/46665
* gfortran.dg/pr46665.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/pr46665.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/46559] libstdc++ link FAILs with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-11-26 
15:09:34 UTC ---
The FAILs also occur with -flto-partition=none.

Hm, looking at 27_io/basic_filebuf/underflow/10096.cc there are no location
lists at all in the LTO assembler:

.section.debug_loc,"",@progbits
.Ldebug_loc0:


dwarf2out.c:output_loc_list is never called, add_AT_loc_list is, so is
output_location_lists.

But the local var 'die' that is refered is the last in the limbo_die_list.
Do we expect this magically to be comp_unit_die?  For the testcase
in question it is a DW_TAG_structure_type.  With multiple comp-unit dies
as we now can have with LTO do we need to iterate through them for
the remaining parts of dwarf2out after limbo-die processing?

Well.

Index: dwarf2out.c
===
--- dwarf2out.c (revision 167177)
+++ dwarf2out.c (working copy)
@@ -23177,7 +23176,7 @@ dwarf2out_finish (const char *filename)
 add_AT_macptr (comp_unit_die (), DW_AT_macro_info, macinfo_section_label);

   if (have_location_lists)
-optimize_location_lists (die);
+optimize_location_lists (comp_unit_die ());

   /* Output all of the compilation units.  We put the main one last so that
  the offsets are available to output_pubnames.  */
@@ -23222,7 +23221,7 @@ dwarf2out_finish (const char *filename)
   ASM_GENERATE_INTERNAL_LABEL (loc_section_label,
   DEBUG_LOC_SECTION_LABEL, 0);
   ASM_OUTPUT_LABEL (asm_out_file, loc_section_label);
-  output_location_lists (die);
+  output_location_lists (comp_unit_die ());
 }

   /* Output public names table if necessary.  */

fixes this bug and makes sense anyway.

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[dodji at gcc dot gnu.org]

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

--- Comment #37 from Dodji Seketeli  2010-11-26 
15:08:34 UTC ---
"manu at gcc dot gnu.org"  writes:
> Awesome!

:-) thank you for caring.

> I still think that the output would be better if it was more consistent with
> the current way of printing template instantiations, that is, using "note:
> while expanding macro..." after the error/warning. If you look to the code for
> printing the instantiations of templates, you'll see that it also handles long
> nested templates and recursive templates. Perhaps the same code/algorithm 
> could
> be used for printing this to avoid such problems.

Yes, I think so too. I will try to do that.

> In any case, you should seek comments from the decision-makers at 
> gcc-patches@,
> not me, because whatever they want is what is going to be implemented.

Sure, I will do that eventually.

By the way, I started working on fixing the bug mentioned in
comments 2, 8, 10, 11, 12, 13. Now we seem to have the infrastructure to
do so. I will come up with a patch to fix this specifically, on top of
the patcheset of this PR.

Maybe I need a separate PR, I don't know.

[Bug middle-end/46675] New: [4.6 Regression] profiledbootstrap failed

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] profiledbootstrap failed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 167173 gave

libtool: compile:  /export/gnu/import/svn/gcc-test-profile/bld/./gcc/gcj
-B/export/gnu/import/svn/gcc-test-profile/bld/x86_64-unknown-linux-gnu/32/libjava/
-B/export/gnu/import/svn/gcc-test-profile/bld/x86_64-unknown-linux-gnu/32/libjava/
-B/export/gnu/import/svn/gcc-test-profile/bld/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -ffloat-store
-fomit-frame-pointer -fclasspath=
-fbootclasspath=../../../../src-trunk/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -m32
-fsource-filename=/export/gnu/import/svn/gcc-test-profile/bld/x86_64-unknown-linux-gnu/32/libjava/classpath/lib/classes
-fjni -findirect-dispatch -fno-indirect-classes -c
@gnu-java-awt-dnd-peer-gtk.list -o gnu-java-awt-dnd-peer-gtk.o >/dev/null 2>&1
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
In class 'gnu.java.awt.peer.gtk.GtkComponentPeer':
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
In method
'gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(java.awt.AWTEvent)':
In file included from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GdkPixbufDecoder.java:260:0,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:457,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkMenuBarPeer.java:112,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkPopupMenuPeer.java:67,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkTextFieldPeer.java:198,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkMouseInfoPeer.java:63,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/AsyncImage.java:281,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkChoicePeer.java:141,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkWindowPeer.java:436,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkMenuPeer.java:125,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkMenuItemPeer.java:115,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkClipboard.java:423,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GdkScreenGraphicsDevice.java:357,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GdkScreenGraphicsDevice.java:284,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkContainerPeer.java:137,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/ComponentGraphics.java:940,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkLabelPeer.java:100,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GdkGraphicsEnvironment.java:170,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GdkPixbufDecoder.java:404,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkListPeer.java:186,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkSelection.java:656,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkCanvasPeer.java:58,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkGenericPeer.java:144,
from
/export/gnu/import/svn/gcc-test-profile/src-trunk/libjava/classpath/gnu/java/awt/peer/gtk/GdkRobotPeer.java:98,
from
/export/gnu/impo

[Bug tree-optimization/46560] libstdc++ execute FAILs with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2010-11-26 
14:40:22 UTC ---
All fixed.  Yay.

[Bug tree-optimization/46560] libstdc++ execute FAILs with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-11-26 
14:39:31 UTC ---
Author: rguenth
Date: Fri Nov 26 14:39:25 2010
New Revision: 167178

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167178
Log:
2010-11-26  Richard Guenther  

PR lto/46560
* cgraph.c (cgraph_clone_edge): Clone call_stmt dependent
flags manually.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Guenther  2010-11-26 
14:36:02 UTC ---
(In reply to comment #20)
> On Fri, 26 Nov 2010, Joost.VandeVondele at pci dot uzh.ch wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
> > 
> > --- Comment #19 from Joost VandeVondele  > uzh.ch> 2010-11-26 13:39:00 UTC ---
> > Tobias, thanks for the clean explanation. I overlooked that the target of a
> > pointer has that target attribute (seems logical!).
> > 
> > Richard, I tried to get to a testcase for which the ME generates wrong code,
> > but somehow things are always 'right'. I was expecting this to fail (-O3
> > -fno-inline), since the ME should not now that X aliases with V1%D:
> > 
> > MODULE M1
> >  IMPLICIT NONE
> >  TYPE T1
> >REAL, DIMENSION(:), ALLOCATABLE :: D
> >  END TYPE T1
> > CONTAINS
> >  SUBROUTINE S1(V1)
> >TYPE(T1), POINTER :: V1
> 
> We can't exploit restrict information for pointers, it would need to
> be a var of type t1 with target attribute - but even then the double
> indirection (v1 passed by reference, embedded array desc points to
> data) prevents us from exploiting restrict info.
> 
> So we might be safe for now (apart from the related ICE seen with lto).

Actually we _can_ see the restrict, but only with -fipa-pta which then
also sees the pointer association (even with -fno-inline) which then
makes the alias visible again (so we ignore restrict, maybe by pure luck
of course):

  D.1625_4 = *v1_2(D);
  # PT = nonlocal unit-escaped null { D.1644 D.1645 } (restr)
  D.1626_5 = D.1625_4->d.data;

  # PT = nonlocal unit-escaped null { D.1644 D.1645 } (restr)
  D.1630_10 = x.data;

wonders of propagation ;)

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  
2010-11-26 14:29:41 UTC ---
On Fri, 26 Nov 2010, Joost.VandeVondele at pci dot uzh.ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
> 
> --- Comment #19 from Joost VandeVondele  uzh.ch> 2010-11-26 13:39:00 UTC ---
> Tobias, thanks for the clean explanation. I overlooked that the target of a
> pointer has that target attribute (seems logical!).
> 
> Richard, I tried to get to a testcase for which the ME generates wrong code,
> but somehow things are always 'right'. I was expecting this to fail (-O3
> -fno-inline), since the ME should not now that X aliases with V1%D:
> 
> MODULE M1
>  IMPLICIT NONE
>  TYPE T1
>REAL, DIMENSION(:), ALLOCATABLE :: D
>  END TYPE T1
> CONTAINS
>  SUBROUTINE S1(V1)
>TYPE(T1), POINTER :: V1

We can't exploit restrict information for pointers, it would need to
be a var of type t1 with target attribute - but even then the double
indirection (v1 passed by reference, embedded array desc points to
data) prevents us from exploiting restrict info.

So we might be safe for now (apart from the related ICE seen with lto).

>REAL, DIMENSION(:), POINTER :: X
>INTEGER :: I
>CALL PA(V1,X)
>DO i=1,4
>   V1%D(i)=1
>   X(i)=2
>   V1%D(i)=2*V1%D(i)
>ENDDO
>  END SUBROUTINE S1
>  SUBROUTINE PA(V1,X)
>TYPE(T1), POINTER :: V1
>REAL, DIMENSION(:), POINTER :: X
>X=>V1%D
>  END SUBROUTINE
> END MODULE M1
> 
> USE M1
> IMPLICIT NONE
> TYPE(T1), POINTER :: V1
> INTEGER :: i
> ALLOCATE(V1)
> ALLOCATE(V1%D(4))
> V1%D=(/(i,i=1,4)/)
> CALL S1(V1)
> IF (ANY(V1%D.NE.4)) STOP "BUG"
> write(6,*) "ALL IS FINE"
> END
> 
>

[Bug rtl-optimization/46665] two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #5 from Richard Guenther  2010-11-26 
14:05:53 UTC ---
Fixed.

[Bug rtl-optimization/46665] two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2010-11-26 
14:04:55 UTC ---
Author: rguenth
Date: Fri Nov 26 14:04:50 2010
New Revision: 167176

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167176
Log:
2010-11-26  Richard Guenther  

PR tree-optimization/46665
* tree-ssa-structalias.c (pt_solution_set_var): Use DECL_PT_UID.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%ppc()

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
Summary|[OOP] gfortran rejects  |[OOP] gfortran rejects
   |CALL|CALL
   |polymorphic%abstract_type%t |polymorphic%abstract_type%p
   |bp()|pc()

--- Comment #4 from Tobias Burnus  2010-11-26 
14:02:41 UTC ---
REOPEN:

As Wolfgang Kilian mentions in the c.l.f thread (cf. link in comment 0):
While gfortran rejects TBP, it accepts PPC (proc pointer components)

  CALL polymorphic%abstract_type%PPC()

The same arguments should hold for those, which means that they should be
rejected.

[Bug tree-optimization/46560] libstdc++ execute FAILs with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-11-26 
14:02:28 UTC ---
FAIL: 21_strings/basic_string/insert/char/1.cc execution test

is because we optimize away EH code.  A stripped-down testcase shows instead
of

Eh tree:
   3 cleanup land:{3,}
 6 cleanup
   7 cleanup land:{5,}
 11 try land:{7,} catch:{struct out_of_range},{}
 8 try land:{6,} catch:{struct out_of_range},{}

Eh tree:
   3 cleanup land:{3,}
 6 cleanup
   7 cleanup land:{5,}
 8 try land:{6,} catch:{(void *) &_ZTISt12out_of_range},{}

it's already broken at .044i.inline - one insert call doesn't have eh info.

I suspect that nothrow discovery is broken somehow.

Function found to be nothrow: insert
insert/19(-1) @0x75d1fdc0 (asm: _ZNSs6insertEmRKSsmm) (inline copy in
test01/5) (clone of insert/0) availability:local analyzed 29 time, 20 benefit
25 size, 12 benefit reachable local finalized inlinable
  called by: test01/5 (1.00 per call) (inlined)
  calls: __throw_out_of_range/8 insert/7 (1.00 per call)
  References:
  Refering this function:

but we have before propagate nothrow:

insert/19(-1) @0x75d1fdc0 (asm: _ZNSs6insertEmRKSsmm) (inline copy in
test01/5) (clone of insert/0) availability:local analyzed 29 time, 20 benefit
25 size, 12 benefit reachable local finalized inlinable
  called by: test01/5 (1.00 per call) (inlined)
  calls: __throw_out_of_range/8 insert/7 (1.00 per call)
  References:
  Refering this function:

__throw_out_of_range/8(-1) @0x75d1ec60 (asm: _ZSt20__throw_out_of_rangePKc)
availability:not_available reachable
  called by: insert/19 insert/0 (can throw external)
  calls:
  References:
  Refering this function:

insert/0(-1) @0x75d1e160 (asm: _ZNSs6insertEmRKSsmm) availability:available
analyzed 29 time, 20 benefit 25 size, 12 benefit reachable finalized inlinable
  called by: test01/5
  calls: insert/7 (1.00 per call) (can throw external) __throw_out_of_range/8
(can throw external)
  References:
  Refering this function:

so __throw_out_of_range/8 can throw.

During propagation visiting insert/19 we visit the edge to
__throw_out_of_range.
The edge has e->can_throw_external == 0, probably because:

  edge->can_throw_external
= call_stmt ? stmt_can_throw_external (call_stmt) : false;

in cgraph.c which isn't exactly a conservative assumption.

(gdb) p e
$13 = (struct cgraph_edge *) 0x75d20548
(gdb) p e->caller
$14 = (struct cgraph_node *) 0x75d1fdc0
(gdb) p e->callee
$15 = (struct cgraph_node *) 0x75d1ec60

which is an inline clone edge.  I suppose cgraph_clone_edge should clone
the flags that depend on call_stmt as well.

That fixes it.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

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

--- Comment #4 from Michael Haubenwallner  2010-11-26 13:54:41 UTC ---
Created attachment 22538
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22538
Workaround to emit .line values >0 and <64k only

For now, I'm using this patch to get the debug-info working good enough for me.
However, I don't believe this is the proper fix.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2010-11-26 
13:45:31 UTC ---
(In reply to comment #3)
> Same problem on SPARC/Solaris 8 and 9 (but not 10).  SPARC has quad precision
> floating point support but Solaris 8 and 9 aren't C99; only Solaris 10 is.

There is a simple solution: Simply not using a C99 long double math function
... That won't test complex libquadmath functions anymore, but one can defer
that to a libquadmath testsuite, if needed.

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #19 from Joost VandeVondele  
2010-11-26 13:39:00 UTC ---
Tobias, thanks for the clean explanation. I overlooked that the target of a
pointer has that target attribute (seems logical!).

Richard, I tried to get to a testcase for which the ME generates wrong code,
but somehow things are always 'right'. I was expecting this to fail (-O3
-fno-inline), since the ME should not now that X aliases with V1%D:

MODULE M1
 IMPLICIT NONE
 TYPE T1
   REAL, DIMENSION(:), ALLOCATABLE :: D
 END TYPE T1
CONTAINS
 SUBROUTINE S1(V1)
   TYPE(T1), POINTER :: V1
   REAL, DIMENSION(:), POINTER :: X
   INTEGER :: I
   CALL PA(V1,X)
   DO i=1,4
  V1%D(i)=1
  X(i)=2
  V1%D(i)=2*V1%D(i)
   ENDDO
 END SUBROUTINE S1
 SUBROUTINE PA(V1,X)
   TYPE(T1), POINTER :: V1
   REAL, DIMENSION(:), POINTER :: X
   X=>V1%D
 END SUBROUTINE
END MODULE M1

USE M1
IMPLICIT NONE
TYPE(T1), POINTER :: V1
INTEGER :: i
ALLOCATE(V1)
ALLOCATE(V1%D(4))
V1%D=(/(i,i=1,4)/)
CALL S1(V1)
IF (ANY(V1%D.NE.4)) STOP "BUG"
write(6,*) "ALL IS FINE"
END

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #18 from Tobias Burnus  2010-11-26 
13:23:59 UTC ---
(In reply to comment #13)
> Ugh.  That might be terrible.  Can you point to some language in the standard
> supporting that (I haven't looked myself and am not too fluent in the fortran
> standard).

(All relative to Fortran 2008,
ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf)

"5.3.17 TARGET attribute"
[...]
"If an object has the TARGET attribute, then all of its nonpointer subobjects
also have the TARGET attribute."

The pointer part probably enters indirectly: Assume in "a%b%p%d", "p" is the
pointer than "a%b%p%d" denotes the "d" components of the target to which
"a%b%p" points to. Per construction the target of the pointer has the TARGET
attribute - and "d" has it via the rule above.


Note, however, that the TARGET issue is local. Example:

type t
  integer :: i
end type t
type(t) :: a
integer, pointer :: ptr

call sub(a)
ptr = 7 ! Invalid, ptr has unknown association
! status as "a" is not a TARGET

contains

  subroutine sub(x)
type(a), TARGET :: x
ptr => x%i ! OK, x and thus x%i is a TARGET
ptr = 5
  end subroutine
end

Reason: "If the dummy argument has the TARGET attribute and the effective
argument does not have the TARGET attribute [...], any pointers associated with
the dummy argument become undefined when execution of the procedure completes."
(Cf. "12.5.2.4 Ordinary dummy variables".)

See also: "16.5.2.5 Events that cause the association status of pointers to
become undefined".


(In reply to comment #15)
> You then need to make sure to create variant types of aggregates with the
> target attribute applied to all subtypes (thus, the restrict stuff removed)
> as the middle-end doesn't know about this rule.

Yes, that sounds sensible - even though it will be a lot of work and requires
quite some book keeping :-(

That's somehow the curse of -fwhole-file: Now the decls are sensible enough
that the ME has plenty of opportunities to exploit all the wrong decl the FE
generates...


(In reply to comment #16)
> I think this implies this bug depends in somehow on PR45777.

Maybe. One operates on gfc_expr level - the other on tree level; however, both
are about the same issue. I assume they independent of each other.

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2010-11-26 
12:49:39 UTC ---
(In reply to comment #16)
> I think this implies this bug depends in somehow on PR45777.

Yes indeed - that bug looks very much related.

[Bug lto/46664] Failed to build 481.wrf in SPEC CPU 2006 with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #5 from Richard Guenther  2010-11-26 
12:43:30 UTC ---
Fixed for 4.6.

[Bug lto/46664] Failed to build 481.wrf in SPEC CPU 2006 with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2010-11-26 
12:42:47 UTC ---
Author: rguenth
Date: Fri Nov 26 12:42:41 2010
New Revision: 167173

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167173
Log:
2010-11-26  Richard Guenther  

PR tree-optimization/46664
* tree-affine.c (aff_combination_to_tree): Add rest last.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-affine.c

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[Joost.VandeVondele at pci dot uzh.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Depends on||45777

--- Comment #16 from Joost VandeVondele  
2010-11-26 12:28:20 UTC ---
I think this implies this bug depends in somehow on PR45777.

[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.26 12:22:56
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|Weak alias is mistakenly|[4.6 Regression] Weak alias
   |optimized away  |is mistakenly optimized
   ||away
 Ever Confirmed|0   |1

[Bug rtl-optimization/46665] two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-11-26 
12:19:54 UTC ---
The -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop failure goes away
with -fno-schedule-insns2.

restrict support really depends on CCP and CSE, -fipa-pta doesn't
recompute it after CSE.  But there isn't anything obviously wrong
in the .optimized alias info.

Fails with -fdbg-cnt=sched_insn:218, ok with -fdbg-cnt=sched_insn:217

--- array_alloc_3.s.good2010-11-26 13:04:58.0 +0100
+++ array_alloc_3.s.bad 2010-11-26 13:04:48.0 +0100
@@ -151,6 +151,7 @@
.p2align 4,,10
.p2align 3
 .L11:
+   movq(%rcx), %rdx
movq$1, 144(%rsp)
movq%rbp, 152(%rsp)
movq$1, 168(%rsp)
@@ -159,7 +160,6 @@
movq$1, 192(%rsp)
movq%r11, 200(%rsp)
movq%r10, 184(%rsp)
-   movq(%rcx), %rdx
subq-8(%rcx), %rdx
addq$1, %rdx
cmovs   %r9, %rdx

which is

(insn 264 263 267 15 (set (mem/s:DI (plus:DI (reg/f:DI 7 sp)
(const_int 184 [0xb8])) [5 parm.16.dim[2].stride+0 S8 A64])
(reg:DI 39 r10 [orig:227 D.1900 ] [227]))
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/array_alloc_3.f90:12
62 {*movdi_internal_rex64}
 (nil))

(and similar accesses to parm.16) vs.

(insn:TI 267 264 268 15 (set (reg:DI 1 dx [323])
(mem:DI (reg:DI 2 cx [orig:251 ivtmp.92 ] [251]) [3 MEM[(struct
array3_integer(kind=4) *)D.2016_21]+0 S8 A64]))
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/array_alloc_3.f90:12
62 {*movdi_internal_rex64}
 (nil))

  # PT = { parm.16ptD.1610ptD.1610 }
  D.2016_21 = (void *) ivtmp.92_128;

I found the bug and have a patch.

[Bug middle-end/46674] New: Weak alias was mistakenly optimized away

[jiez at gcc dot gnu.org]

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

   Summary: Weak alias was mistakenly optimized away
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


Created attachment 22537
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22537
The test case

This patch

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02275.html

causes a failure when building glibc for arm-none-linux-gnueabi target. The
reduced test case is attached.

Without this patch, memchr is defined in the assembly:

.size__memchr, .-__memchr
.weak   __GI_memchr
.hidden __GI_memchr
.set__GI_memchr,__memchr
.global memchr
.setmemchr,__GI_memchr
.ident"GCC: (GNU) 4.6.0 20101026 (experimental)"

but with this patch, memchr is not defined:

.size__memchr, .-__memchr
.weak__GI_memchr
.hidden__GI_memchr
.set__GI_memchr,__memchr
.ident"GCC: (GNU) 4.6.0 20101026 (experimental)"

When compiling the test case, -O is used on the command line.

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther  2010-11-26 
11:32:53 UTC ---
You then need to make sure to create variant types of aggregates with the
target attribute applied to all subtypes (thus, the restrict stuff removed)
as the middle-end doesn't know about this rule.

[Bug regression/46667] Target arm-unknown-eabi build results in "causes a section type conflict" error in libstdc++

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.26 11:29:17
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  2010-11-26 
11:29:17 UTC ---
I see this failure as well starting from a couple of nights back.

Ramana

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2010-11-26 
11:25:30 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #2)
> > > int &a = a;
> > > i don't believe this is valid code.  i believe g++ should reject the code.
> > 
> > I'm not convinced the compiler must reject it. EDG accepts it too.
> 
> Without warning? What about clang 2.8?

Yes, without warning (G++ at least warns)
I don't know about clang

[Bug lto/46664] Failed to build 481.wrf in SPEC CPU 2006 with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.26 11:23:10
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2010-11-26 
11:23:10 UTC ---
Confirmed.  My gold also complains:

/var.o netcdf/typeSizes.o netcdf/netcdf.o -o wrf
/usr/bin/gold: error: module_physics_init.fppized.o: multiple definition of
'module_ra_gfdleta.eq.0_'
/usr/bin/gold: module_ra_gfdleta.fppized.o: previous definition here
/usr/bin/gold: error: module_physics_init.fppized.o: multiple definition of
'module_ra_gfdleta.eq.1_'
/usr/bin/gold: module_ra_gfdleta.fppized.o: previous definition here
/usr/bin/gold: error: module_physics_init.fppized.o: multiple definition of
'module_ra_gfdleta.eq.2_'
...
In file included from :12:0:
solve_em.fppized.f90: In function 'solve_em':
solve_em.fppized.f90:3:0: internal compiler error: in build2_stat, at
tree.c:3798
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [/tmp/cc4pERit.ltrans2.ltrans.o] Error 1

In the end it is because we have

{
  type = [0:D.35766] * restrict
  offset = 0
  elements = {
[0] = D.36037_17957 * 1, 
[1] = (lbound.2168_17368 + 1) * stride.2022_17908 * 8, 
[2] = stride.2025_17914 * j_18060 * 4, 
[3] = offset.2026_17932 * 4, 
[4] = lbound.2168_17368 * stride.2022_17908 * -4, 
[5] = (j_18060 + -1) * stride.2025_17914 * -4, 
[6] = D.36025_17988 * -1, 
[7] = i_18065 * 4
  }
  rest = () D.36049_17926
}

and D.36049_17926 is a pointer.  Thus, the affine comb is of pointer type
but there is no pointer element.

We are adding

{
  type = [0:D.35766] * restrict
  offset = 0
  elements = {
[0] = D.36037_17957 * 1, (void *)
[1] = (lbound.2168_17368 + 1) * stride.2022_17908 * 4, (int)
[2] = stride.2025_17914 * j_18060 * 4, (int)
[3] = offset.2026_17932 * 4 (int)
  }
}

and

{
  type = 
  offset = 0
  elements = {
[0] = lbound.2168_17368 * stride.2022_17908 * -1,  (int)
[1] = (j_18060 + -1) * stride.2025_17914 * -1,  (int)
[2] = D.36025_17988 * -1,  (void *)
[3] = i_18065 * 4,  (int)
[4] = D.36049_17926 * 1,  (void *)
[5] = (lbound.2168_17368 + 1) * stride.2022_17908 * 4  (int)
  }
}

Adding D.36049_17926 we add it to ->rest of

{
  type = [0:D.35766] * restrict
  offset = 0
  elements = {
[0] = D.36037_17957 * 1, 
[1] = (lbound.2168_17368 + 1) * stride.2022_17908 * 4, 
[2] = stride.2025_17914 * j_18060 * 4, 
[3] = offset.2026_17932 * 4, 
[4] = lbound.2168_17368 * stride.2022_17908 * -4, 
[5] = (j_18060 + -1) * stride.2025_17914 * -4, 
[6] = D.36025_17988 * -1, 
[7] = i_18065 * 4
  }
}

because we overflow MAX_AFF_ELTS and hit

  type = comb->type;
  if (POINTER_TYPE_P (type))
type = sizetype;

which means ->rest will be always of sizetype which is inconsistent
with what aff_combination_to_tree does.

It sounds more natural to not start aff_combination_to_tree with
->rest but instead add that last, before adding ->offset.  That fixes
the ICE.

Mine.

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez  2010-11-26 
11:11:29 UTC ---
(In reply to comment #9)
> (In reply to comment #2)
> > int &a = a;
> > i don't believe this is valid code.  i believe g++ should reject the code.
> 
> I'm not convinced the compiler must reject it. EDG accepts it too.

Without warning? What about clang 2.8?

[Bug c/46672] Problem with fork and buffer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  2010-11-26 
11:05:56 UTC ---
Undefined: http://c-faq.com/ansi/undef.html

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||

--- Comment #9 from Jonathan Wakely  2010-11-26 
10:59:24 UTC ---
(In reply to comment #2)
> int &a = a;
> i don't believe this is valid code.  i believe g++ should reject the code.

I'm not convinced the compiler must reject it. EDG accepts it too.

> various comp.std.c++ people agree with me.

Working link to the thread:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/fb732bbcd0fecec5/4e04facc65ebf2f5

> 8.3.2/4 states "[...] A reference shall be initialized to refer to a valid
> object or function."
>
> surely a (the right-hand-side) is not a valid object or function since it has
> not been initialised, so the code is ill-formed.

Right, but consider:

inline int& f(int& i) { return i; }

int& i = f(i);

And then consider if f(int&) is not inline and is defined in another
translation unit.  The compiler can warn that f(i) uses an uninitialized
variable but can't know that the initializer for i is invalid, because maybe
f() does return a reference to a valid object.

(In reply to comment #8)
> in g++-4.6 (and maybe all before) this bug can be even more troublesome:
> struct AA
> {
>  int &a;
>  AA() : a(a)
>  {
>  }
> };
> 
> int main()
> {
> AA aa;
> cout << &aa.a << endl;
> return 0;
> }
> 
> compiled without a warning even with

That's simply because we don't do uninitialized warnings for data members,
that's a separate bug.

[Bug c/46672] Problem with fork and buffer

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andreas Schwab  2010-11-26 10:51:06 
UTC ---
There is nothing lost.  If stdout is line buffered then \n forces a flush.

[Bug c/46672] Problem with fork and buffer

[debayanin at gmail dot com]

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

Debayan Banerjee  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #2 from Debayan Banerjee  2010-11-26 
10:44:45 UTC ---
(In reply to comment #1)
> Concurrent writes to stdout (any files) invoke undefined behavior.

I dont think its undefined. For my compiler it always produces this output. I
tried the same on http://ideone.com (dont know which compiler they are using)
and it prints the correct output.

Also, doesnt each process have its own stdout?

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[doko at ubuntu dot com]

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

--- Comment #8 from Matthias Klose  2010-11-26 10:32:43 
UTC ---
Looking at Debian/Ubuntu build logs:

- the last sucessful build was 20100918-0ubuntu1.

- 20101004-0ubuntu1 shows an ICE building stage2 libgcc

- 20101004-0ubuntu1 shows an ICE building stage2 libgcc

- 20101009-1 (Debian) shows the ICE

 -20101012-0ubuntu1 is the last one showing this ICE

- 20101016-1 (Debian) shows the CTOR issue

- 20101114-1 shows the current CTOR issue (building stage1 GCC)

Maybe the issue was introduced between 20101012 and 20101016?