[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[octoploid at yandex dot com]

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

--- Comment #13 from Markus Trippelsdorf  ---
(In reply to Jeffrey A. Law from comment #11)
> Damn it.  Tested the wrong compiler.
> 
> The problem with your testcase Markus is you're simply not allowed to pass a
> null pointer to sprintf, memcpy and a variety of other functions.  Once you
> execute code which attempts that, you've walked into the realm of undefined
> behaviour.
> 
> Once you cross that boundary the compiler is allowed to do these kinds of
> transformations.  Your testcode is fundamentally flawed in that it relies
> upon undefined behaviour.

Understood. But the problem is that "the kernel" and "x.org" still fail.
I will try to come up with testcases for those two and see if it's also
caused by the same undefined behavior.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
I'll note further, that an implementation of sprintf, memcpy, etc could check
for a NULL pointer internally and raise a trap on their own rather than
dereferencing the invalid pointer and still be a conforming implementation.

In summary, you can't make the assumption that you'll actually get a
segfault/bus error like your code wants to do.

Contrast that to an explicit *0 =  which might appear in user code. 
While executing that code still results in undefined behaviour, one can easily
make an argument from a QOI standpoint that we should still allow the memory
dereference to occur to generate the SIGBUS/SIGSEGV.

[Bug fortran/59103] [OOP] Reject deallocate/intent(out) for polymorphic var in PURE procedures (IR F08/0033)

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Actually, we also have to check whether finalizers are IMPURE for
nonpolymorphic TYPE. I think we currently don't do so.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
Damn it.  Tested the wrong compiler.

The problem with your testcase Markus is you're simply not allowed to pass a
null pointer to sprintf, memcpy and a variety of other functions.  Once you
execute code which attempts that, you've walked into the realm of undefined
behaviour.

Once you cross that boundary the compiler is allowed to do these kinds of
transformations.  Your testcode is fundamentally flawed in that it relies upon
undefined behaviour.

[Bug fortran/59104] New: Wrong result with SIZE specification expression

[burnus at gcc dot gnu.org]

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

Bug ID: 59104
   Summary: Wrong result with SIZE specification expression
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

James Van Buskirk found the following problem,
https://groups.google.com/forum/#!topic/comp.lang.fortran/2RleGXz6-ew

Result with GCC 4.8 + 4.9:
   size(f) =1
   size(y) =   2143476561

Result with GCC 4.5, 4.6 and 4.7:
 size(f) =1
 size(y) =1

Expected result:
 size(f) =1
 size(y) =2


module m1
   implicit none
   integer, parameter :: dp = kind([double precision::])
   contains
  recursive function f(x)
 integer, intent(in) :: x
 real(dp) f(x/2)
 integer y(size(f)+1)

 write(*,*) 'size(f) = ',size(f)
 write(*,*) 'size(y) = ',size(y)
 f = 0
  end function f
end module m1

program bug3
   use m1
   implicit none
   real y

   y = sum(f(2))
end program bug3

[Bug fortran/59103] New: [OOP] Reject deallocate/intent(out) for polymorphic var in PURE procedures (IR F08/0033)

[burnus at gcc dot gnu.org]

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

Bug ID: 59103
   Summary: [OOP] Reject deallocate/intent(out) for polymorphic
var in PURE procedures (IR F08/0033)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

(This PR is also motivated by
https://groups.google.com/forum/#!topic/comp.lang.fortran/66iSG-kMZfo and
https://groups.google.com/forum/#!topic/comp.lang.fortran/-NaOfgodyYc )


Interpretation request F08/0033,
ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1875.txt, added additional
restrictions to PURE as polymorphic variables might have IMPURE FINAL
subroutines. Thus:

* An INTENT(OUT) argument of a pure procedure should
  not be allowed to be polymorphic
* deallocation of any polymorphic entity should be forbidden in
  a pure procedure.
* Any statement that might result in a deallocation that is
  forbidden should not be allowed in a pure procedure.


Or more formally:


EDITS to 10-007r1:

[24:10] 1.6.2p1 last sentence, "Any"->"Except as identified in this
subclause, any".
{This edit is also present in interp F08/0032.}

[24:11+] 1.6.2 at end of subclause insert new paragraph:

 "Fortran 2003 permitted an INTENT(OUT) argument of a pure
  subroutine to be polymorphic.  This is not permitted by this
  part of ISO/IEC 1539.".

[312:23+] After C1278, insert new constraint:
  "C1278b An INTENT(OUT) dummy argument of a pure procedure shall not
  be polymorphic."

[313:4+] After C1284, insert new constraint and note:
  "C1284a A statement that might result in the deallocation of a
  polymorphic entity is not permitted in a pure procedure.

   Note 12.48x
   Apart from the DEALLOCATE statement, this includes intrinsic
   assignment if the variable has a polymorphic allocatable component
   at any level of component selection that does not involve a pointer
   component but which might involve one or more allocatable
   components."


Example:
  See interpretation request.

[Bug c/59100] requesting optimization of safe rotate function

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
IIRC we already added another safe rotate form this year based on a report by
Niels, you may want to search for that (maybe in the comment before
simplify_rotate in tree-ssa-forwprop.c).

Basically you are asking to optimize n?rotate(x,n):x to rotate(x,n), makes
sense.

[Bug c++/58533] [c++1y] ICE with auto in function pointer

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords|error-recovery, |ice-on-valid-code
   |ice-on-invalid-code |
 CC||adam at jessamine dot co.uk

--- Comment #1 from Volker Reichelt  ---
Adam, thanks to your patch (see PR58534 etc.), this is now also compiled.
Do you want to add a testcase for this one, too?

[Bug c++/58549] [4.9 Regression] [c++1y] ICE with local function in function with auto parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Volker Reichelt  ---
Fixed by Adam's patch.

[Bug c++/58548] [4.9 Regression] [c++1y] ICE with local struct in function with auto parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Volker Reichelt  ---
Fixed by Adam's patch.

[Bug c++/58637] [c++1y] ICE with wrong usage of template<> in front of function containing auto parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Volker Reichelt  ---
Fixed by Adam's patch.

[Bug c++/58536] [c++1y] ICE with auto in constructor

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #4 from Volker Reichelt  ---
Fixed by Adam's patch.

[Bug c++/58534] [c++1y] ICE with auto in template function parameters

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #2 from Volker Reichelt  ---
Fixed by Adam's patch.

[Bug tree-optimization/59102] New: ICE on valid code at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 59102
   Summary: ICE on valid code at -Os and above on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes). 

This is a regression from 4.8.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++,fortran,lto
--disable-werror --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131112 (experimental) [trunk revision 204721] (GCC) 
$ 
$ gcc-trunk -O1 small.c; a.out
$ gcc-4.8.2 -Os small.c; a.out
$
$ gcc-trunk -Os small.c
small.c: In function ‘main’:
small.c:16:1: internal compiler error: gimple check: expected
gimple_assign(error_mark), have gimple_call() in gimple_assign_lhs, at
gimple.h:1774
 main ()
 ^
0x7bafab gimple_check_failed
../../gcc-trunk/gcc/gimple.c:1139
0x51c805 gimple_assign_lhs
../../gcc-trunk/gcc/gimple.h:1774
0xe28b58 gimple_assign_lhs
../../gcc-trunk/gcc/gimple.h:1774
0xe28b58 insert_trap_and_remove_trailing_statements
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:73
0xe29861 gimple_ssa_isolate_erroneous_paths
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:300
0xe29861 execute
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:365
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


int a, b, c, f;

struct S
{
  int f0;
} d, *e;

struct S
foo ()
{
  b = c = b || a == 0 || f % 11;
  return d;
}

int
main ()
{
  foo ();
  if (b);
  else
{
  struct S **g = &e;
  *g = 0;
  *e = foo ();
}
  return 0;
}

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[kcc at gcc dot gnu.org]

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

--- Comment #7 from Kostya Serebryany  ---
Is this fixed by  http://gcc.gnu.org/viewcvs?rev=204726&root=gcc&view=rev ?

[Bug c/59101] New: integer wrong code bug

[regehr at cs dot utah.edu]

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

Bug ID: 59101
   Summary: integer wrong code bug
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: regehr at cs dot utah.edu

$ gcc -O0 foo.c ; ./a.out 
7
$ gcc -O1 foo.c ; ./a.out 
6
$ cat foo.c
int printf(const char *, ...);
int a, b;

int main() {
  b = (~a & 4102790424) > 0 | 6;
  printf("%d\n", b);
  return 0;
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r204695-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r204695-install
--enable-languages=c,c++ --enable-multilib
Thread model: posix
gcc version 4.9.0 20131112 (experimental) (GCC)

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
I ran the testcase you sent.  It worked fine for me.

THe problems we're having are within the realm of normal development and they
will be resolved one way or another.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[octoploid at yandex dot com]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Jeffrey A. Law from comment #8)
> Should be fixed via recent commits.  Specifically, we preserve the *0 for
> code that wants to catch the null pointer deref.

Well, if you had run the simple glibc testcase that I've posted above,
you would have found out that your recent commits don't fix this issue.

It's obvious, not only from the amount of churn, that fisolate-erroneous-paths
shouldn't be enabled by default at -O2. The very few users you would like
SIGSEGV
to be transformed to SIGILL by the compiler should set this option explicitly.

[Bug c/59100] New: requesting optimization of safe rotate function

[regehr at cs dot utah.edu]

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

Bug ID: 59100
   Summary: requesting optimization of safe rotate function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: regehr at cs dot utah.edu

Here is the obvious rotate idiom in C (this code is from Nettle):

#define ROTL32(n,x) (((x)<<(n)) | ((x)>>(32-(n

GCC does an admirable job of recognizing the code and turning it into a rotate
instruction, when one is available.

The problem is that this code executes undefined behavior when n==0 or n==32.

Most crypto libraries are careful not to rotate by 32, but out of 10 libraries
that I examined, 5 execute undefined behavior when rotating by zero.

We can make the obvious modification to protect against undefined rotate by 0:

#define ROTL32(n,x) ((n)==0?(x):(((x)<<(n)) | ((x)>>(32-(n)

Notice that this can be turned into exactly the same object code as the earlier
macro since the rotate-by-0 special case is already handled by the rotate
instruction.  However, this isn't what we get out of the compiler:

rotl32c:
movl%edi, %eax
movb%sil, %cl
roll%cl, %eax
testl%esi, %esi
cmove%edi, %eax
ret

I'm in the process of trying to convince crypto library maintainers to fix
their rotate functions and macros, and this will be easier if the fix doesn't
have a performance penalty.

So would it be possible for you folks to teach the compiler to emit the better
code for the safe rotate idiom?

[Bug c/59098] Unwarranted warning: promoted ~unsigned is always non-zero [-Wsign-compare]

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
Possibly related to bug 38341.

Note also that this simple change:

Index: c-common.c
===
--- c-common.c  (revision 204219)
+++ c-common.c  (working copy)
@@ -11236,11 +11236,11 @@ warn_for_sign_compare (location_t locati
 {
   mask = (~ (HOST_WIDE_INT) 0) << bits;
   if ((mask & constant) != mask)
{
  if (constant == 0)
-   warning (OPT_Wsign_compare,
+   warning_at (location, OPT_Wsign_compare,
 "promoted ~unsigned is always non-zero");
  else
warning_at (location, OPT_Wsign_compare,
"comparison of promoted ~unsigned with
constant");
}


improves the caret information from:

small.c:6:3: warning: promoted ~unsigned is always non-zero [-Wsign-compare]
   return (val ^ (small_type_t)0xul) == 0;
   ^

to:

small.c:6:45: warning: promoted ~unsigned is always non-zero [-Wsign-compare]
   return (val ^ (small_type_t)0xul) != 0;
 ^

[Bug rtl-optimization/59099] New: Erroneous register allocation on 32-bit x86 using regparm

[ian at airs dot com]

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

Bug ID: 59099
   Summary: Erroneous register allocation on 32-bit x86 using
regparm
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
CC: vmakarov at redhat dot com

The appended test case should run without error and return 0.  When I compile
it with  -O2 -fPIC -m32 for 32-bit x86, it crashes at runtime with a
segmentation violation.

The generated code is incorrect.  The loop is entered like this:

movl12(%esp), %eax
leal4(%esi), %ecx
movl%edi, 64(%esp)
xorl%esi, %esi
subl$1, %eax
movl%eax, 20(%esp)
jmp.L7


Note that %eax holds a value stored in 20(%esp), which as we will see is used
to terminate the loop.  At .L7 we see this:

.L7:
movl4(%esp), %edi
testl%edi, %edi
jne.L5
cmpl%edx, 20(%esp)
jne.L5

Note that nothing changes %eax.  Note the comparison with 20(%esp).

At .L5 we see this:

.L5:
movl64(%esp), %edi
movl(%eax), %eax

Note that we are loading a value from %eax.  But at this point it still holds
the value it was given before the loop, which is a counter, not a pointer.

I have not tried to track down the problem, but superficially it appears that
the register allocator has decided to rematerialize the pointer p from the
register parameter, without realizing that the register has changed since the
start of the function.

This is reduced from code in the libgo library.  The libgo code does not use
regparm, but the function in question is a static function and the optimizers
assign it regparm ((1)).

void (*pfn)(void);

struct s
{
  void** q;
  int h;
  int t;
  int s;
};


void* f (struct s *, struct s *) __attribute__ ((noinline, regparm(1)));

void*
__attribute__ ((regparm(1)))
f (struct s *p, struct s *p2)
{
  void *gp, *gp1;
  int t, h, s, t2, h2, c, i;

  if (p2->h == p2->t)
return 0;

  (*pfn) ();

  h = p->h;
  t = p->t;
  s = p->s;

  h2 = p2->h;
  t2 = p2->t;

  gp = p2->q[h2++];

  c = (t2 - h2) / 2;
  for (i = 0; i != c; i++)
{
  if (t == h || (h == 0 && t == s - 1))
break;
  gp1 = p2->q[h2++];
  p->q[t++] = gp1;
  if (t == s)
t = 0;
}

  p2->h = h2;
  return gp;
}

static void fn () { }

int
main()
{
  struct s s1, s2;
  void *q[10];

  pfn = fn;

  s1.q = q;
  s1.h = 0;
  s1.t = 2;
  s1.s = 4;

  s2.q = q;
  s2.h = 0;
  s2.t = 4;
  s2.s = 2;

  f (&s1, &s2);

  return 0;
}

[Bug c/59098] New: Unwarranted warning: promoted ~unsigned is always non-zero [-Wsign-compare]

[jmattsson at dius dot com.au]

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

Bug ID: 59098
   Summary: Unwarranted warning: promoted ~unsigned is always
non-zero [-Wsign-compare]
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmattsson at dius dot com.au

Created attachment 31202
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31202&action=edit
Tiny test case for this issue

We recently switched to compiling existing warning-free code from IAR to gcc,
and are seeing "warning: promoted ~unsigned is always non-zero" for lines like
this:

  return (val ^ (small_type_t)0xul) == 0;

where "val" is of type "small_type_t" and "small_type_t" is typedef'd elsewhere
depending on the target platform/project to a uint8_t/uint16_t/uint32_t. The
code produced is correct, with or without optimization enabled.

Rewriting the code into two lines removes the warning:

  small_type_t mask = (small_type_t)0xul;
  return (val ^ mask) == 0;


As far as we can tell, the warning in the above is unwarranted and incorrect,
given that correct output is produced. It appears what the warning is really
trying to catch is this:

  return ~val == 0;

which due to promotion before the tilde application, does in fact end up always
non-zero and probably not what was intended/expected by the developer. Gcc
however also warns about

  return (small_type_t)~val == 0;

despite this producing the expected correct behavior.


We see this both on gcc 4.7.3 and 4.8.2 (and presumably others, but we haven't
tested).

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-1)

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)

[Bug c++/59097] New: [4.7/4.8/4.9 Regression] ICE with invalid statement expression as array size

[reichelt at gcc dot gnu.org]

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

Bug ID: 59097
   Summary: [4.7/4.8/4.9 Regression] ICE with invalid statement
expression as array size
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet triggers an ICE since GCC 4.6.0:


void foo()
{
  int x[({ return; })];
}


bug.cc: In function 'void foo()':
bug.cc:3:22: internal compiler error: Segmentation fault
   int x[({ return; })];
  ^
0xb2bf3f crash_signal
../../gcc/gcc/toplev.c:334
0x6dac34 cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9350
0x6db91b cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9453
0x6de4d6 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:9725
0x6e119b maybe_constant_value(tree_node*)
../../gcc/gcc/cp/semantics.c:9835
0x567450 compute_array_index_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/decl.c:8227
0x589075 create_array_type_for_decl
../../gcc/gcc/cp/decl.c:8540
0x589075 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:9486
0x58d8f4 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4469
0x6664a2 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16567
0x667edf cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11107
0x64bdf0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10988
0x64cf13 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10635
0x64d587 cp_parser_statement
../../gcc/gcc/cp/parser.c:9376
0x64e289 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9654
0x64e3fe cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9608
0x661a8b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18461
0x661a8b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18497
0x665e8f cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22520
0x666c62 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22441
Please submit a full bug report, [etc.]


A slightly different testcase produces a different ICE:


void foo()
{
  int x[({ L: ; })];
}


bug.cc: In function 'void foo()':
bug.cc:3:19: internal compiler error: unexpected expression '' of
kind label_expr
   int x[({ L: ; })];
   ^
0x6db55d cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9705
0x6de4d6 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:9725
0x6e119b maybe_constant_value(tree_node*)
../../gcc/gcc/cp/semantics.c:9835
0x567450 compute_array_index_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/decl.c:8227
0x589075 create_array_type_for_decl
../../gcc/gcc/cp/decl.c:8540
0x589075 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:9486
0x58d8f4 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4469
0x6664a2 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16567
0x667edf cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11107
0x64bdf0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10988
0x64cf13 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10635
0x64d587 cp_parser_statement
../../gcc/gcc/cp/parser.c:9376
0x64e289 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9654
0x64e3fe cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9608
0x661a8b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18461
0x661a8b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18497
0x665e8f cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22520
0x666c62 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22441
0x666c62 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16472
0x667edf cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11107
Please submit a full bug report, [etc.]

[Bug c++/58822] Segfault when calling make_shared

[vlukas at gmx dot de]

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

vlukas at gmx dot de changed:

   What|Removed |Added

 CC||vlukas at gmx dot de

--- Comment #26 from vlukas at gmx dot de ---
I think the main.ii from 2013-10-23 can be reduced to this:
---
struct Exception {
  Exception(int) {}
};

template
int make_shared(Arg arg)
{
  Exception* p = arg; p = p;
  return 0;
}

struct InvalidArgumentException : public virtual Exception
{
 explicit InvalidArgumentException() : Exception(make_shared(this))
 { }

  virtual ~InvalidArgumentException() noexcept {}
};

int main()
{
  throw InvalidArgumentException();
}
--

I believe this violates a restriction of the Standard, namely section 3.8,
paragraph 5, dash 3 (in the N3290 draft or in N3797).

I can reproduce a segmentation fault with both my reduced testcase and the
original main.ii.

Mr. Henning, you could try the following:
In your main.ii on line 24571 substitute the *implicit* cast by an explicit
one, so that the line reads
: Exception(std::make_shared(static_cast(this)))

Or replace the forbidden implicit cast by changing line 24556 so that it reads
template explicit ExceptionImplBase(E const*) {}

Both options fulfill the requirements of the Standard to the letter and on my
system make the segmentation fault go away. Valgrind won't indicated an error
with those modifications either.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Should be fixed via recent commits.  Specifically, we preserve the *0 for code
that wants to catch the null pointer deref.

[Bug c++/59096] New: [4.9 Regression] [c++11] ICE with template attribute

[reichelt at gcc dot gnu.org]

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

Bug ID: 59096
   Summary: [4.9 Regression] [c++11] ICE with template attribute
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with "-std=c++11") triggers an ICE
on trunk:


template struct A
{
  typedef T B [[mode]];
};

A::B b;


bug.cc: In instantiation of 'struct A':
bug.cc:6:7:   required from here
bug.cc:3:22: internal compiler error: Segmentation fault
   typedef T B [[mode]];
  ^
0xb2bf3f crash_signal
../../gcc/gcc/toplev.c:334
0x5beaf8 contains_struct_check
../../gcc/gcc/tree.h:2819
0x5beaf8 apply_late_template_attributes
../../gcc/gcc/cp/pt.c:8618
0x5cd569 tsubst_decl
../../gcc/gcc/cp/pt.c:10976
0x5bbf6c tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11325
0x5e98f0 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8974
0x5e98f0 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9238
0x677563 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:132
0x652b5a cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:5377
0x66120e cp_parser_constructor_declarator_p
../../gcc/gcc/cp/parser.c:22246
0x66120e cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11434
0x667d39 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11039
0x64bdf0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10988
0x66f8a7 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10885
0x66e5c8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10771
0x66fe56 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4007
0x66fe56 c_parse_file()
../../gcc/gcc/cp/parser.c:31107
0x791013 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1055
Please submit a full bug report, [etc.]

The regression appeared between 4.9.0 20131012 and 4.9.0 20131019.

[Bug go/59095] New: FAIL: TestMakeFunc on x32

[hjl.tools at gmail dot com]

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

Bug ID: 59095
   Summary: FAIL: TestMakeFunc on x32
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: hjl.tools at gmail dot com

On x32, I got

FAIL: TestMakeFunc (0.00 seconds)
all_test.go:1457: Call returned 10, 20, 30, [40 0], 60, 70, 80; want 10,
 20, 30, [40, 50], 60, 70, 80

X32 info can be found at

https://sites.google.com/site/x32abi/

[Bug target/59091] __builtin_trap calls abort for arm-linux-gnueabi

[marcus.shawcroft at arm dot com]

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

Marcus Shawcroft  changed:

   What|Removed |Added

 CC||marcus.shawcroft at arm dot com

--- Comment #2 from Marcus Shawcroft  ---
Mark Mitchell proposed a patch some time back, not sure why it didn't get
installed:

See:

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00639.html

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[mikpelinux at gmail dot com]

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

--- Comment #6 from Mikael Pettersson  ---
(In reply to Kostya Serebryany from comment #5)
> So far we were not even able to reproduce it. 

Building gcc trunk as a cross to ppc64-linux reproduces the build failure for
me.

[Bug bootstrap/59094] [4.9 Regression] Cilk runtime library headers are installed into the general include directory

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

 CC||bviyer at gcc dot gnu.org,
   ||bviyer at gmail dot com

--- Comment #1 from Dmitry Gorbachev  ---
CC'ing the Cilk runtime library maintainer.

This is like the libvtv bug 58441...

[Bug bootstrap/59094] New: [4.9 Regression] Cilk runtime library headers are installed into the general include directory

[d.g.gorbachev at gmail dot com]

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

Bug ID: 59094
   Summary: [4.9 Regression] Cilk runtime library headers are
installed into the general include directory
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.g.gorbachev at gmail dot com

When GCC is configured with "--enable-version-specific-runtime-libs", header
files for libstdc++, libgomp, libquadmath, etc. are installed in the
compiler-specific directory ($libdir/gcc/$target/$version/include). But
libcilkrts, somehow, stands out from this scheme. It seems to be a bug.

[Bug target/59092] __builtin_trap calls abort for aarch64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-12
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I have a patch which I am testing.

[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Nov 12 21:33:06 2013
New Revision: 204720

URL: http://gcc.gnu.org/viewcvs?rev=204720&root=gcc&view=rev
Log:
2013-11-12  Vladimir Makarov  

PR other/58712
* ira-costs.c (record_operand_costs): Check operands number for
the single set.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c

[Bug fortran/59093] internal compiler error: Segmentation fault compiling F90 File

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
I see the segmentation fault from 4.4 up to trunk. The backtrace for revision
204648 is

Program received signal SIGSEGV, Segmentation fault.
0x000100109a88 in gfc_trans_pointer_assignment (expr1=, expr2=)
at ../../_clean/gcc/fortran/trans-expr.c:6622
6622  gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);
(gdb) bt
#0  0x000100109a88 in gfc_trans_pointer_assignment (expr1=, expr2=)
at ../../_clean/gcc/fortran/trans-expr.c:6622
#1  0x0001000c8007 in trans_code (code=, cond=) at ../../_clean/gcc/fortran/trans.c:1639
#2  0x00010012adc5 in gfc_trans_if_1 (code=) at
../../_clean/gcc/fortran/trans-stmt.c:985
#3  0x0001001320ad in gfc_trans_if (code=) at
../../_clean/gcc/fortran/trans-stmt.c:1016
#4  0x0001000c7e48 in trans_code (code=, cond=) at ../../_clean/gcc/fortran/trans.c:1719
#5  0x0001000f4a69 in gfc_generate_function_code (ns=)
at ../../_clean/gcc/fortran/trans-decl.c:5528
#6  0x0001000c99f2 in gfc_generate_module_code (ns=)
at ../../_clean/gcc/fortran/trans.c:1955
#7  0x0001000822a9 in gfc_parse_file () at
../../_clean/gcc/fortran/parse.c:4523
#8  0x0001000c34e6 in gfc_be_parse_file () at
../../_clean/gcc/fortran/f95-lang.c:189
#9  0x0001008107b4 in compile_file () at ../../_clean/gcc/toplev.c:545
#10 0x00010081295a in toplev_main (argc=2, argv=0x7fff5fbfd8f0) at
../../_clean/gcc/toplev.c:1891
#11 0x0001aba4 in _Unwind_Find_FDE (pc=0x7fff5fbfd8e0, bases=0x0) at
../../../_clean/libgcc/unwind-dw2-fde.c:1029

[Bug fortran/59093] internal compiler error: Segmentation fault compiling F90 File

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-12
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Reduced test:

module MAPL_LocStreamMod

implicit none
private

type, public :: MAPL_LocStream
  private
  type(MAPL_LocStreamType), pointer :: Ptr=>null()
end type MAPL_LocStream

type MAPL_Tiling
   integer :: IM=0
end type MAPL_Tiling

type MAPL_LocStreamType
   type(MAPL_Tiling),pointer  :: Tiling(:)  =>null() ! Grid
associated tilings
end type MAPL_LocStreamType

contains

  subroutine MAPL_LocStreamGet(LocStream, GRIDIM)
type(MAPL_LocStream), intent(IN   ) :: LocStream
integer, optional,pointer   :: GRIDIM(:)

if (present(gridim)) then
   gridim => locstream%Ptr%tiling(:)%im
end if

  end subroutine MAPL_LocStreamGet

end module MAPL_LocStreamMod

[Bug target/59054] Powerpc -O0 -mcpu=power7 generates sub-optimal code to load 0

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Tue Nov 12 20:55:58 2013
New Revision: 204718

URL: http://gcc.gnu.org/viewcvs?rev=204718&root=gcc&view=rev
Log:
2013-11-12  Michael Meissner  

PR target/59054
* config/rs6000/rs6000.md (movdi_internal32): Eliminate
constraints that would allow DImode into the traditional Altivec
registers, but cause undesirable code generation when loading 0 as
a constant.
(movdi_internal64): Likewise.
(cmp_fpr): Do not use %x for CR register output.
(extendsfdf2_fpr): Fix constraints when -mallow-upper-df and
-mallow-upper-sf debug switches are used.

[gcc/testsuite]
2013-11-12  Michael Meissner  

PR target/59054
* gcc.target/powerpc/pr59054.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr59054.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/58548] [4.9 Regression] [c++1y] ICE with local struct in function with auto parameter

[abutcher at gcc dot gnu.org]

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

--- Comment #4 from abutcher at gcc dot gnu.org ---
Author: abutcher
Date: Tue Nov 12 20:17:33 2013
New Revision: 204714

URL: http://gcc.gnu.org/viewcvs?rev=204714&root=gcc&view=rev
Log:
Refactor implicit function template implementation and fix 58534, 58536, 58548,
58549 and 58637.

gcc/
* tree.c (grow_tree_vec_stat): New function ...
* tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration
and macro front-end.

gcc/cp/
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser.h (struct cp_parser): New members implicit_template_parms,
implicit_template_scope and auto_is_implicit_function_template_parm_p.
* parser.c (add_implicit_template_parms): Refactor as ...
(synthesize_implicit_template_parm): ... this to append a new template
type parm to the current template parameter list (introducing a new list
if necessary).  Removed push_deferring_access_checks.
(finish_fully_implicit_template): Removed pop_deferring_access_checks.
(cp_parser_new): Initialize new cp_parser members.
(cp_parser_parameter_declaration_clause): Consider auto as implicit
template parm when parsing a parameter declaration (unless parsing an
explicit specialization).
(cp_parser_parameter_declaration_list): Remove local
implicit_template_parms counter and reset cp_parser implicit template
state when complete.
(cp_parser_lambda_expression): Reset implicit template cp_parser members
whilst generating lambda class.
(cp_parser_function_definition_after_declarator): Reset implicit
template cp_parser members whilst parsing function definition.
(make_generic_type_name): Respell '' as 'auto:N' which works
better with template diagnostics.
(cp_parser_simple_type_specifier): Synthesize implicit template parm on
parsing 'auto' if auto_is_implicit_function_template_parm_p and provide
diagnostics ...
* decl.c (grokdeclarator): ... that were previously done here.

gcc/testsuite/g++.dg/
* cpp1y/pr58534.C: New testcase.
* cpp1y/pr58536.C: New testcase.
* cpp1y/pr58548.C: New testcase.
* cpp1y/pr58549.C: New testcase.
* cpp1y/pr58637.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr58534.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58536.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58548.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58549.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58637.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/58549] [4.9 Regression] [c++1y] ICE with local function in function with auto parameter

[abutcher at gcc dot gnu.org]

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

--- Comment #6 from abutcher at gcc dot gnu.org ---
Author: abutcher
Date: Tue Nov 12 20:17:33 2013
New Revision: 204714

URL: http://gcc.gnu.org/viewcvs?rev=204714&root=gcc&view=rev
Log:
Refactor implicit function template implementation and fix 58534, 58536, 58548,
58549 and 58637.

gcc/
* tree.c (grow_tree_vec_stat): New function ...
* tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration
and macro front-end.

gcc/cp/
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser.h (struct cp_parser): New members implicit_template_parms,
implicit_template_scope and auto_is_implicit_function_template_parm_p.
* parser.c (add_implicit_template_parms): Refactor as ...
(synthesize_implicit_template_parm): ... this to append a new template
type parm to the current template parameter list (introducing a new list
if necessary).  Removed push_deferring_access_checks.
(finish_fully_implicit_template): Removed pop_deferring_access_checks.
(cp_parser_new): Initialize new cp_parser members.
(cp_parser_parameter_declaration_clause): Consider auto as implicit
template parm when parsing a parameter declaration (unless parsing an
explicit specialization).
(cp_parser_parameter_declaration_list): Remove local
implicit_template_parms counter and reset cp_parser implicit template
state when complete.
(cp_parser_lambda_expression): Reset implicit template cp_parser members
whilst generating lambda class.
(cp_parser_function_definition_after_declarator): Reset implicit
template cp_parser members whilst parsing function definition.
(make_generic_type_name): Respell '' as 'auto:N' which works
better with template diagnostics.
(cp_parser_simple_type_specifier): Synthesize implicit template parm on
parsing 'auto' if auto_is_implicit_function_template_parm_p and provide
diagnostics ...
* decl.c (grokdeclarator): ... that were previously done here.

gcc/testsuite/g++.dg/
* cpp1y/pr58534.C: New testcase.
* cpp1y/pr58536.C: New testcase.
* cpp1y/pr58548.C: New testcase.
* cpp1y/pr58549.C: New testcase.
* cpp1y/pr58637.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr58534.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58536.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58548.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58549.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58637.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/58637] [c++1y] ICE with wrong usage of template<> in front of function containing auto parameter

[abutcher at gcc dot gnu.org]

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

--- Comment #1 from abutcher at gcc dot gnu.org ---
Author: abutcher
Date: Tue Nov 12 20:17:33 2013
New Revision: 204714

URL: http://gcc.gnu.org/viewcvs?rev=204714&root=gcc&view=rev
Log:
Refactor implicit function template implementation and fix 58534, 58536, 58548,
58549 and 58637.

gcc/
* tree.c (grow_tree_vec_stat): New function ...
* tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration
and macro front-end.

gcc/cp/
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser.h (struct cp_parser): New members implicit_template_parms,
implicit_template_scope and auto_is_implicit_function_template_parm_p.
* parser.c (add_implicit_template_parms): Refactor as ...
(synthesize_implicit_template_parm): ... this to append a new template
type parm to the current template parameter list (introducing a new list
if necessary).  Removed push_deferring_access_checks.
(finish_fully_implicit_template): Removed pop_deferring_access_checks.
(cp_parser_new): Initialize new cp_parser members.
(cp_parser_parameter_declaration_clause): Consider auto as implicit
template parm when parsing a parameter declaration (unless parsing an
explicit specialization).
(cp_parser_parameter_declaration_list): Remove local
implicit_template_parms counter and reset cp_parser implicit template
state when complete.
(cp_parser_lambda_expression): Reset implicit template cp_parser members
whilst generating lambda class.
(cp_parser_function_definition_after_declarator): Reset implicit
template cp_parser members whilst parsing function definition.
(make_generic_type_name): Respell '' as 'auto:N' which works
better with template diagnostics.
(cp_parser_simple_type_specifier): Synthesize implicit template parm on
parsing 'auto' if auto_is_implicit_function_template_parm_p and provide
diagnostics ...
* decl.c (grokdeclarator): ... that were previously done here.

gcc/testsuite/g++.dg/
* cpp1y/pr58534.C: New testcase.
* cpp1y/pr58536.C: New testcase.
* cpp1y/pr58548.C: New testcase.
* cpp1y/pr58549.C: New testcase.
* cpp1y/pr58637.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr58534.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58536.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58548.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58549.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58637.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/58536] [c++1y] ICE with auto in constructor

[abutcher at gcc dot gnu.org]

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

--- Comment #3 from abutcher at gcc dot gnu.org ---
Author: abutcher
Date: Tue Nov 12 20:17:33 2013
New Revision: 204714

URL: http://gcc.gnu.org/viewcvs?rev=204714&root=gcc&view=rev
Log:
Refactor implicit function template implementation and fix 58534, 58536, 58548,
58549 and 58637.

gcc/
* tree.c (grow_tree_vec_stat): New function ...
* tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration
and macro front-end.

gcc/cp/
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser.h (struct cp_parser): New members implicit_template_parms,
implicit_template_scope and auto_is_implicit_function_template_parm_p.
* parser.c (add_implicit_template_parms): Refactor as ...
(synthesize_implicit_template_parm): ... this to append a new template
type parm to the current template parameter list (introducing a new list
if necessary).  Removed push_deferring_access_checks.
(finish_fully_implicit_template): Removed pop_deferring_access_checks.
(cp_parser_new): Initialize new cp_parser members.
(cp_parser_parameter_declaration_clause): Consider auto as implicit
template parm when parsing a parameter declaration (unless parsing an
explicit specialization).
(cp_parser_parameter_declaration_list): Remove local
implicit_template_parms counter and reset cp_parser implicit template
state when complete.
(cp_parser_lambda_expression): Reset implicit template cp_parser members
whilst generating lambda class.
(cp_parser_function_definition_after_declarator): Reset implicit
template cp_parser members whilst parsing function definition.
(make_generic_type_name): Respell '' as 'auto:N' which works
better with template diagnostics.
(cp_parser_simple_type_specifier): Synthesize implicit template parm on
parsing 'auto' if auto_is_implicit_function_template_parm_p and provide
diagnostics ...
* decl.c (grokdeclarator): ... that were previously done here.

gcc/testsuite/g++.dg/
* cpp1y/pr58534.C: New testcase.
* cpp1y/pr58536.C: New testcase.
* cpp1y/pr58548.C: New testcase.
* cpp1y/pr58549.C: New testcase.
* cpp1y/pr58637.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr58534.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58536.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58548.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58549.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58637.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/58534] [c++1y] ICE with auto in template function parameters

