[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-10-08 
07:35:25 UTC ---
Depends if pointer comparison on the architecture is the same as comparing
integer of the same size and if the alignment of the pointer is the same as its
size and all bits are significant.
E.g. you can't optimize std::equal of say long double that way (e.g. on x86_64
there are 6 bytes of padding in it), but not even float/double (+/-0).  Not
sure e.g. on s390 31-bit if pointer comparison includes the topmost bit or not.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #3 from Paolo Carlini  2011-10-08 
08:12:29 UTC ---
Thanks Jakub. Indeed, I knew about floats, but for pointers looks like there is
more hope, in general, have to investigate a bit further. About s390, let's ask
Andreas...

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #4 from Marc Glisse  2011-10-08 
08:50:00 UTC ---
This seems to call for a traits class (provided by compiler magic) that tells
whether objects are memcmp-comparable (although we might have to be careful to
ask it about the status of T[] instead of plain T, not sure about that). There
are already traits telling whether objects can be copied with memcpy, (I think)
whether objects can be initialized with bzero, etc.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-10-08 
09:28:10 UTC ---
The analogy with copying and traits is enticing, but before reading Marc's
message, I wondered: for pointers, which kind of improvement are we talking
about? Comparing 64 bits at a time in a tight loop doesn't seem so bad...

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org
   |gnu.org |

[Bug fortran/47844] Array stride ignored for pointer-valued function results

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  2011-10-08 10:18:56 
UTC ---
Author: pault
Date: Sat Oct  8 10:18:51 2011
New Revision: 179710

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179710
Log:
2011-10-08  Paul Thomas  

PR fortran/47844
* trans-array.c (gfc_conv_array_index_offset): Use descriptor
stride for pointer function results.

2011-10-08  Paul Thomas  

PR fortran/47844
* gfortran.dg/pointer_function_result_1.f90 : New test.

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

[Bug middle-end/50638] [4.7 Regression] emulated TLS fails

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  
2011-10-08 10:22:30 UTC ---
On x86_64-apple-darwin10 the patch in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00597.html fixes the tls failures
(over a thousand in my tests;-).

[Bug rtl-optimization/50663] New: conditional propagation missed in cprop.c pass

[amker.cheng at gmail dot com]

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

 Bug #: 50663
   Summary: conditional propagation missed in cprop.c pass
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com


For following test case:
extern int g;
int main(int a, int b)
{
if (a == 1)
{
b = a;
}

g = b;
return 0;
}

piece of dump file for cprop1 pass is like:


(insn 8 4 9 2 (set (reg:CC 24 cc)
(compare:CC (reg/v:SI 135 [ a ])
(const_int 1 [0x1]))) test.c:4 200 {*arm_cmpsi_insn}
 (nil))

(jump_insn 9 8 10 2 (set (pc)
(if_then_else (ne (reg:CC 24 cc)
(const_int 0 [0]))
(label_ref 11)
(pc))) test.c:4 212 {*arm_cond_branch}
 (expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_BR_PROB (const_int 6218 [0x184a])
(nil)))
 -> 11)

(note 10 9 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 5 10 11 3 (set (reg/v:SI 136 [ b ])
(reg/v:SI 135 [ a ])) test.c:4 696 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg/v:SI 135 [ a ])
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil

The r135 in insn_5 should handled by conditional propagation, like:

(note 10 9 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 5 10 11 3 (set (reg/v:SI 136 [ b ])
(const_int 1 [0x1])) test.c:4 709 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg/v:SI 135 [ a ])
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil

Seems cprop misses the conditional propagation for the branch basic block.
FYI, I compiled the test case with command:
./arm-none-eabi-gcc -march=armv7-m -mthumb -O2 -S test.c -o test.S -da

The gcc is comfigured for arm-none-eabi and it's on trunk.

[Bug rtl-optimization/50663] conditional propagation missed in cprop.c pass

[amker.cheng at gmail dot com]

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

--- Comment #1 from amker.cheng  2011-10-08 
10:25:04 UTC ---
Here comes the cause:

Though the cprop.c pass collected the implicit_set information, it is recorded
as local info of basic block, and cprop only does global propagation.
The result is such conditional const propagation opportunities is missed.

The whole process in cprop pass is like:

bb0 : if (x)
then
 bb1
else
 bb2
end

1, implicit_set from the preceding bb0 is tagged as local in bb1;
2, in compute_local_properties, the implicit_set is recorded in avloc[bb1];
3, in compute_cprop_available, the implicit_set is only recorded in avout[bb1],
   not in avin[bb1], which it should be;
4, in cprop_insn and find_avail_set, only info recorded in avin[bb1] is
considered
   when try to do propagation for bb1;

Well, I believe it is a small problem, since implicit_set is recorded
in avout[bb1],
The basic block bb1 is the only one get missed in propagation.

I'm working on a patch and will send it for reviewing later.

[Bug fortran/50659] [4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6/4.7 Regression]
   |[F03] ICE on invalid with   |[F03] ICE with PROCEDURE
   |procedure interface |statement