[abutcher at gcc dot gnu.org]

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

--- Comment #1 from abutcher at gcc dot gnu.org ---
Author: abutcher
Date: Tue Nov 12 20:17:33 2013
New Revision: 204714

URL: http://gcc.gnu.org/viewcvs?rev=204714&root=gcc&view=rev
Log:
Refactor implicit function template implementation and fix 58534, 58536, 58548,
58549 and 58637.

gcc/
* tree.c (grow_tree_vec_stat): New function ...
* tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration
and macro front-end.

gcc/cp/
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser.h (struct cp_parser): New members implicit_template_parms,
implicit_template_scope and auto_is_implicit_function_template_parm_p.
* parser.c (add_implicit_template_parms): Refactor as ...
(synthesize_implicit_template_parm): ... this to append a new template
type parm to the current template parameter list (introducing a new list
if necessary).  Removed push_deferring_access_checks.
(finish_fully_implicit_template): Removed pop_deferring_access_checks.
(cp_parser_new): Initialize new cp_parser members.
(cp_parser_parameter_declaration_clause): Consider auto as implicit
template parm when parsing a parameter declaration (unless parsing an
explicit specialization).
(cp_parser_parameter_declaration_list): Remove local
implicit_template_parms counter and reset cp_parser implicit template
state when complete.
(cp_parser_lambda_expression): Reset implicit template cp_parser members
whilst generating lambda class.
(cp_parser_function_definition_after_declarator): Reset implicit
template cp_parser members whilst parsing function definition.
(make_generic_type_name): Respell '' as 'auto:N' which works
better with template diagnostics.
(cp_parser_simple_type_specifier): Synthesize implicit template parm on
parsing 'auto' if auto_is_implicit_function_template_parm_p and provide
diagnostics ...
* decl.c (grokdeclarator): ... that were previously done here.

gcc/testsuite/g++.dg/
* cpp1y/pr58534.C: New testcase.
* cpp1y/pr58536.C: New testcase.
* cpp1y/pr58548.C: New testcase.
* cpp1y/pr58549.C: New testcase.
* cpp1y/pr58637.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr58534.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58536.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58548.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58549.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr58637.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug fortran/59093] New: internal compiler error: Segmentation fault compiling F90 File

[matthew.thompson at nasa dot gov]

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

Bug ID: 59093
   Summary: internal compiler error: Segmentation fault compiling
F90 File
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.thompson at nasa dot gov

Created attachment 31201
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31201&action=edit
Pre-processed source file

I'm getting an ICE compiling a Fortran file. I'll attach a stripped down
reproducer that demonstrates the problem (the real file is 3000+ lines and
requires many, many external modules and libraries).

Per instructions, running gfortran on our .F90:

$ gfortran -v -save-temps MAPL_LocStreamGet.F90
Driving: gfortran -v -save-temps MAPL_LocStreamGet.F90 -l gfortran -l m
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/other/SLES11.1/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /gpfsm/dnbsrc/other/GCC/SLES11/4.8.1/gcc-4.8.1/configure
--prefix=/usr/local/other/SLES11.1/gcc/4.8.1 CC=gcc --enable-languages=all
--enable-bootstrap
Thread model: posix
gcc version 4.8.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/usr/local/other/SLES11.1/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/f951
MAPL_LocStreamGet.F90 -cpp=MAPL_LocStreamGet.f90 -quiet -v
MAPL_LocStreamGet.F90 -quiet -dumpbase MAPL_LocStreamGet.F90 -mtune=generic
-march=x86-64 -auxbase MAPL_LocStreamGet -version -fintrinsic-modules-path
/usr/local/other/SLES11.1/gcc/4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/finclude
-o MAPL_LocStreamGet.s
GNU Fortran (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/other/SLES11.1/gcc/4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/other/SLES11.1/gcc/4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/finclude
 /usr/local/intel/Composer/composer_xe_2013_sp1.0.080/mkl/include
 /gpfsm/dnb32/mbhat/TestSlurm/Installs/openmpi/1.7.2-gcc-4.8.1-shared/include

/usr/local/other/SLES11.1/gcc/4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
 /usr/local/include
 /usr/local/other/SLES11.1/gcc/4.8.1/include

/usr/local/other/SLES11.1/gcc/4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
 /usr/include
End of search list.
GNU Fortran (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
MAPL_LocStreamGet.F90: In function ‘mapl_locstreamget’:
MAPL_LocStreamGet.F90:111:0: internal compiler error: Segmentation fault
tiletype => locstream%Ptr%Local_GeoLocation(:)%t
 ^
0x4eb078 ???
../sysdeps/x86_64/elf/start.S:113
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

And running on the attached pre-processed source file, MAPL_LocStreamGet.f90:

$ gfortran -v -save-temps MAPL_LocStreamGet.f90
Driving: gfortran -v -save-temps MAPL_LocStreamGet.f90 -l gfortran -l m
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/other/SLES11.1/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /gpfsm/dnbsrc/other/GCC/SLES11/4.8.1/gcc-4.8.1/configure
--prefix=/usr/local/other/SLES11.1/gcc/4.8.1 CC=gcc --enable-languages=all
--enable-bootstrap
Thread model: posix
gcc version 4.8.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/usr/local/other/SLES11.1/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/f951
MAPL_LocStreamGet.f90 -quiet -dumpbase MAPL_LocStreamGet.f90 -mtune=generic
-march=x86-64 -auxbase MAPL_LocStreamGet -version -fintrinsic-modules-path
/usr/local/other/SLES11.1/gcc/4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/finclude
-o MAPL_LocStreamGet.s
GNU Fortran (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
MAPL_LocStreamGet.f90: In function ‘mapl_locst

[Bug target/59091] __builtin_trap calls abort for arm-linux-gnueabi

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
See https://sourceware.org/ml/libc-alpha/2013-11/msg00291.html for more
information on the glibc failure.

[Bug target/59092] New: __builtin_trap calls abort for aarch64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Bug ID: 59092
   Summary: __builtin_trap calls abort for aarch64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org

Like bug 59091.

Right now __builtin_trap calls abort on aarch64-linux-gnueabi which causes
glibc fail to build as that brings in lots of dependencies.  The arm back-end
should implement a "trap" pattern.

See https://sourceware.org/ml/libc-alpha/2013-11/msg00291.html for more
information on the glibc failure.

[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008

[tejohnson at google dot com]

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

--- Comment #23 from Teresa Johnson  ---
On Tue, Nov 12, 2013 at 11:06 AM, ubizjak at gmail dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
>
> --- Comment #22 from Uroš Bizjak  ---
> (In reply to Teresa Johnson from comment #19)
>
>> Since this was blocking my SPEC testing I took a look. The issue is
>> that the new edge_count variable is declared as an int and is
>> overflowing. It should be gcov_type. Here is the patch that fixed the
>> bzip2 failure. I will run regression and lto bootstrap testing on it:
>
> You will need additional patch to libiberty to push the lto-profiledbootstrap
> further.
>
> Unfortunately, the lto profiledbootstrap will later die in stagefeedback with:
>
>   /ssd/uros/gcc-build-profiled/./prev-gcc/xgcc
> -B/ssd/uros/gcc-build-profiled/./prev-gcc/
> -B/usr/local/x86_64-unknown-linux-gnu/bin/
> -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-c -DHAVE_CONFIG_H -g -O2
> -flto=jobserver -frandom-seed=1 -fprofile-use  -I.
> -I/home/uros/gcc-svn/trunk/libiberty/../include  -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
> /home/uros/gcc-svn/trunk/libiberty/pex-unix.c -o pic/pex-unix.o; \
> else true; fi
> if [ x"-fpic" != x ]; then \
> /home/uros/gcc-svn/trunk/libiberty/pex-unix.c:790:1: error: Missing counts for
> called function pex_child_error.isra.1/75
>  }
>  ^
> gmake[3]: *** [pex-unix.o] Error 1
> gmake[3]: *** Waiting for unfinished jobs
> gmake[2]: *** [all-stagefeedback-libiberty] Error 2
> gmake[2]: *** Waiting for unfinished jobs
> gmake[2]: Leaving directory `/ssd/uros/gcc-build-profiled'
> gmake[1]: *** [stagefeedback-bubble] Error 2
> gmake[1]: Leaving directory `/ssd/uros/gcc-build-profiled'
> gmake: *** [profiledbootstrap] Error 2

Yep, I just hit this myself while testing the badness overflow fix. It
is due to my own patch and I just sent a fix to gcc-patches for it -
this should be made into a warning for now.

Teresa

>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008

[ubizjak at gmail dot com]

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

--- Comment #22 from Uroš Bizjak  ---
(In reply to Teresa Johnson from comment #19)

> Since this was blocking my SPEC testing I took a look. The issue is
> that the new edge_count variable is declared as an int and is
> overflowing. It should be gcov_type. Here is the patch that fixed the
> bzip2 failure. I will run regression and lto bootstrap testing on it:

You will need additional patch to libiberty to push the lto-profiledbootstrap
further.

Unfortunately, the lto profiledbootstrap will later die in stagefeedback with:

  /ssd/uros/gcc-build-profiled/./prev-gcc/xgcc
-B/ssd/uros/gcc-build-profiled/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-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-c -DHAVE_CONFIG_H -g -O2
-flto=jobserver -frandom-seed=1 -fprofile-use  -I.
-I/home/uros/gcc-svn/trunk/libiberty/../include  -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic  -fpic
/home/uros/gcc-svn/trunk/libiberty/pex-unix.c -o pic/pex-unix.o; \
else true; fi
if [ x"-fpic" != x ]; then \
/home/uros/gcc-svn/trunk/libiberty/pex-unix.c:790:1: error: Missing counts for
called function pex_child_error.isra.1/75
 }
 ^
gmake[3]: *** [pex-unix.o] Error 1
gmake[3]: *** Waiting for unfinished jobs
gmake[2]: *** [all-stagefeedback-libiberty] Error 2
gmake[2]: *** Waiting for unfinished jobs
gmake[2]: Leaving directory `/ssd/uros/gcc-build-profiled'
gmake[1]: *** [stagefeedback-bubble] Error 2
gmake[1]: Leaving directory `/ssd/uros/gcc-build-profiled'
gmake: *** [profiledbootstrap] Error 2

[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak  ---
Created attachment 31200
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31200&action=edit
libiberty patch to push lto-profiledbootstrap further

Additional patch to libiberty to fix some c++ casting warnings/errors.

[Bug target/59091] New: __builtin_trap calls abort for arm-linux-gnueabi

[pinskia at gcc dot gnu.org]

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

Bug ID: 59091
   Summary: __builtin_trap calls abort for arm-linux-gnueabi
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Target: arm-linux-gnueabi

Right now __builtin_trap calls abort on arm-linux-gnueabi which causes glibc
fail to build as that brings in lots of dependencies.  The arm back-end should
implement a "trap" pattern.

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[kcc at gcc dot gnu.org]

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

--- Comment #5 from Kostya Serebryany  ---
So far we were not even able to reproduce it. 
As I told in another thread, please apply any minimal #ifdef patch to 
sanitizer_platform_limits_linux.cc to make it compile (while keeping tests
running on x86_86).

[Bug c/59090] New: Broken debug information for a function containing __sync_compare_and_swap

[kostja.osipov at gmail dot com]

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

Bug ID: 59090
   Summary: Broken debug information for a function containing
__sync_compare_and_swap
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kostja.osipov at gmail dot com

gcc 4.6.3 fails to produce a correct debuggable binary when a function uses
an atomic built-iin and an infinite loop.

In the example below a breakpoint on 'pop' never hits, even though pop is
clearly called from main.

kostja@olah ~ % cat bug.c 
void *
pop(void **ptr)
{
for (;;) {
void *p=  *ptr;
if (__sync_val_compare_and_swap(ptr, p, 0) == p)
return p;
}
}

int main()
{
void *ptr = 0;
void *val = pop(&ptr);

return 0;
}

kostja@olah ~ % gcc -O0 -g bug.c; gdb ./a.out 
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/kostja/a.out...done.
(gdb) b pop
Breakpoint 1 at 0x4004be: file bug.c, line 8.
(gdb) run
Starting program: /home/kostja/a.out 
[Inferior 1 (process 1034) exited normally]


kostja@olah ~ % gcc -O0 -ggdb -S bug.c 
kostja@olah ~ % cat bug.s 
.file"bug.c"
.text
.Ltext0:
.globlpop
.typepop, @function
pop:
.LFB0:
.file 1 "bug.c"
.loc 1 3 0
.cfi_startproc
pushq%rbp
.LCFI0:
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.LCFI1:
.cfi_def_cfa_register 6
movq%rdi, -24(%rbp)
jmp.L3
.L4:
.loc 1 8 0
nop
.L3:
.LBB2:
.loc 1 5 0
movq-24(%rbp), %rax
movq(%rax), %rax
movq%rax, -8(%rbp)
.loc 1 6 0
movq-8(%rbp), %rax
movq-24(%rbp), %rdx
movl$0, %ecx
lock cmpxchgq%rcx, (%rdx)
cmpq-8(%rbp), %rax
jne.L4
.loc 1 7 0
movq-8(%rbp), %rax
.LBE2:
.loc 1 9 0
popq%rbp
.LCFI2:
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.sizepop, .-pop
.globlmain
.typemain, @function
main:
.LFB1:
.loc 1 12 0
.cfi_startproc
pushq%rbp
.LCFI3:
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.LCFI4:
.cfi_def_cfa_register 6
subq$16, %rsp
.loc 1 13 0
movq$0, -16(%rbp)
.loc 1 14 0
leaq-16(%rbp), %rax
movq%rax, %rdi
callpop
movq%rax, -8(%rbp)
.loc 1 16 0
movl$0, %eax
.loc 1 17 0
leave
.LCFI5:
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.sizemain, .-main
.Letext0:
.section.debug_info,"",@progbits
.Ldebug_info0:
.long0xcc
.value0x2
.long.Ldebug_abbrev0
.byte0x8
.uleb128 0x1
.long.LASF0
.byte0x1
.long.LASF1
.long.LASF2
.quad.Ltext0
.quad.Letext0
.long.Ldebug_line0
.uleb128 0x2
.byte0x1
.string"pop"
.byte0x1
.byte0x2
.byte0x1
.long0x7f
.quad.LFB0
.quad.LFE0
.long.LLST0
.long0x7f
.uleb128 0x3
.string"ptr"
.byte0x1
.byte0x2
.long0x81
.byte0x2
.byte0x91
.sleb128 -40
.uleb128 0x4
.quad.LBB2
.quad.LBE2
.uleb128 0x5
.string"p"
.byte0x1
.byte0x5
.long0x7f
.byte0x2
.byte0x91
.sleb128 -24
.byte0
.byte0
.uleb128 0x6
.byte0x8
.uleb128 0x7
.byte0x8
.long0x7f
.uleb128 0x8
.byte0x1
.long.LASF3
.byte0x1
.byte0xb
.long0xc8
.quad.LFB1
.quad.LFE1
.long.LLST1
.long0xc8
.uleb128 0x5
.string"ptr"
.byte0x1
.byte0xd
.long0x7f
.byte0x2
.byte0x91
.sleb128 -32
.uleb128 0x5
.string"val"
.byte0x1
.byte0xe
.long0x7f
.byte0x2
.byte0x91
.sleb128 -24
.byte0
.uleb128 0x9
.byte0x4
.byte0x5
.string"int"
.byte0
.section.debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.uleb128 0x1
.uleb128 0x11
.byte0x1
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x10
.uleb128 0x6
.byte0
.b

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #4 from Michael Meissner  ---
It has been a week since you broke the build for powerpc64 and other targets. 
Please immediately revert these patches to allow the ports to build while you
work on patches that will not break on the major host/targets.

Quoting from the GCC development plan.

If a patch is committed which introduces a regression on any target which the
Steering Committee considers to be important and if:

the problem is reported to the original poster;
48 hours pass without the original poster or any other party indicating that a
fix will be forthcoming in the very near future;
two people with write privileges to the affected area of the compiler determine
that the best course of action is to revert the patch;
then they may revert the patch.

(The list of important targets will be revised at the beginning of each release
cycle, if necessary, and is part of the release criteria.)

After the patch has been reverted, the poster may appeal the decision to the
Steering Committee.

Note that no distinction is made between patches which are themselves buggy and
patches that expose latent bugs elsewhere in the compiler.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[octoploid at yandex dot com]

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

--- Comment #7 from Markus Trippelsdorf  ---
markus@x4 tmp % cat test.c
#include 
#include 
#include 
#include 
#include 

static sigjmp_buf jmpbuf;

static void
sig_handler (int signo)
{
  siglongjmp (jmpbuf, 1);
}

int
main (void)
{
  char *p = NULL;
  volatile int ret = 0;
  struct sigaction sa;

  sa.sa_handler = sig_handler;
  sigemptyset (&sa.sa_mask);
  sa.sa_flags = SA_SIGINFO;

  if (sigaction (SIGSEGV, &sa, 0))
{
  perror ("installing SIGSEGV handler\n");
  exit (1);
}

  puts ("Attempting to sprintf to null ptr");
  if (setjmp (jmpbuf))
{
  puts ("Exiting main...");
  return ret;
}

  sprintf (p, "This should segv\n");

  return 1;
}

markus@x4 tmp % gcc -O2 test.c && ./a.out
Attempting to sprintf to null ptr
[1]28519 illegal hardware instruction  ./a.out
markus@x4 tmp % gcc -fno-isolate-erroneous-paths -O2 test.c && ./a.out
Attempting to sprintf to null ptr
Exiting main...
markus@x4 tmp %

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[octoploid at yandex dot com]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Jeffrey A. Law from comment #5)
> I need testcases.  "the kernel" or "x.org" isn't sufficient for a variety of
> reasons.

Every program that uses a custom sig_handler which only handles
SIGSEGV will fail.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
I need testcases.  "the kernel" or "x.org" isn't sufficient for a variety of
reasons.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[octoploid at yandex dot com]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||octoploid at yandex dot com

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Jeffrey A. Law from comment #2)
> I need a compilable/complete testcase.
> 
> If a program is faulting with -fisolate-erroneous-paths, then that program
> is faulty in one way or another.  It's dereferencing a null pointer, pass a
> null argument in a situation where the argument must be non-null, or
> returning a null pointer from a function declared as returning non-null.

I'm seeing this also quite often. Xorg fails to start when
compiled with current gcc, the Linux kernel doesn't build, because
relocs (build during the kernel build) fails with illegal instruction, 
etc..
So tbe -fisolate-erroneous-paths patch should be reverted IMHO.

[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008

[pa...@matos-sorge.com]

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

--- Comment #20 from Paulo J. Matos  ---
Thanks for fixing this.

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[marxin.liska at gmail dot com]

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

--- Comment #3 from Martin Liška  ---
I've seen the same problem also in Inkscape. I will try to create a testcase.

Would it be possible Jeffrey to build one of these programs?

Thanks,
Martin

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
Unfortunately associated() does not allow unassociated array pointers as input
so your code works for allocatable arrays but not for array pointers.
Yes, a negative value for size() is good. It is a pity there are not
the human resources
for detecting and handling access to unassociated array pointers.
I stumbled into this issue by looking at abinit,
a code in the public domain. I mean this is an example taken from a
real life situation,
it is not just fabricated as an exercise.

[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008

[tejohnson at google dot com]

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

--- Comment #19 from Teresa Johnson  ---
On Mon, Nov 4, 2013 at 11:11 AM, tejohnson at google dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
>
> --- Comment #18 from Teresa Johnson  ---
> Just hit this same error with cpu2006 bzip2. The .i and .gcda are attached.
> Reproduce with:
>
> gcc -c -fprofile-use -O2 blocksort.i
>
> blocksort.c:1136:1: internal compiler error: in edge_badness, at
> ipa-inline.c:1011
>  }
>  ^
> 0xe13caa edge_badness
> /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:1011
> 0xe16935 update_edge_key
> /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:1024
> 0xe16935 inline_small_functions
> /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:1610
> 0xe16935 ipa_inline
> /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:2015
> 0xe16935 execute
> /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:2385
> Please submit a full bug report,
>
>
> Teresa

Since this was blocking my SPEC testing I took a look. The issue is
that the new edge_count variable is declared as an int and is
overflowing. It should be gcov_type. Here is the patch that fixed the
bzip2 failure. I will run regression and lto bootstrap testing on it:

2013-11-12  Teresa Johnson  

PR ipa/58862
* ipa-inline.c (edge_badness): Fix overflow.

Index: ipa-inline.c
===
--- ipa-inline.c(revision 204703)
+++ ipa-inline.c(working copy)
@@ -909,7 +909,7 @@ edge_badness (struct cgraph_edge *edge, bool dump)
   /* Capping edge->count to max_count. edge->count can be larger than
 max_count if an inline adds new edges which increase max_count
 after max_count is computed.  */
-  int edge_count = edge->count > max_count ? max_count : edge->count;
+  gcov_type edge_count = edge->count > max_count ? max_count :
edge->count;

   sreal_init (&relbenefit_real, relbenefit, 0);
   sreal_init (&growth_real, growth, 0);


Teresa

>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c/59089] sin and/or cos produce bogus results with -O2

[octoploid at yandex dot com]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||octoploid at yandex dot com

--- Comment #2 from Markus Trippelsdorf  ---
That is not a gcc issue, it's a glibc problem.
There were a lot of improvements in that area in recent months.
So I would recommend that you update your glibc to get better results.

[Bug c/59089] sin and/or cos produce bogus results with -O2

[terra at gnome dot org]

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

--- Comment #1 from M Welinder  ---
Version and arch details:

welinder@sherwood:~> gcc -v -Wall -O0 sc.c -lm
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-O0' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.7/cc1 -quiet -v sc.c -quiet -dumpbase sc.c
-mtune=generic -march=x86-64 -auxbase sc -O0 -Wall -version -o /tmp/cc9NYeac.s
GNU C (SUSE Linux) version 4.7.1 20120723 [gcc-4_7-branch revision 189773]
(x86_64-suse-linux)
compiled by GNU C version 4.7.1 20120723 [gcc-4_7-branch revision 189773],
GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/gcc/x86_64-suse-linux/4.7/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/4.7/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
GNU C (SUSE Linux) version 4.7.1 20120723 [gcc-4_7-branch revision 189773]
(x86_64-suse-linux)
compiled by GNU C version 4.7.1 20120723 [gcc-4_7-branch revision 189773],
GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e3eb1496554b3c5a9dcd68c49e292596
COLLECT_GCC_OPTIONS='-v' '-Wall' '-O0' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/as -v
--64 -o /tmp/ccOxQnNc.o /tmp/cc9NYeac.s
GNU assembler version 2.22 (x86_64-suse-linux) using BFD version (GNU Binutils;
openSUSE 12.2) 2.22
COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.7/:/usr/lib64/gcc/x86_64-suse-linux/4.7/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.7/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.7/:/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Wall' '-O0' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.7/collect2 --build-id --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../lib64/crt1.o
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/4.7/crtbegin.o
-L/usr/lib64/gcc/x86_64-suse-linux/4.7
-L/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.7/../../.. /tmp/ccOxQnNc.o -lm -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib64/gcc/x86_64-suse-linux/4.7/crtend.o
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../lib64/crtn.o

[Bug c/59089] New: sin and/or cos produce bogus results with -O2

[terra at gnome dot org]

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

Bug ID: 59089
   Summary: sin and/or cos produce bogus results with -O2
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org

Created attachment 31199
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31199&action=edit
sc.c

welinder@sherwood:~> gcc --version
gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773]

When sin(x) and cos(x) are used near each other and -O2 is active,
results are utterly unreliable:

welinder@sherwood:~> gcc -Wall -O0 sc.c -lm
welinder@sherwood:~> ./a.out 1e19
cot(1e+19) = 0.40440089012342833596
welinder@sherwood:~> gcc -Wall -O2 sc.c -lm
welinder@sherwood:~> ./a.out 1e19
cot(1e+19) = 0.60484784464511465174



Reference value from
http://www.wolframalpha.com/input/?i=Cot[10^19]&a=TrigRD_R
--> 0.40440089012342830052606419647330231956673028985010736178...

Further info: -O2 uses sincos, not sin and cos:

welinder@sherwood:~> gcc -Wall -O2 sc.c
/tmp/ccouebOR.o: In function `gnm_cot':
sc.c:(.text+0xd): undefined reference to `sincos'
collect2: error: ld returned 1 exit status
welinder@sherwood:~> gcc -Wall -O0 sc.c
/tmp/ccR0uAFj.o: In function `gnm_cot':
sc.c:(.text+0x1b): undefined reference to `sin'
sc.c:(.text+0x3a): undefined reference to `cos'
collect2: error: ld returned 1 exit status

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-12
 CC||glisse at gcc dot gnu.org
Summary|including complex.h in  |Issues including complex.h
   |C++11/1y mode should not|in C++11/1y mode because of
   |include C's complex.h   |C's complex.h
 Ever confirmed|0   |1

--- Comment #3 from Marc Glisse  ---
Thanks, there are several issues.

> C's  provides a macro named 'I' and this breaks existing codes.

Well, just include  if that's what you need, and if you include
, expect its natural content (except possibly for the macro
"complex").

> ext/pod_char_traits.h

This needs uglifying indeed.

> boost/iterator/iterator_facade.hpp

They should use a less risky name.

> and, anyway, C's complex doesn't work on C++11 mode.
> gcc4.8.2 c++11) http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1

Ah, user-defined literals... I'll let the experts comment.

> gcc4.8.2 c++03) http://melpon.org/wandbox/permlink/QrBInjH6rlRs2Jdl
> 
> 
> Or, if C++'s  includes C's one, I think also  should
> behave so (I think 26.4.10 is incomprehensible.)

Maybe (it mostly shouldn't have existed in the first place), indeed. Might be
as simple as making it include complex.h instead of complex.

[Bug target/59088] -mtune=core-avx2 doesn't turn on SSE unaligned load/store

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.0   |4.8.3

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug target/59088] -mtune=core-avx2 doesn't turn on SSE unaligned load/store

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Nov 12 14:38:49 2013
New Revision: 204703

URL: http://gcc.gnu.org/viewcvs?rev=204703&root=gcc&view=rev
Log:
Turn on SEE unaligned load and store for Haswell

Backported from mainline
PR target/59088
* config/i386/i386.c (initial_ix86_tune_features): Set
X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL and
X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL for m_HASWELL.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c

[Bug libstdc++/59087] including complex.h in C++11/1y mode should not include C's complex.h

[kikairoya at gmail dot com]

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

--- Comment #2 from Tomohiro Kashiwada  ---
C's  provides a macro named 'I' and this breaks existing codes.

ext/pod_char_traits.h
gcc4.8.2) http://melpon.org/wandbox/permlink/qb87YqrI7I4BAQRw
gcc4.7.3) http://melpon.org/wandbox/permlink/ighn7hGeL2tFXj16

boost/iterator/iterator_facade.hpp
gcc4.8.2) http://melpon.org/wandbox/permlink/VERBb6mK69nva2ML
gcc4.7.3) http://melpon.org/wandbox/permlink/ujalJUbClOd9FjFg


and, anyway, C's complex doesn't work on C++11 mode.
gcc4.8.2 c++11) http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1
gcc4.8.2 c++03) http://melpon.org/wandbox/permlink/QrBInjH6rlRs2Jdl


Or, if C++'s  includes C's one, I think also  should
behave so (I think 26.4.10 is incomprehensible.)

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Tue, Nov 12, 2013 at 08:13:14AM +, zeccav at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
> 
> --- Comment #7 from Vittorio Zecca  ---
> I believe most times a code knows if and when the size of an array
> must be nonzero, so a zerosize array would raise suspicions in
> those cases.

Given the description of the return value for SIZE(), a
better value would be -1 as -1 is not a possible return
for valid code.  Using a negative value for {L|U}BOUND
does not work as well as the bounds can be negative.

> Anyway in my opinion gfortran run time should detect when an
> unallocated/unassociated array is referenced and should raise
> an error situation, except for allocated intrinsic function.
> Only if that were impossible or too much time consuming

And here is your answer.  Time.  Someone would need to rewrite
a (possibly large?) chunk of the compiler (and be available
to fix the new bugs introduced).

> I would suggest to force it as a zerosize array
> with one as lower bound and zero as upper bound for each dimension.
> A clever code should detect that something is wrong and take the right
> action (crashing?).

A clever code would not access an unallocated or unassociated entity.
The clever programmer would have written

   if (allocated(a)) then
  ! Do stuff with a
   end if

or 

   if (.not. allocated(a)) allocate(a(some_arra_spec)

Yes, I'm aware that a programmer may want to write

   subroutine foo(a)
   real b(size(a))

where it is not possible to use the ALLOCATED (or ASSOCIATED) intrinsic.
Of course, using a block if-statement as shown above would prevent 
calling foo with an unallocated (or unassociated) entity.

[Bug c/59084] Sub-optimal vector moves in AVX2 vectorized loop for unaligned loads.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug target/59088] -mtune=core-avx2 doesn't turn on SSE unaligned load/store

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
   Target Milestone|--- |4.9.0
Summary|-mtune=core-avx2 doesn't|-mtune=core-avx2 doesn't
   |turn on unaligned   |turn on SSE unaligned
   |load/store  |load/store

[Bug target/59088] -mtune=core-avx2 doesn't turn on unaligned load/store

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Nov 12 13:52:08 2013
New Revision: 204701

URL: http://gcc.gnu.org/viewcvs?rev=204701&root=gcc&view=rev
Log:
Turn on SEE unaligned load and store for Haswell

PR target/59088
* config/i386/x86-tune.def (X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL):
Set for m_HASWELL.
(X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL): Set for m_HASWELL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/x86-tune.def

[Bug target/59088] New: -mtune=core-avx2 doesn't turn on unaligned load/store

[hjl.tools at gmail dot com]

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

Bug ID: 59088
   Summary: -mtune=core-avx2 doesn't turn on unaligned load/store
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

For Haswell, -mtune=core-avx2 should turn on unaligned load/store.

[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902

[evstupac at gmail dot com]

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

--- Comment #4 from Stupachenko Evgeny  ---
Not reproduced on trunk(4.9) any more.
Still reproduced on 4.8.

[Bug rtl-optimization/58934] [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Martin Jambor  ---
[...]
> If anyone is willing to test the patch on any platform but especially
> on those which I could not, I'd be very grateful.  Thanks.

I've now regression-tested the patch on sparc-sun-solaris2.11.
Bootstrap works and I find just a single regression:

FAIL: gfortran.fortran-torture/execute/pr32604.f90 execution,  -O2
-fbounds-check 

which is reproducible.

Rainer

[Bug c/59084] Sub-optimal vector moves in AVX2 vectorized loop for unaligned loads.

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Nov 12 13:26:51 2013
New Revision: 204700

URL: http://gcc.gnu.org/viewcvs?rev=204700&root=gcc&view=rev
Log:
Properly handle AVX256 unaligned load and store

PR target/59084
* config/i386/i386.c (ix86_option_override_internal): Check
X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL and
X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL for
MASK_AVX256_SPLIT_UNALIGNED_LOAD and
MASK_AVX256_SPLIT_UNALIGNED_STORE.

* config/i386/x86-tune.def (X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL):
Clear m_COREI7_AVX and update comments.
(X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/x86-tune.def

[Bug libstdc++/59087] including complex.h in C++11/1y mode should not include C's complex.h

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
That's an extension, it is done on purpose for compatibility with C code. IMHO
the standard's decision to replace C's complex.h with something completely
unrelated was nonsense.

Did that cause real problems for you?

[Bug rtl-optimization/10474] shrink wrapping for functions

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor  ---
Author: jamborm
Date: Tue Nov 12 12:53:53 2013
New Revision: 204698

URL: http://gcc.gnu.org/viewcvs?rev=204698&root=gcc&view=rev
Log:
2013-11-12  Martin Jambor  

PR rtl-optimization/10474
* ira.c (interesting_dest_for_shprep): New function.
(split_live_ranges_for_shrink_wrap): Likewise.
(find_moveable_pseudos): Move calculation of dominance info,
df_analysios and the final anlyses to...
(ira): ...here, call split_live_ranges_for_shrink_wrap.

testsuite/
* gcc.dg/pr10474.c: New testcase.
* gcc.dg/ira-shrinkwrap-prep-1.c: Likewise.
* gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
trunk/gcc/testsuite/gcc.dg/pr10474.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/59087] New: including complex.h in C++11/1y mode should not include C's complex.h

[kikairoya at gmail dot com]

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

Bug ID: 59087
   Summary: including complex.h in C++11/1y mode should not
include C's complex.h
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kikairoya at gmail dot com

working draft N3691 says:

 26.4.10 Header 
  The header behaves as if it simply includes the header .

 D.5 C standard library headers
  Every C header, each of which has a *name* of the form *name.h*, behaves as
  if each name placed in the standard library namespace by the corresponding
  *cname* header is placed within the global namespace scope.


so, including  should behaves as same as including 
except namespace scope, but libstdc++'s one includes system's
 unnecessarily.

[Bug fortran/58913] Segmentation fault on real128 array

[rrodrigues at poli dot ufrj.br]

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

--- Comment #10 from Rodrigo Rodrigues  ---
(In reply to Steve Kargl from comment #8)
> On Tue, Oct 29, 2013 at 08:39:15PM +, rrodrigues at poli dot ufrj.br
> wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58913
> > 
> > --- Comment #7 from Rodrigo Rodrigues  ---
> > Here goes the backtrack:
> > 
> > #0  0x in ?? ()
> > #1  0x0042d483 in output_float_FMT_G_16 (comp_d=, 
> > zero_flag=, sign_bit=, 
> > size=, buffer=, m=, 
> > f=0x22fb6c, dtp=)
> > at ../../../gcc-4.8.0-mingw/libgfortran/io/write_float.def:1112
> > #2  write_float (dtp=dtp@entry=0x22fcf8, f=f@entry=0x22fbbc, 
> > source=source@entry=0x22fe70 "", len=len@entry=16, 
> > comp_d=comp_d@entry=1)
> > at ../../../gcc-4.8.0-mingw/libgfortran/io/write_float.def:1259
> 
> Unfortnately, your trace suggests to me that this is MingW 
> specific.  I can't help beyond this point.  Prehaps, ping 
> the MingW developers?

Well, as I got gfortran binaries from http://www.equation.com/
I've contacted the Equation Team and they confirmed that that is a platform
specific bug. They addressed this bug and recommended to not use real128 float
numbers.

So I think that this bug report can be closed here. Thank you for the
attention.

[Bug c++/29143] address-of overloaded function does not work in function call

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #5 from Paolo Carlini  ---
Mine.

[Bug regression/59086] New: error: ‘asm’ operand has impossible constraints

[aivchenk at gmail dot com]

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

Bug ID: 59086
   Summary: error: ‘asm’ operand has impossible constraints
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gmail dot com

Android image build with trunk gcc failed after the following commit:

Author: hubicka 
Date:   Thu Oct 3 17:25:42 2013 +

* i386.c (ix86_option_override_internal): Do not enable
accumulate-outgoing-args when producing unwind info.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@203171
138bc75d-0d04-0410-961f-82ee72b054a4

==

The reduced testcase looks something like this
(previous r203169 is able to compile it):

#include 

void testFunc(int count) {

  int x;
  __m128i tmp1;
  __asm__(
  "1:\n"
  :"+d"(x)
  :[count] "m" (count), [tmp1] "m" (tmp1)
  :"ecx","esi","edi","eax"
  );
}

The compiling options:
gcc test.c -c -fPIC -mstackrealign -march=core-avx2 -m32

[Bug c++/57734] Returning template alias to enum class fails with "invalid declarator"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug c++/57734] Returning template alias to enum class fails with "invalid declarator"

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Nov 12 09:21:45 2013
New Revision: 204697

URL: http://gcc.gnu.org/viewcvs?rev=204697&root=gcc&view=rev
Log:
/cp
2013-11-12  Paolo Carlini  

PR c++/57734
* pt.c (lookup_template_class_1): Handle alias template declarations
of enumeration types.

/testsuite
2013-11-12  Paolo Carlini  

PR c++/57734
* g++.dg/cpp0x/alias-decl-enum-1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-enum-1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Just had a quick look at 3dview.c and indeed, the only swap of arguments I see
is due to different SSA_NAME_VERSIONs being used by reassoc1 (that is not a
bug) and
then during copyprop5 when a stmt is folded using fold_stmt,
tree_swap_operands_p is called and that prefers for commutative operands
operand with smaller SSA_NAME_VERSION first.  So yes, there can be small code
generation differences, and there is I'm afraid nothing that can be done about
that.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[eugeni.stepanov at gmail dot com]

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

--- Comment #8 from Evgeniy Stepanov  ---
I'm a little surprised we did not run into this on Android yet - we use the
same LD_PRELOAD scheme there. Are you linking libasan with libpthread? This
might go away as libpthread constructors call one of the ASan interceptors that
does ENSURE_ASAN_INITED(). Arguably, all interceptors should do it.

I think Kostya raises valid points, but still, adding attribute((constructor))
is reasonable.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

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

--- Comment #7 from Yury Gribov  ---
(In reply to Kostya Serebryany from comment #6)
> adding attribute ctor to __asan_init is questionable
> - windows has different syntax.

We'll fix that (see the obsolete patch).

> - running non-instrumented binary w/o calling __asan_init at startup is
> risky: the binary may call memset/etc an touch shadow memory, which is not
> initialized before __asan_init

Sorry, I didn't understand. The proposal is to call __asan_init at startup so
that we don't have this problem.

[Bug tree-optimization/58121] [4.9 regression] FAIL: cc1224a

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Andreas Schwab  ---
Fixed between r202487 and r202587.

[Bug c++/59085] New: internal compiler error: Segmentation fault

[filip.7an at gmail dot com]

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

Bug ID: 59085
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: filip.7an at gmail dot com

Created attachment 31198
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31198&action=edit
The preprocessed file

When compiling a small piece of C++11 code the compiler encountered a fatal
error -segmentation fault- which does not allow the compilation to proceed.

The problem first appear when I start using a thread_local static variable -of
stringstream type- in a template class.

The g++ version in use is:

.
g++ (rev5, Built by MinGW-W64 project) 4.8.1
.

The compilation command is:

.
g++ --std=c++11 main.cpp -v -save-temps -o test.exe
.

OS Windows 7 SP 1.

Attached is available the preprocessed file of a piece of code which generate
the fault.

Compiler output:

d:\Logger - Copy>g++ --std=c++11 main.cpp -v -save-temps -o test.exe
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/program\
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 -
-with-sysroot=/tmp/x64-481-posix-seh-r5/mingw64 --enable-shared --enable-static
--disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,l
to --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic
-string --enable-version-specific-runtime-libs --disable-isl-version-check
--disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-d
ebug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-a
rch=nocona --with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpfr=/tmp/mingw-prereq/x
86_64-w64-mingw32-static --with-mpc=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-isl=/tmp/mingw-prereq/x86_64-w64-mingw32-static --with-cloog=/t
mp/mingw-prereq/x86_64-w64-mingw32-static --enable-cloog-backend=isl
--with-pkgversion='rev5, Built by MinGW-W64 project'
--with-bugurl=http://sourcef
orge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/tmp/x64-481-posix-seh-r5/libs/include -I/tmp/mingw-prereq/x64-zlib/include
-I/tmp/mingw-prereq/x86_64
-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/tmp/x64-481-posix-seh-r5/libs/include -I/tmp/mingw-prereq/x64-zlib/include
-I/tmp/mingw-prereq/x86
_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe
-L/tmp/x64-481-posix-seh-r5/libs/lib -L/tmp/mingw-prereq/x64-zlib/lib
-L/tmp/mingw-prereq/x86
_64-w64-mingw32-static/lib -L/tmp/x64-481-posix-seh-r5/mingw64/opt/lib '
Thread model: posix
gcc version 4.8.1 (rev5, Built by MinGW-W64 project)
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-o' 'test.exe'
'-shared-libgcc' '-mtune=core2' '-march=nocona'
 c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/cc1plus.exe
-E -quiet -v -iprefix c:\progr
am
files\mingw-builds\x64-4.8.1-posix-seh-rev5\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.8.1/
-D_REENTRANT main.cpp -mtune=core2 -march=nocona -std=
c++11 -fpch-preprocess -o main.ii
ignoring duplicate directory "c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.8.1/include/c+
+"
ignoring duplicate directory "c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.8.1/include/c+
+/x86_64-w64-mingw32"
ignoring duplicate directory "c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.8.1/include/c+
+/backward"
ignoring duplicate directory "c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.8.1/include"
ignoring nonexistent directory
"C:/Temp/msys64/tmp/x64-481-posix-seh-r5/mingw64C:/Temp/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../inc
lude"
ignoring duplicate directory "c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.8.1/include-fi
xed"
ignoring duplicate directory "c:/program
files/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../.
./x86_64-w64-mingw32/include"
ignoring nonexistent directory
"C:/Temp/msys64/tmp/x64-481-posix-seh-r5/mingw64/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\program
files\mingw-builds\x64-4.8.1-posix-seh-rev5\mingw64\bin\../lib/gcc/x86_64

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[kcc at gcc dot gnu.org]

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

--- Comment #6 from Kostya Serebryany  ---
adding attribute ctor to __asan_init is questionable
- windows has different syntax.
- running non-instrumented binary w/o calling __asan_init at startup is risky:
the binary may call memset/etc an touch shadow memory, which is not initialized
before __asan_init

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
I believe most times a code knows if and when the size of an array
must be nonzero,
so a zerosize array would raise suspicions in those cases.
Anyway in my opinion gfortran run time should detect when an
unallocated/unassociated array
is referenced and should raise an error situation, except for
allocated intrinsic function.
Only if that were impossible or too much time consuming
I would suggest to force it as a zerosize array
with one as lower bound and zero as upper bound for each dimension.
A clever code should detect that something is wrong and take the right
action (crashing?).

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[samsonov at google dot com]

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

Alexey Samsonov  changed:

   What|Removed |Added

 CC||eugeni.stepanov at gmail dot 
com,
   ||glider at google dot com

--- Comment #5 from Alexey Samsonov  ---
+eugenis,glider

Do we have any similar issues on systems where we use dynamic ASan runtime
ourselves (Mac and Android)?