--- Comment #7 from janus at gcc dot gnu.org 2011-10-08 10:49:38 UTC ---
(In reply to comment #4)
> I'm still not completely sure if the test case is valid or not. I could not
> find anything in the standard which forbids it, so I'm assuming it is valid 
> for
> now.

For what it's worth, the test case in comment #2 is accepted by g95, PGI and
PathScale.

It is rejected by ifort with:

error #8169: The specified interface is not declared.   [PROC]
  procedure(Proc) :: Proc_Get
^

To my understanding, this is a bug in ifort. However, ifort does accept the
following variant (which also ICEs with gfortran):


module m
  integer :: arrSize
end module

module m2
contains
  function Proc (arg)
use m
double precision, dimension(arrSize) :: proc
double precision :: arg
  end function
end

program p
  use m2
  implicit none
  procedure(Proc) :: Proc_Get
end


In summary, this test case is accepted by ifort, g95, PGI and PathScale, which
I think is strong empirical evidence that it is valid (though it's not a proof,
of course). I don't have access to any other compiler which supports PROCEDURE
statements.

Unless anyone can show me a restriction in the standard which makes it illegal,
I'll continue to assume that this is an ICE-on-valid bug (which makes it even
more severe).

[Bug fortran/50659] [4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  2011-10-08 
10:55:10 UTC ---
Compiling the code in comment #7 with 4.4.6 gives an ICE:

[macbook] f90/bug% gfortran-fsf-4.4 pr50659_3.f90
pr50659_3.f90:8: internal compiler error: in replace_symbol, at
fortran/expr.c:3630

while 4.4.6 does not give an ICE on the other tests.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[marc.glisse at normalesup dot org]

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

--- Comment #6 from Marc Glisse  2011-10-08 
10:59:31 UTC ---
(In reply to comment #5)
> The analogy with copying and traits is enticing, but before reading Marc's
> message, I wondered: for pointers, which kind of improvement are we talking
> about? Comparing 64 bits at a time in a tight loop doesn't seem so bad...

glibc uses SSE2 to work with 128 bits (but it is a bit more than a simple
comparison in this case) and the hand-written asm might be a bit better than
what gcc generates.

My suggestion about traits is actually not such a good idea, since comparison
operators are not generated by the compiler for non-builtin types.

[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[4.5/4.6/4.7 Regression]|[4.4/4.5/4.6/4.7
   |[F03] ICE with PROCEDURE|Regression] [F03] ICE with
   |statement   |PROCEDURE statement

--- Comment #9 from janus at gcc dot gnu.org 2011-10-08 11:11:32 UTC ---
(In reply to comment #8)
> Compiling the code in comment #7 with 4.4.6 gives an ICE:

... while it is accepted by 4.3.

Oh boy. So this thing is even a 4.4 regression!

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-10-08 
11:19:04 UTC ---
I see, in principle 256 bits too at a time, with avx or something, I guess.
That reminds me, i dont's why appropriate command line switches should not
trigger the use of the same instructions anyway: these loops are *really*
simple (for a range specified via pointers)!!

[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2011-10-08 11:19:07 UTC ---
One more side note: The following variant segfaults with 4.3:


module Test_Mod
 implicit none

contains

 subroutine Init
   procedure(Proc1) :: Proc_Get
 end subroutine

 function Proc1() result (res)
   double precision, dimension(3) :: res
 end function

end module


while 4.4 rejects it with:

   procedure(Proc1) :: Proc_Get
   1
Error: Interface 'proc1' of procedure 'proc_get' at (1) must be explicit


Since this is not a regression (and 4.3 is not being maintained any more,
anyway), it probably won't get fixed. From 4.5 on it is accepted.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-10-08 
11:34:51 UTC ---
I guess the problem with autovectorization of loop like:
  for (i = 0; i < n; i++)
if (array1[i] != array2[i])
  break;
  return i == n;
is the control flow in the loop and that the compiler can't know that it is ok
to access array1[i + 1] (assuming i < n) even when array1[i] == array2[i].
One would need to write something like
if (n >= 4)
  for (i = 0; i < n - 3; i += 4)
if ((array1[i] != array2[i])
| (array1[i+1] != array2[i+1])
| (array1[i+2] != array2[i+2])
| (array1[i+3] != array2[i+3]))
  return 0;
for (; i < n; i++)
  if (array1[i] != array2[i])
return 0;
return 1;
to get it SLP vectorized.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern
   ||dot ch

--- Comment #9 from Paolo Carlini  2011-10-08 
11:44:08 UTC ---
Thanks Jakub. Maybe Vincenzo is interested in this exchange, we vaguely
discussed a few times the idea of vectorization-friendly (or even explicit),
, etc.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #10 from Paolo Carlini  2011-10-08 
11:56:23 UTC ---
Naively, by 'vectorization-friendly' I mean a rewrite of the trivial loops
encoding explicitly the specified semantics (see, for example the 2nd
difficulty pointed out by Jakub). If we find a way to do that effectively but
still abstracting from the detail of the vector instructions, seems a great
idea! Does something similar already exist?

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-10-08 
12:20:34 UTC ---
One possibility would be some fallthru hint to the compiler similar to
__builtin_assume_aligned that would tell the compiler that certain range of
bytes will not trap/fault on reading and thus it is safe to read it
speculatively.
ptr = __builtin_assume_object_size (ptr, length);
or similar.  You could just insert it before the loop and let it be vectorized.
But I believe we don't vectorize even
void *array1[1024], *array2[1024];
int foo (void)
{
  int i;
  for (i = 0; i < 1024; i++)
if (array1[i] != array2[i])
  break;
  return i == n;
}
where the will not fault/trap for i 0 .. 1023 is already known (or can be
known).

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2011-10-08 
12:57:55 UTC ---
Did you recently check even simpler loops, single range, like std::accumulate?
I'm trying to figure out if we can deal in a light way with the simpler cases,
like provide hints, and then attack nastier cases, rewrite loops, file specific
autovect enhancement PRs motivated by the C++ library.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2011-10-08 
13:08:21 UTC ---
So far I've been mostly looking at C loops (e.g. the ones reported by Vincenzo
or derived from those), or, e.g. with
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00135.html for std::vector loops.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[vincenzo.innocente at cern dot ch]

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

--- Comment #14 from vincenzo Innocente  
2011-10-08 13:48:22 UTC ---
Thanks for adding me in the loop.
I wonder if we can reuse
-funsafe-loop-optimizations 
to force loop vectorization.
I know that INTEL has introduced a specific pragma to force vectorization for
instance.
Maybe gcc can do the same…

in any case recoding in
if ((array1[i] != array2[i])
| (array1[i+1] != array2[i+1])
| (array1[i+2] != array2[i+2])
| (array1[i+3] != array2[i+3]))

is Vector and size specific (SSE, AVX, future-1024) char,float,double
so very suboptimal...

[Bug other/50664] New: GDB rebuilt by i686-w64-mingw32-gcc4.6.2's "-Os" crahed when debuging, but "-O2" is OK.

[xunxun1982 at gmail dot com]

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

 Bug #: 50664
   Summary: GDB rebuilt by i686-w64-mingw32-gcc4.6.2's "-Os"
crahed when debuging, but "-O2" is OK.
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xunxun1...@gmail.com


I don't know which section this issue can be reported in.

I rebuilt the latest gcc4.6 branch on Win7 and I found a weird probem.
When I use the editon to build gdb with "-Os", it won't list source code, and
if you input list twice, gdb will crash.

The debug log:
--
GNU gdb (GDB) 7.3.1.20110921-cvs
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
For bug reporting instructions, please see:
...
Reading symbols from E:\MyPack\MinGW\bin/gdb-1.exe...done.
(gdb) run
Starting program: E:\MyPack\MinGW\bin/gdb-1.exe
[New Thread 2212.0x1ba8]
GNU gdb (pcx32) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
For bug reporting instructions, please see:
.
(gdb) file a.exe
Reading symbols from e:\t\temp\a.exe...done.
(gdb) l
(gdb) No source file named main.
l
[New Thread 2212.0xe34]
[New Thread 2212.0x654]

Program received signal SIGSEGV, Segmentation fault.
0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING) at exceptions.c:126
126  switch (current_catcher->state)
(gdb) bt
#0  0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING)
at exceptions.c:126
#1  0x0041ad0d in throw_exception (exception=...) at exceptions.c:240
#2  0x0041ae68 in exceptions_state_mc (action=)
at exceptions.c:191
#3  0x0041b1d4 in catch_errors (func=0x40181e ,
func_args=0x28fe90, errstring=0x614070 "", mask=6) at exceptions.c:519
#4  0x0040262c in gdb_main (args=0x28fe90) at ./main.c:949
#5  0x00608ef0 in main (argc=1, argv=0x3f2fc0) at gdb.c:35
(gdb) bt 30
#0  0x0041ad8b in exceptions_state_mc (action=CATCH_THROWING)
at exceptions.c:126
#1  0x0041ad0d in throw_exception (exception=...) at exceptions.c:240
#2  0x0041ae68 in exceptions_state_mc (action=)
at exceptions.c:191
#3  0x0041b1d4 in catch_errors (func=0x40181e ,
func_args=0x28fe90, errstring=0x614070 "", mask=6) at exceptions.c:519
#4  0x0040262c in gdb_main (args=0x28fe90) at ./main.c:949
#5  0x00608ef0 in main (argc=1, argv=0x3f2fc0) at gdb.c:35
(gdb) q
A debugging session is active.

Inferior 1 [process 2212] will be killed.

Quit anyway? (y or n)
 

But if I replace "-Os" with "-O2" to rebuild again, gdb will work ok.

And gcc4.6.1 release haven't the issue.
I don't know why.
So it's gcc's -Os bug?
But I only found the issue when I built gdb, other projects with "-Os" work
well.

[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org 2011-10-08 15:08:25 UTC ---
Here is an alternative patch to the one in comment #4:

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 179710)
+++ gcc/fortran/expr.c(working copy)
@@ -4144,7 +4144,8 @@ replace_symbol (gfc_expr *expr, gfc_symbol *sym, i
   if ((expr->expr_type == EXPR_VARIABLE 
|| (expr->expr_type == EXPR_FUNCTION
&& !gfc_is_intrinsic (expr->symtree->n.sym, 0, expr->where)))
-  && expr->symtree->n.sym->ns == sym->ts.interface->formal_ns)
+  && expr->symtree->n.sym->ns == sym->ts.interface->formal_ns
+  && expr->symtree->n.sym->attr.dummy)
 {
   gfc_symtree *stree;
   gfc_namespace *ns = sym->formal_ns;


We simply forgot to check if the symbol we're replacing is actually a dummy
argument! This even qualifies as obvious, I think ...

[Bug c/50662] Incorrect diagnostic returning non-const array pointer

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Joseph S. Myers  2011-10-08 
16:04:52 UTC ---
This is not a bug.  You can implicitly convert "pointer to int" to "pointer to
const int", but not "pointer to array of int" to "pointer to array of const
int" (see 6.5.16.1), and "const that_type *" is "pointer to array of const int"
(there is no such type as "pointer to const array of int", which would be a
permitted target of such a conversion; see 6.7.3#8).

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

  Attachment #25409|0   |1
is obsolete||

--- Comment #41 from Mikael Morin  2011-10-08 
16:26:31 UTC ---
Created attachment 25443
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25443
Most up-to-date patch

Here is the latest patch.
It has evolved quite a lot since the last submission, but the evolutions are
improved handling of array constructors, and slightly different scalarizer
structures, so that the code produced should not be worse than the previous
versions (but there should not be great improvements either).

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

  Attachment #23267|0   |1
is obsolete||

--- Comment #42 from Mikael Morin  2011-10-08 
16:29:57 UTC ---
Created attachment 25444
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25444
slightly updated testcase

[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map

[andi-gcc at firstfloor dot org]

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

--- Comment #11 from Andi Kleen  2011-10-08 
16:47:54 UTC ---
Created attachment 25445
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25445
patchkit

I tested this patchkit which implements most of the ideas from this bug,
unfortunately still the same problem (with 20% threshold and madvise)

>From the core file I see a lot of 2-3 page holes still:

65218 load65205 00019000  2ae45c515000    bfea1000 
2**12
  CONTENTS, ALLOC, LOAD
65219 load65206 00018000  2ae45c52f000    bfeba000 
2**12
  CONTENTS, ALLOC, LOAD
65220 load65207 00013000  2ae45c548000    bfed2000 
2**12
  CONTENTS, ALLOC, LOAD
65221 load65208 00019000  2ae45c55d000    bfee5000 
2**12
  CONTENTS, ALLOC, LOAD
65222 load65209 1000  2ae45c577000    bfefe000 
2**12
  CONTENTS, ALLOC, LOAD
65223 load65210 00044000  2ae45c579000    bfeff000 
2**12
  CONTENTS, ALLOC, LOAD
65224 load65211 0003d000  2ae45c5be000    bff43000 
2**12
  CONTENTS, ALLOC, LOAD
65225 load65212 00021000  2ae45c5fc000    bff8 
2**12
  CONTENTS, ALLOC, LOAD
65226 load65213 6000  2ae45c61e000    bffa1000 
2**12
  CONTENTS, ALLOC, LOAD
65227 load65214 0002d000  2ae45c625000    bffa7000 
2**12
  CONTENTS, ALLOC, LOAD
65228 load65215 00041000  2ae45c653000    bffd4000 
2**12
  CONTENTS, ALLOC, LOAD
65229 load65216 b000  2ae45c695000    c0015000 
2**12
  CONTENTS, ALLOC, LOAD
65230 load65217 1000  2ae45c6a1000    c002 
2**12
  CONTENTS, ALLOC, LOAD
65231 load65218 f000  2ae45c6a3000    c0021000 
2**12
  CONTENTS, ALLOC, LOAD
65232 load65219 1000  2ae45c6b3000    c003 
2**12
  CONTENTS, ALLOC, LOAD
65233 load65220 00031000  2ae45c6b5000    c0031000 
2**12
  CONTENTS, ALLOC, LOAD
65234 load65221 0001a000  2ae45c6e7000    c0062000 
2**12
  CONTENTS, ALLOC, LOAD
65235 load65222 0001c000  2ae45c702000    c007c000 
2**12
  CONTENTS, ALLOC, LOAD

[Bug bootstrap/50665] New: [4.7 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

 Bug #: 50665
   Summary: [4.7 Regression] Bootstrap failure
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 179703 gave:

checking for stdlib.h... ../../src-trunk/libcpp/lex.c: In function 'const
uchar* search_line_sse42(const uchar*, const uchar*)':
../../src-trunk/libcpp/lex.c:466:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Revision 179695 is OK.

[Bug libobjc/50428] Consider changing semantics of +initialize so that it is inherited

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2011-10-08 17:52:11 
UTC ---
Author: nicola
Date: Sat Oct  8 17:52:06 2011
New Revision: 179711

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179711
Log:
In libobjc/:
2011-10-08  Richard Frith-Macdonald 
Nicola Pero  

PR libobjc/50428
* sendmsg.c (__objc_send_initialize): If a class does not have an
+initialize method, search for an +initialize method in the
superclass and in the ancestor classes and execute the first one
that is found.  This makes the GNU runtime behave in the same way
as the Apple/NeXT runtime with respect to +initialize methods and
subclassing.

In gcc/:
2011-10-08  Nicola Pero  

PR libobjc/50428
* doc/objc.texi (Garbage Collection): Updated example to protect
+initialize against execution in subclasses.

In gcc/testsuite/:
2011-10-08  Nicola Pero  

PR libobjc/50428
* objc/execute/initialize-1.m: New test.

Added:
trunk/gcc/testsuite/objc/execute/initialize-1.m
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/objc.texi
trunk/gcc/testsuite/ChangeLog
trunk/libobjc/ChangeLog
trunk/libobjc/sendmsg.c

[Bug libobjc/50428] Consider changing semantics of +initialize so that it is inherited

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2011-10-08 17:56:09 
UTC ---
Implemented in trunk.  The change will appear in 4.7.0.

Thanks

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu.org]

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

--- Comment #43 from Mikael Morin  2011-10-08 
17:57:43 UTC ---
(In reply to comment #39)
> Thanks. One comment: I think you will increase the binary size by inlining the
> reduction. Could you consider keeping the current libgfortran version and
> protecting the scalarization by
>   if (!optimize_size)
> 
This is included in the patch in comment #41. Unfortunately, it makes the test
(comment #42) fail with -Os in the testsuite. I don't know yet how I will
handle it. I would like to avoid forcing one optimization level if possible.
Any idea?

[Bug bootstrap/50665] [4.7 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-10-08 19:23:54 
UTC ---
This may be another target optimization bug:

[hjl@gnu-1 prev-gcc]$ cat /tmp/x.i
const char *
__attribute__((__target__("ssse3")))
foo (const char *s)
{
  return s;
}
[hjl@gnu-1 prev-gcc]$ ./xgcc -B./ -S /tmp/x.i -o /tmp/x.s
/tmp/x.i: In function \u2018foo\u2019:
/tmp/x.i:6:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-1 prev-gcc]$

[Bug lto/50666] New: bad error reporting for TMPDIR full

[andi-gcc at firstfloor dot org]

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

 Bug #: 50666
   Summary: bad error reporting for TMPDIR full
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


When $TMPDIR gets full for a LTO build you just get

"ld exited with error 1"

which is very unhelpful.

It would be better if there was a real error message for this.

[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

  Attachment #25445|0   |1
is obsolete||

--- Comment #12 from Andi Kleen  2011-10-08 
19:54:59 UTC ---
Created attachment 25446
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25446
updated patchkit

This version seems to work. I am at under 1000 mappings now for the case
that failed previously.

[Bug bootstrap/50665] [4.7 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-10-08 20:12:37 
UTC ---
Program received signal SIGSEGV, Segmentation fault.
df_ref_create_structure (cl=DF_REF_ARTIFICIAL, collection_rec=0xd110, 
reg=0xafafafaf, loc=0x0, bb=0xf7dae000, info=0x0, ref_type=DF_REF_REG_DEF, 
ref_flags=0) at ../../src-trunk/gcc/df-scan.c:2755
2755  int regno = REGNO (GET_CODE (reg) == SUBREG ? SUBREG_REG (reg) :
reg);
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-9.1.f15.i686
gmp-4.3.2-3.fc15.i686 libgcc-4.6.0-10.fc15.i686
libmpc-0.8.3-0.3.svn855.fc15.i686 libstdc++-4.6.0-10.fc15.i686
mpfr-3.0.0-4.fc15.i686 zlib-1.2.5-3.fc15.i686
(gdb)  bt
#0  df_ref_create_structure (cl=DF_REF_ARTIFICIAL, collection_rec=0xd110, 
reg=0xafafafaf, loc=0x0, bb=0xf7dae000, info=0x0, ref_type=DF_REF_REG_DEF, 
ref_flags=0) at ../../src-trunk/gcc/df-scan.c:2755
#1  0x0827c04c in df_ref_record (cl=DF_REF_ARTIFICIAL, 
collection_rec=0xd110, reg=, loc=0x0, bb=0xf7dae000, 
insn_info=0x0, ref_type=DF_REF_REG_DEF, ref_flags=0)
at ../../src-trunk/gcc/df-scan.c:2888
#2  0x0827c2ef in df_entry_block_defs_collect (collection_rec=0xd110, 
entry_block_defs=) at ../../src-trunk/gcc/df-scan.c:3823
#3  0x0827c35c in df_record_entry_block_defs (entry_block_defs=0x8f2ea28)
at ../../src-trunk/gcc/df-scan.c:3839
#4  0x0827f7ec in df_scan_blocks () at ../../src-trunk/gcc/df-scan.c:670
#5  0x0826dc77 in rest_of_handle_df_initialize ()
at ../../src-trunk/gcc/df-core.c:738
#6  0x084990cc in execute_one_pass (pass=0x8d485c0)
at ../../src-trunk/gcc/passes.c:2064
#7  0x08499435 in execute_pass_list (pass=0x8d485c0)
at ../../src-trunk/gcc/passes.c:2119
#8  0x08499448 in execute_pass_list (pass=0x8d493c0)
at ../../src-trunk/gcc/passes.c:2120
#9  0x085af6d7 in tree_rest_of_compilation (fndecl=0xf7d7b580)
at ../../src-trunk/gcc/tree-optimize.c:420
#10 0x0825254f in cgraph_expand_function (node=0xf7ce83d8)
---Type  to continue, or q  to quit---
at ../../src-trunk/gcc/cgraphunit.c:1805
#11 0x08254733 in cgraph_output_in_order ()
at ../../src-trunk/gcc/cgraphunit.c:1962
#12 cgraph_optimize () at ../../src-trunk/gcc/cgraphunit.c:2136
#13 0x08254abf in cgraph_finalize_compilation_unit ()
at ../../src-trunk/gcc/cgraphunit.c:1312
#14 0x0812f650 in c_write_global_declarations ()
at ../../src-trunk/gcc/c-decl.c:9936
#15 0x0854432a in compile_file () at ../../src-trunk/gcc/toplev.c:581
#16 do_compile () at ../../src-trunk/gcc/toplev.c:1925
#17 toplev_main (argc=13, argv=0xd404) at ../../src-trunk/gcc/toplev.c:2001
#18 0x0811012b in main (argc=13, argv=0xd404)
at ../../src-trunk/gcc/main.c:36
(gdb)

[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2011-10-08 
20:14:14 UTC ---
In the 0001-initial-madvise.patch patch I think if you subtract the size
MADV_DONTNEEDed from G.bytes_mapped, then you should add it again in
alloc_page (i.e. replace
+  p->unmapped = false;
+
you've added there with:
+  if (p->unmapped)
+G.bytes_mapped += p->bytes;
+  p->unmapped = false;
+
Not sure if it is enough as is with that change, or if more is needed - like
also keeping track of the size of currently MADV_DONTNEED bytes and if it grows
too much together with G.bytes_mapped, consider really munmapping some of the
pages (perhaps try to sort the free list by increasing size, so that further
allocations will prefer the smaller blocks over the larger ones, and if getting
close to filled address space, consider freeing some of the largest one in case
malloc would be requested.  Or alternatively, hook into xmalloc_failed and if
malloc fails, try to free some of the largest chunks and retry.  I'm just
worried if at some point during the compilation we need huge amount of GC
memory, close to filling 32-bit address space, then we GC collect lots of it,
but on the other side would need a lot of malloced memory.  But perhaps that is
unlikely to happen.

[Bug middle-end/50598] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jh at suse dot cz

--- Comment #1 from Dominique d'Humieres  2011-10-08 
20:33:53 UTC ---
Revision 179428 is OK, the failures appear at revision 179429.

[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map

[andi-gcc at firstfloor dot org]

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

--- Comment #14 from Andi Kleen  2011-10-08 
21:10:13 UTC ---
Thanks for the review. Fixed the accounting

I'll leave the xmalloc_failed hook out for now: it would need a retry
path which is somewhat complicated. If it's needed would probably just
add another separate threshold that forces munmapping.

BTW i also filed a bug on the glibc bug this triggered:
http://sourceware.org/bugzilla/show_bug.cgi?id=13276

[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  2011-10-08 
21:41:11 UTC ---
FORALL sucks rocks through a straw.

We cannot use the usual front-end optimization within forall, because

  forall(iTime=1:2)
 tmp = dble(iTime)
 timeSteps(iTime)=ratio**(tmp-0.5d0)-ratio**(tmp-1.5d0)
  end forall

doesn't work (gfortran correctly warns about multiple assignments to tmp).

So, the best method is to disable front-end optimization within
a forall loop.

I assume the same holds for DO CONCURRENT.

[Bug middle-end/50598] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-10-08 
21:50:37 UTC ---
Reverting the change for gcc/cgraphunit.c in  revision 179429 fixes the pr.

[Bug middle-end/50667] New: [4.7 Regression] FAIL: gcc.c-torture/execute/vshuf-* on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

 Bug #: 50667
   Summary: [4.7 Regression] FAIL: gcc.c-torture/execute/vshuf-*
on powerpc-apple-darwin9
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: r...@gcc.gnu.org
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


Between revisions 179667 (OK) and 179708 (ICE, see
http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00887.html) the tests
gcc.c-torture/execute/vshuf-* are failing with an internal compiler error:

[karma] f90/bug% gcc47
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/vshuf-v16qi.c
[address=18e6a568 pc=005a76dc]
In file included from
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/vshuf-v16qi.c:5:0:
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/vshuf-main.inc: In function
'main':
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/vshuf-main.inc:12:9: internal
compiler error: Segmentation Fault

The back-trace is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x18e6a568
maybe_gen_insn (icode=16845201, nops=4, ops=0xbfffd1e8) at
../../work/gcc/optabs.c:7436
7436  gcc_assert (nops == (unsigned int) insn_data[(int)
icode].n_generator_args);
(gdb) bt
#0  maybe_gen_insn (icode=16845201, nops=4, ops=0xbfffd1e8) at
../../work/gcc/optabs.c:7436
#1  0x005a7e60 in maybe_expand_insn (icode=, nops=,
ops=) at
../../work/gcc/optabs.c:7468
#2  0x005b0198 in expand_insn (icode=, nops=,
ops=) at
../../work/gcc/optabs.c:7499
#3  0x005b0b54 in expand_vec_perm_expr (type=, v0=0x41d7f65c, v1=0x20213220, mask=, target=) at ../../work/gcc/optabs.c:6704
#4  0x003995a0 in expand_expr_real_2 (ops=0xbfffd358, target=0x1010991,
tmode=V16QImode, modifier=EXPAND_NORMAL) at ../../work/gcc/expr.c:8610
#5  0x00273388 in expand_gimple_stmt (stmt=0x41dbd0a8) at
../../work/gcc/cfgexpand.c:2014
#6  0x00273ff4 in expand_gimple_basic_block (bb=0x41dbd0a8) at
../../work/gcc/cfgexpand.c:3814
#7  0x002764d8 in gimple_expand_cfg () at ../../work/gcc/cfgexpand.c:4322
#8  0x005bd020 in execute_one_pass (pass=0xbd8eb0) at
../../work/gcc/passes.c:2064
#9  0x005bd3d4 in execute_pass_list (pass=0xccd2c8) at
../../work/gcc/passes.c:2119
#10 0x00713dcc in tree_rest_of_compilation (fndecl=0x41da7500) at
../../work/gcc/tree-optimize.c:420
#11 0x0029ba84 in cgraph_expand_function (node=0x41dbf968) at
../../work/gcc/cgraphunit.c:1805
#12 0x0029deec in cgraph_optimize () at ../../work/gcc/cgraphunit.c:1962
#13 0x0029e214 in cgraph_finalize_compilation_unit () at
../../work/gcc/cgraphunit.c:1312
#14 0x000206f8 in c_write_global_declarations () at
../../work/gcc/c-decl.c:9936
#15 0x00688214 in toplev_main (argc=2, argv=0xe) at ../../work/gcc/toplev.c:581
#16 0x1bf8 in start ()

[Bug c/50668] New: gcc gives warnings for code with #if 0 .... #endif code block

[jg at jguk dot org]

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

 Bug #: 50668
   Summary: gcc gives warnings for code with #if 0  #endif
code block
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@jguk.org


A little surprised to see the following build warning for code withn #if 0 
#endif I had expected that to be excluded from the build.

main3.c:4:3: warning: missing terminating " character

gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

gcc -Wall -o main main3.c

My sample program follows:


#if 0
p("
#endif

int main(void)
{
return 0;
}

[Bug c/50669] New: no warning for unused globals

[jg at jguk dot org]

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

 Bug #: 50669
   Summary: no warning for unused globals
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@jguk.org


I see unused warning for item on stack, but not global variale that is unused.
Could gcc also give warnings for unused globals?

jon@laptop:~$ gcc -Wextra -Wunused -Wall -o main main4.c
main4.c: In function ‘main’:
main4.c:9:6: warning: unused variable ‘unused_flag’


Example program follows:

// gcc -Wextra -Wunused -Wall -o main main4.c


int unused_int;


int main(void)
{
int unused_flag;

return 0;
}

[Bug testsuite/50670] New: GCC testsuite try to execute sse2 code on non-sse2 machines

[newsgrp at duradsl dot dyndns.org]

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

 Bug #: 50670
   Summary: GCC testsuite try to execute sse2 code on non-sse2
machines
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: news...@duradsl.dyndns.org


Created attachment 25447
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25447
testsuite gcc.log

When running gcc testsuite on an athlon-xp machine (which does not support
sse2) it tries to execute pr48377.c compiled with -msse2 switch.

/sources/gcc-4.6.1/gcc-build/gcc/xgcc -B/sources/gcc-4.6.1/gcc-build/gcc/
/sources/gcc-4.6.1/gcc-4.6.1/gcc/testsuite/gcc.dg/vect/pr48377.c   -msse2
-ftree-vectorize -fno-vect-cost-model -O2 -fdump-tree-vect-details  -lm   -o
./pr48377.exe
./pr48377.exe
Illegal instruction (core dumped)

No more core if -msse2 switch is removed

This bug is quite similar to PR36889, but IMHO the PR36889 resolution is not
applicable here.

/sources/gcc-4.6.1/gcc-build/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/sources/gcc-4.6.1/gcc-build/gcc/xgcc
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.1/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-multilib
--disable-bootstrap --with-ppl --with-cloog
Thread model: posix
gcc version 4.6.1 (GCC)

[Bug bootstrap/50665] [4.7 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #3 from H.J. Lu  2011-10-08 22:49:14 
UTC ---
[hjl@gnu-1 gcc]$ cat x.i
const char *
foo (const char *s)
{
  return s;
}
[hjl@gnu-1 gcc]$ ./xgcc -B./ -S x.i -o /tmp/x.s -mssse3
x.i: In function \u2018foo\u2019:
x.i:5:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-1 gcc]$ 

Somehow

Continuing.
Hardware watchpoint 9: default_target_regs.x_hard_regno_nregs[31][DImode]

Old value = 1 '\001'
New value = 255 '\377'
init_all_optabs () at insn-opinit.c:1543
1543set_direct_optab_handler (vec_perm_optab, V2DImode,
CODE_FOR_vec_permv2di);

overwrites default_target_regs.x_hard_regno_nregs[31][DImode].

[Bug preprocessor/12075] non-terminated quotes within #if'ed out text comments confuse preprocessor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jg at jguk dot org

--- Comment #2 from Andrew Pinski  2011-10-08 
22:58:18 UTC ---
*** Bug 50668 has been marked as a duplicate of this bug. ***

[Bug c/50668] gcc gives warnings for code with #if 0 .... #endif code block

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2011-10-08 
22:58:18 UTC ---
This is correct since it has to be parsed for tokens inside the #if block.

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

[Bug middle-end/25957] -fstack-protector code on i386/x86_64 can be improved.

[andi-gcc at firstfloor dot org]

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

--- Comment #11 from Andi Kleen  2011-10-08 
23:27:02 UTC ---
I just checked and the problem is still there with

 4.7.0 20111002

   xorq%fs:40, %rax
jne .L4
addq$120, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L4:
.cfi_restore_state
.p2align 4,,6
call__stack_chk_fail
.cfi_endproc
.LFE0:


unnecessary wasteful alignment for the call to
abort. The basic block should be marked cold.

[Bug c++/34927] Duplicate error message about abstract class

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2011-10-09 00:21:41 UTC ---
Author: paolo
Date: Sun Oct  9 00:21:37 2011
New Revision: 179718

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179718
Log:
2011-10-08  Paolo Carlini  

PR c++/34927
* typeck2.c (abstract_virtuals_error_sfinae): Don't produce duplicate
inform messages in case of cloned destructor.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/34927] Duplicate error message about abstract class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  2011-10-09 
00:23:44 UTC ---
Fixed for 4.7.0.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen  2011-10-09 
02:31:38 UTC ---
Looked at this now again

debug_function doesn't work. TDF_UID was also not available, but i hardcoded
it.

(gdb)  call debug_function (cfun->decl, 1<<8)
(gdb)

neither the other call

(gdb)  call print_generic_expr(stderr, result, 1 << 8)
(gdb) 

Looking at the code

0x0075a827 :test   %rax,%rax
0x0075a82a :je 0x75a7f2 
0x0075a82c :cmp%rax,%rbx
0x0075a82f :je 0x75a7f2 
0x0075a831 :mov$0xbe3bb7,%edx
0x0075a836 :mov$0x9b,%esi
0x0075a83b :mov$0xbe3b7a,%edi
0x0075a840 :callq  0xb488e0 
0x0075a845 :nopl   (%rax)


I'm in the fancy_abort

When I go up and print $rax I get 0

(gdb) p $rax
$11 = 0

But this cannot be because the test tested it for 0.  Perhaps the 
unwind information below is wrong?

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #6 from Andi Kleen  2011-10-09 
04:05:52 UTC ---
i changed the code now to save ret_val in a volatile global.

This is a bit better

(gdb) p saved_ret_val
$5 = (volatile tree) 0x2afc557b68c0
(gdb) p result
$6 = (tree_node *) 0x2afbfb754a00

Still not sure how to print them, maybe stderr is broken.

Looking at raw output I see one of them is a VAR_DECL and the other
a RESULT_DECL

(gdb) p result->decl_minimal.uid
$9 = 83837
(gdb) p saved_ret_val->decl_minimal.uid
$10 = 3599083
(gdb) p cfun->decl->decl_minimal.uid
$3 = 83835


Searching for the second uid in the dump files I see it first in 
045i.whole-program:

 :
  return D.3599083;

and the first doesn't appear in any file (that means the current pass added
it?)
 The third is first in 049.inline