[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
int bar (void);

int
foo ()
{
  if (_Cilk_spawn bar ())
return 5;
  return 0;
}

Whether this is valid Cilk+ or not, no idea.

[Bug other/60816] Optimzed arm code generates infinite loop via branch instruction branching to current program counter

[andrew.j.c.parker at gmail dot com]

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

--- Comment #2 from Andrew Parker  ---
Ach, my bad.  This snippet came from some old code that started failing with
4.8.  I whittled it down for the example but didn't vet it closely enough. 
Looks like a bug in our code!  Thanks for poiting out the obvious.  Apols for
the waste of time.

[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Severity|critical|normal

--- Comment #1 from Jakub Jelinek  ---
You haven't said which target it is, and we need preprocessed source as well.
Couldn't reproduce this on x86_64-linux.

[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Are you going to commit the testcase to the trunk too?

[Bug target/60818] New: ICE in validate_condition_mode on powerpc-e500v2-linux-gnuspe

[asolokha at gmx dot com]

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

Bug ID: 60818
   Summary: ICE in validate_condition_mode on
powerpc-e500v2-linux-gnuspe
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com

gcc 4.9.0-alpha20140406 segfaults when compiling the following code for target
powerpc-e500v2-linux-gnuspe w/ optimization levels -O1 and above:

int d7;

static int
ca(int l3)
{
  for (d7 = 0; d7 < 1; ++d7)
;
  return l3;
}

int
c9(void)
{
  int yj;
  return ca(((yj != 1) & 65535U) > d7);
}

% powerpc-e500v2-linux-gnuspe-gcc -O1 -c 62931f03.c 
62931f03.c: In function 'c9':
62931f03.c:16:1: internal compiler error: in validate_condition_mode, at
config/rs6000/rs6000.c:15657

[Bug target/60817] New: gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as

[redlizard at redlizard dot nl]

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

Bug ID: 60817
   Summary: gcc configure script misdetects TLS support on
x86_64-pc-solaris* with gnu as
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redlizard at redlizard dot nl

Created attachment 32584
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32584&action=edit
Proposed patch.

When building gcc >= 4.7 on x86_64-pc-solaris2.11 --with-gnu-as, the
gcc/configure script incorrectly decides that gnu as does not support real TLS,
and so unnecessarily decides to activate emutls instead.

The solaris-specific test checks this support by trying to assemble a piece of
TLS-using assembly code, and it uses the same 32-bit code for this test both on
32-bit and 64-bit platforms. The solaris assembler will accept this, but gnu as
fails on the 32 bit code when targeting x86_64-pc-solaris*, thus causing the
detection to fail.

Attached patch for 4.9 fixes the problem, and is trivially backported to 4.8
and 4.7.

[Bug other/60816] Optimzed arm code generates infinite loop via branch instruction branching to current program counter

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Adding:
__builtin_printf("index1 = %d, index2 = %d.\n", iIndex - (i0or1 - 1), (
iIndex - i0or1 ));


Shows the reason why it is optimized to an infinite loop:
index1 = 1000, index2 = 999.

You are accessing one outside the bounds of the array.

[Bug fortran/60810] [4.9 Regression] list directed io from array results in end of file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Is that the r208591 (and for 4.8 r208595) change that changed the behavior?

[Bug other/60816] New: Optimzed arm code generates infinite loop via branch instruction branching to current program counter

[andrew.j.c.parker at gmail dot com]

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

Bug ID: 60816
   Summary: Optimzed arm code generates infinite loop via branch
instruction branching to current program counter
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.j.c.parker at gmail dot com

Created attachment 32583
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32583&action=edit
Zip file containing repro cpp, compiler output, preprocessed file and GCC build
script

The bug is with GCC 4.8.3 compiler for ARM bare metal.  It has been produced on
both:

build=linux (ubuntu) host=Windows target=arm
build=osx host=osx target=arm

The source comes from https://launchpad.net/gcc-arm-embedded/+download,
specifically the q1 release
https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-src.tar.bz2.
 

I have also reproduced it with the Android NDK r9 and the arm 4.8 toolchain. 
The bug isn't present in 4.7.4.

Attached is a simple cpp file attached to reproduce bug.  Command line is:

gcc -c -O3 compiler_bug.cpp

The unlinked object file exhibits the problem.  The generated assembly for the
main function is:

 :
   0:eafe b0 

There are some comments in the code about what changes you can make to "remove"
the bug.

Also attached is the compiler output and the preprocessed .ii file.

[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand

[sambler at alumni dot nd.edu]

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

--- Comment #2 from Stuart Ambler  ---
Using gdb on my code, it appears that the immediate problem is caused by what
gthr-default.h and/or gthr-posix.h do to detect whether a program is
multi-threaded, which they seem to assume is ok as a precondition for using
call_once.  I think they do this with the code
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
 __pthread_key_create,
 pthread_key_create)
# define GTHR_ACTIVE_PROXY__gthrw_(__pthread_key_create)

Just after that code is

static inline int
__gthread_active_p (void)
{
  static void *const __gthread_active_ptr
= __extension__ (void *) >HR_ACTIVE_PROXY;
  return __gthread_active_ptr != 0;
}

This function is called by __gthread_once, which if __gthread_active_p()
returns false, does nothing other than return -1, which results in call_once
throwing a system_error.

__pthread_key_create is a function in libpthread, which my gcc command line
links with.  It's possible to display the value of __gthread_active_ptr in
main, and it's 0 at a point before call_once is called and the error is thrown,
unless the this_thread::sleep_for code is uncommented, in which case
__gthread_active_ptr is not 0 and there is no problem.

It's not necessary for the this_thread::sleep to be executed to avoid the
problem.  Putting that line in a function in the same source file as main also
results in nonzero __gthread_active_ptr and no problem, even if the function is
never called.

I thought it might depend on order of loading the libraries and gave gcc the
-static option to hopefully have more control over that.  Giving gcc also -v
libpthread is listed before libstdc++.  But with static linking,
__gthread_active_ptr is 0 and the problem occurs whether or not the
this_thread::sleep_for is present.  So I gave up on static linking.

this_thread::sleep_for calls nano_sleep, which libpthread exports.  I don't
know much about the linux linker, but it seems that somehow the existence of
this call to nano_sleep, even if not executed, causes libpthread to be loaded
in a way that gives a nonzero value for __gthread_active_ptr when it is
checked.

Though it may work differently on different systems, it seems like the problem
may revolve around an assumption that call_once won't be called except by a
multi-threaded program, and a perhaps somewhat fragile way of determining
whether it's a multi-threaded program.

If you still think I should report it to Ubuntu, I will.

Thanks.

[Bug fortran/60810] [4.9 Regression] list directed io from array results in end of file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-11
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Confirmed.

Works on 4.6, fails on 4.7, 4.8, and 4.9.

I have to think about this a bit.  I could see an end-of-record message would
be possibly the right behavior since each array element is treated as a record.

On the other hand, ifort accepts this.  So I wonder what other compilers do.

[Bug debug/60815] Inconsistent prologue line table location

[dblaikie at gmail dot com]

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

--- Comment #1 from David Blaikie  ---
Oh - and if we can confirm the direction you're going with this (if the
decision is that the prologue should start, like Clang, at the opening '{'
always, for example) I'll go ahead and update the GDB test suite to either be
agnostic or to KFAIL those tests under GDB, referencing this bug.

[Bug debug/60815] New: Inconsistent prologue line table location

[dblaikie at gmail dot com]

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

Bug ID: 60815
   Summary: Inconsistent prologue line table location
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dblaikie at gmail dot com
CC: ccoutant at gcc dot gnu.org, echristo at gmail dot com
  Host: x86_64
Target: x86_64

Given:

template
void func() // prologue
{
}

template void func();

void f2()
{ // prologue
}

struct foo {
  void f3() // GCC prologue
  {
  }
  void f4();
};

void (foo::*x)() = &foo::f3;

void foo::f4()
{ // prologue
}

GCC's line table shows the prologue of both of these functions as the line of
the function name, not the opening '{'. Yet if these functions are
non-templates or out-of-line, the prologue starts at the opening brace, not the
function name.

(backstory: Clang consistently uses the opening brace but fails some GDB tests
that rely on GCC's behavior, even though it's inconsistent (see
gdb.cp/cpexprs.exp for some examples). It'd be great if both GCC and Clang
could agree on this, one way or another, but if not, the GDB tests can of
course be made resilient to the difference by simply putting the '{' on the
same line as the function name)

[Bug middle-end/60814] incorrect integer promotion when multiplying unsigned short values

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is undefined code as 0x*0x overflows int.
x * y is really
((int)x) * ((int)y)

So if that overflows and since we know that both (int)x and (int)y are both
positive integer since we are converting from unsigned short to int; the result
of ((int)x) * ((int)y) will also be positive (since overflow of signed integer
is undefined) we can remove the cast between int and unsigned int and go
directly to unsigned long long in a valid way.

[Bug middle-end/60814] New: incorrect integer promotion when multiplying unsigned short values

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 60814
   Summary: incorrect integer promotion when multiplying unsigned
short values
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Created attachment 32582
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32582&action=edit
incorrect integer promotion

The attached program triggers an optimizer bug with -O2 or -O3 (it performs
correctly with -O1 or -O0).

The unsigned -> unsigned long long promotion should be unsigned, but gcc
incorrectly performs signed promotion.

This bug seems to be architecture-independent, it was reproduced on:
4.7.2 (Debian 4.7.2-5) on i486-linux-gnu
4.7.2 (Debian 4.7.2-5) on ia64-linux-gnu
4.7.2 (Debian 4.7.2-5) on s390x-linux-gnu
4.7.3 on hppa-linux-gnu
4.8.2 on x86_64-unknown-linux-gnu (the bug is in 32-bit, 64-bit and x32 mode)
4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1) on arm-linux-gnueabihf
4.8.2 (Debian 4.8.2-16) on alpha-linux-gnu

The bug doesn't happen in gcc 4.6.4.

[Bug c++/58600] [c++11] ICE on wrong usage of alignas

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Apr 10 23:22:10 2014
New Revision: 209285

URL: http://gcc.gnu.org/viewcvs?rev=209285&root=gcc&view=rev
Log:
2014-04-10  Vladimir Makarov  

PR rtl-optimization/60769
* lra-constraints.c (simplify_operand_subreg): Force reload of
paradoxical subreg if it is not in the class contents.

2014-04-10  Vladimir Makarov  

PR rtl-optimization/60769
* g++.dg/pr60769.C: New.


Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/pr60769.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/lra-constraints.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/57926] Atomic functions broken with C++ but not C?

[lailavrazda1979 at gmail dot com]

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

--- Comment #16 from lailavrazda1979 at gmail dot com ---
Okay, no worries.

[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all

[mircea.namolaru at inria dot fr]

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

--- Comment #19 from Mircea Namolaru  ---

The problem for many of these simple cases is with Graphite formulation of
memory accesses constraints. For Fortran, or C (if arrays are declared as
pointers), a memory access is not constrained enough (basically it is expressed
as a function of a single induction variable). This may increase dramatically
the number of the constraint solutions. The computation time for them could
become prohibitive as well. But even worse, even if the computation finishes,
part of the solutions found are false dependencies restricting possible legal
transformations.

The solution is to constrain more the memory access - as it is done for C
arrays
(similar code in C as this Fortran example don't create any problem).
A possible solution is to express the access in terms of basic induction
variable as in the original source code - maybe by modifying the front end.
But other solutions are possible. For sure not a work for GCC 4.9.

[Bug fortran/60813] New: [Coarray] substrings mishandled

[burnus at gcc dot gnu.org]

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

Bug ID: 60813
   Summary: [Coarray] substrings mishandled
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The following substring reference gives the bogus:

   Error: Rank mismatch in array reference at (1) (1/0)

character(len=5), save :: str[*]
print *, str(j:j)
end


While the following (array section) is rejected - but with the wrong error
message. It should state that "str" is a scalar. (Correct syntax for a
substring would be "str[1](j:j)".)

character(len=5), save :: str[*]
print *, str(j:j)[1]
end

[Bug debug/60812] New: gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[geir at cray dot com]

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

Bug ID: 60812
   Summary: gcc -g -gpubnames statically linked produces a
.debug_pubnames that is wrong or corrupted
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com

gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or
corrupted:

$ gcc --version
gcc (GCC) 4.8.2 20131016 (Cray Inc.)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat getpid.c
#include 

int main() {
return getpid();
}
$ gcc -c -g -gpubnames getpid.c
$ gcc -o getpid getpid.o -static
$ readelf -wp getpid
Contents of the .debug_pubnames section:

  Length:  33
  Version: 2
  Offset into .debug_info section: 0x77
  Size of area in .debug_info section: 139

Offset  Name
6f  _IO_stdin_used
  Length:  7091
  Version: 2
  Offset into .debug_info section: 0x102
  Size of area in .debug_info section: 145

Offset  Name
73  main
readelf: Warning: .debug_info offset of 0x6e65706f in .debug_pubnames section
does not point to a CU header.
readelf: Warning: Only DWARF 2 and 3 pubnames are currently supported

$


   The .debug_pubnames section of the getpid.o object file is fine:

$ readelf -wp getpid.o
Contents of the .debug_pubnames section:

  Length:  7091
  Version: 2
  Offset into .debug_info section: 0x0
  Size of area in .debug_info section: 145

Offset  Name
73  main

$


   The .debug_pubnames section of a dynamically linked executable is also fine:

$ gcc -o getpid-dynamic getpid.o
$ readelf -wp getpid-dynamic
Contents of the .debug_pubnames section:

  Length:  33
  Version: 2
  Offset into .debug_info section: 0x77
  Size of area in .debug_info section: 139

Offset  Name
6f  _IO_stdin_used
  Length:  7091
  Version: 2
  Offset into .debug_info section: 0x102
  Size of area in .debug_info section: 145

Offset  Name
73  main

$


Problem is severely impacting the operation of performance analysis tools that
need to use this information.

[Bug c/60784] Spurious -Wmissing-field-initializers warning for anonymous structure

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
This regtested/bootstrapped patch fixes it, but I'm not fully confident it's
the Right Place.  The problem is that constructor_designated wasn't set
properly when entering pop_init_level from c_parser_braced_init, since
push_init_level called earlier set it to 0.

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 65aad45..9813698 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -7750,6 +7750,7 @@ set_init_label (tree fieldname, struct obstack *
braced_init_obstack)
 do
   {
constructor_fields = TREE_VALUE (field);
+   constructor_designated = 1;
designator_depth++;
designator_erroneous = 0;
if (constructor_range_stack)

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[edlinger at gcc dot gnu.org]

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

--- Comment #16 from edlinger at gcc dot gnu.org ---
Author: edlinger
Date: Thu Apr 10 20:13:23 2014
New Revision: 209282

URL: http://gcc.gnu.org/viewcvs?rev=209282&root=gcc&view=rev
Log:
moved this ChangeLog entry to fortran/ChangeLog
2014-04-04  Bernd Edlinger  

PR fortran/60191
* fortran/trans-types.c (gfc_get_function_type): In case of recursion
build a variadic function type with empty argument list instead of a
stdarg-like function type with incomplete argument list.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/fortran/ChangeLog

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #22 from Jakub Jelinek  ---
Fixed.

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 18:57:48 2014
New Revision: 209280

URL: http://gcc.gnu.org/viewcvs?rev=209280&root=gcc&view=rev
Log:
PR lto/60567
* ipa.c (function_and_variable_visibility): Copy forced_by_abi flag from
decl_node to node.

* g++.dg/lto/pr60567_0.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr60567_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fortran/ChangeLog
trunk/gcc/ipa.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 32581 [details]
> gcc49-pr60567.patch
> 
> The ipa.c version (changing node->forced_by_abi instead of
> decl_node->forced_by_abi), also bootstrapped/regtested on i686-linux and
> bootstrapped on x86_64-linux with regtest still ongoing there.

Regtested fine even on x86_64-linux.

[Bug c/60809] C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

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

--- Comment #5 from jimis  ---
Andreas: On a second thought, this paragraph only talks about the order
*within* the initialisation list. But no matter of that order, the
initialisation list is always evaluated to:

{
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
AI_PASSIVE
};


The outer assignment to query2, should never set ai_flags, no matter what the
side-effects of the inner assignments are. Am I thinking right?

[Bug target/60811] New: arc/arc.c:2135: possible bad argument to abs

[dcb314 at hotmail dot com]

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

Bug ID: 60811
   Summary: arc/arc.c:2135: possible bad argument to abs
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Static analyser cppcheck says

[trunk/gcc/config/arc/arc.c:2135]: (error) Invalid abs() argument nr 1. A
non-boolean value is required.

Source code is

gcc_assert (epilogue_p || abs (*first_offset <= 127));

Maybe better code might be

gcc_assert (epilogue_p || abs (*first_offset) <= 127);

[Bug fortran/60810] New: [4.9 Regression] list directed io from array results in end of file

[orion at cora dot nwra.com]

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

Bug ID: 60810
   Summary: [4.9 Regression] list directed io from array results
in end of file
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orion at cora dot nwra.com

This program:

program readstrlist
  character(len=80), dimension(2) :: ver
  integer :: a, b, c

  ver(1) = '285 383'
  ver(2) = '985'

  read( ver, *) a, b, c
  write ( *, *) a, b, c
end

Outputs:
At line 8 of file readstrlist.f90
Fortran runtime error: End of file

with:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.9.0-20140409/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.0-20140409/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.0 20140409 (Red Hat 4.9.0-0.9) (GCC) 

works with 4.8.2 and earlier and ifort version 14.0.2.

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Created attachment 32581
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32581&action=edit
gcc49-pr60567.patch

The ipa.c version (changing node->forced_by_abi instead of
decl_node->forced_by_abi), also bootstrapped/regtested on i686-linux and
bootstrapped on x86_64-linux with regtest still ongoing there.

[Bug c/60809] C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

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

--- Comment #4 from jimis  ---
Thanks Andreas, that's the reference I was looking for!

I guess since this code triggers unspecified behaviour, a warning would be even
more needed. :-)

[Bug rtl-optimization/60663] [4.9 Regression] Errors out on valid inline asm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-10
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|Errors out on valid inline  |[4.9 Regression] Errors out
   |asm |on valid inline asm
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Supposedly introduced by r203160 which made inline asm with no input operands
appear as having zero cost.

Alternate patch posted at
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00512.html

[Bug ipa/60761] [4.9 RegrImprove dump_decl for clones

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P3
Summary|[4.9 Regression] Names of   |[4.9 RegrImprove dump_decl
   |all function clones in g++  |for clones
   |are "", in both   |
   |warnings and dumps  |

--- Comment #18 from Jakub Jelinek  ---
No longer a regression, keeping open as enhancement request to improve the
dumping for stage1.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 16:20:07 2014
New Revision: 209278

URL: http://gcc.gnu.org/viewcvs?rev=209278&root=gcc&view=rev
Log:
PR ipa/60761
* error.c (dump_decl) : If
DECL_LANG_SPECIFIC is NULL, but DECL_ABSTRACT_ORIGIN is not,
recurse on DECL_ABSTRACT_ORIGIN instead of printing
.

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

[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619

[mircea.namolaru at inria dot fr]

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

Mircea Namolaru  changed:

   What|Removed |Added

 CC||mircea.namolaru at inria dot fr

--- Comment #17 from Mircea Namolaru  ---
Vladimir Kargov, Tobias Grosser and me found that the problem is caused by
incorrect folding of the floord operator. As a result Cloog translates the
expression
-4294967296*floord(_19-i_17,4294967296)
to the tree-SSA expression
4294967296*floord(_19-i_17,-4294967296)

This is wrong, in the first case floord is 0 and in the second is -1.

[Bug target/60800] -O3 -fstack-arrays miscompiles 178.galgel in SPEC CPU 2K

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
Summary|-Ofast -ffast-math  |-O3 -fstack-arrays
   |miscompiles 178.galgel in   |miscompiles 178.galgel in
   |SPEC CPU 2K |SPEC CPU 2K

--- Comment #5 from H.J. Lu  ---
-fstack-arrays needs more stack. 32MB stack limit works.

[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
-O3 -fstack-arrays -ffast-math also fails on both i686 and x86-64.

[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

  Attachment #32577|0   |1
is obsolete||

--- Comment #2 from Andi Kleen  ---
Created attachment 32580
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32580&action=edit
this one still fails with current trunk

[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gereon.kremer at cs dot rwth-aache |
   |n.de|

--- Comment #5 from Paolo Carlini  ---
Indeed, this isn't a Dup, but note that the experiment in Comment 3 doesn't
tell us much: "confused by earlier errors, bailing out" is an ICE for a
compiler built with checks enabled.

[Bug c++/60807] internal compiler error (basic_string.tcc)

[martin at netbsd dot org]

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

--- Comment #4 from Martin Husemann  ---
Neither can I on NetBSD/amd64 - will check with Thomas for differences on his
system

[Bug middle-end/60469] simple cilk plus program ICEs

[izamyatin at gmail dot com]

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

--- Comment #12 from Igor Zamyatin  ---
Thanks, will post a patch after the testing

[Bug c/60809] C99 struct initialiser with embedded self assignment

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

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

--- Comment #3 from Andreas Schwab  ---
6.7.9 Initialization
23 The evaluations of the initialization list expressions are indeterminately
sequenced with respect to one another and thus the order in which any side
effects occur is unspecified.

[Bug c/60809] C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

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

--- Comment #2 from jimis  ---
(In reply to Marek Polacek from comment #1)
> I see nothing surprising here; an assignment expression has the value of the
> left operand after the assignment.  So we 1) set query2.ai_flags to
> AI_PASSIVE, 2) use this value to initialize .ai_protocol.

if the outer assignment runs last, shouldn't it overwrite the inner assignment?
Then it should be equivalent to that:


struct addrinfo query3 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
1


Which means that ai_flags should be 0.

[Bug c++/52844] ICE

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #12 from Paolo Carlini  ---
Done.

[Bug c++/52844] ICE

[paolo at gcc dot gnu.org]

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

--- Comment #11 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Apr 10 14:06:36 2014
New Revision: 209276

URL: http://gcc.gnu.org/viewcvs?rev=209276&root=gcc&view=rev
Log:
2014-04-10  Paolo Carlini  

PR c++/52844
* g++.dg/cpp0x/variadic156.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic156.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug other/60589] Parallel install fails due to multiple cilk.h installs

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #6 from Tobias Burnus  ---
Close as FIXED. Comment 5 should have fixed the problem.

[Some other issues were fixed in commit r208847/r208847 (namely: the double
cilk.h and the automatic inclusion of -lcilkrts).]

[Bug c/60809] C99 struct initialiser with embedded self assignment

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I see nothing surprising here; an assignment expression has the value of the
left operand after the assignment.  So we 1) set query2.ai_flags to AI_PASSIVE,
2) use this value to initialize .ai_protocol.

I'm not sure a warning here makes sense: an assignment-expression is perfectly
valid initializer.

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  ---
(In reply to Martin Jambor from comment #15)
> (In reply to Manuel López-Ibáñez from comment #13)
> > It is not clear to me why you want to print  at all. It is an
> > internal detail.
> 
> ...just printing "" really provides fairly little value.  If we
> (hopefully from the next version on) manage to print details about
> properties of the particular clone, it will become useful.

I'm not entirely convinced by the arguments given above. Templated C++ code in
diagnostics is already convoluted enough to add stuff that is not even in the
language and that users will have no idea about. Imagine (real G++ output):

std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char,
_Traits = std::char_traits, std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream] 

For developer/debug dumps, of course this doesn't apply, but this is not what
this bug is about.


(In reply to Marc Glisse from comment #14)
> Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone
> specializing a=0. If the function contains a comparison a<=b, you might get
> a warning because the comparison is always true. As a user, I would be quite
> confused...

This used to happen with template instantiations and it was considered a bug.
That is, the compiler should not give that kind of warning for generated code
if the original code does not show the same issue. If the original code shows
the same issue, then we should give a warning for the original code. 

In general, there are at least two kinds of warnings: those for which there is
a bug if we reach that code under certain conditions, and those for which the
code looks suspicious but we cannot prove that there is a bug under any
specific condition. Uninitialized warnings fall in the first category, whereas
"comparison is always true/false" falls under the second one. The first kind of
warnings would be improved by providing the exact conditions that may trigger
the bug, whereas the second kind become noise if only triggered for specific
conditions that are actually not present in the original code (like template
specializations, macro expansion, and function cloning).

For the first kind of bugs, if we explain the conditions better thanks to
optimization, great, but saying: we warn because we created a clone of the
function only leads to more questions: what is a clone? For the second kind,
saying that we warn because we created a clone sounds more like an excuse than
an actual analysis. ;-)

[Bug c/50584] No warning for passing small array to C99 static array declarator

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
I don't recommend this kind of usage of the static keyword.  There was even the
possibility of removing/deprecating this feature.  Quoting from DR#205:
"There was a unanimous vote that the feature is ugly, and a good consensus that
its incorporation into the standard at the 11th hour was an unfortunate
decision."

[Bug c/60809] New: C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

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

Bug ID: 60809
   Summary: C99 struct initialiser with embedded self assignment
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jimis at gmx dot net

For the following code, which was a typo from my side (full example attached):


struct addrinfo query2 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
query2.ai_flags = AI_PASSIVE
};


1. A warning would be nice, something like "suggest parentheses around
assignment"
2. What is the C99 mandated behaviour? I'm not sure GCC is behaving properly.
Currently it sets ai_protocol to 1 because it is the next field after
ai_socktype. But it also sets ai_flags to 1, which I'd expect to be 0 after the
outer struct initialiser is executed.


See discussion, full example program and output, at
http://gcc.gnu.org/ml/gcc-help/2014-04/msg00033.html

[Bug c/50584] No warning for passing small array to C99 static array declarator

[jimis at gmx dot net]

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

jimis  changed:

   What|Removed |Added

 CC||jimis at gmx dot net

--- Comment #5 from jimis  ---
I'm currently using this C99 feature. A warning would be nice if NULL or small
arrays are passed.

[Bug target/60808] New: Typo in definition of ATxmega256A3BU

[vonzeng at ibr dot cs.tu-bs.de]

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

Bug ID: 60808
   Summary: Typo in definition of ATxmega256A3BU
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vonzeng at ibr dot cs.tu-bs.de

Created attachment 32579
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32579&action=edit
typo fix

There is a typo in gcc/config/avr/avr-mcus.de. 
The mmcpu definition of the ATxmega256A3BU is __AVR_ATxmega258A3BU__.
This leads to errors while compiling the avr-libc, this is way I marked the bug
critical.
Attached is the very easy patch to fix it.

[Bug c++/57926] Atomic functions broken with C++ but not C?

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to lailavrazda1979 from comment #14)
> Why wait? I'm not hugely opposed, but bugfixes are bugfixes, and one more
> fixed bug makes a better 4.9 release, right?

Because all changes risk introducing new bugs, and we're very close to 4.9 now.

[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can you please bisect it to a particular gcc commit and/or single 178.galgel
source file?

[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #12)
> Also, perhaps to make the change conservative enough for 4.9, might be best
> to not append anything now, and only look at DECL_ABSTRACT_ORIGIN (recurse
> on it) if !DECL_LANG_SPECIFIC.  More verbose printing can be perhaps
> deferred for stage1.

I agree, mostly because...

(In reply to Manuel López-Ibáñez from comment #13)
> It is not clear to me why you want to print  at all. It is an
> internal detail.

...just printing "" really provides fairly little value.  If we
(hopefully from the next version on) manage to print details about
properties of the particular clone, it will become useful.

[Bug c++/52844] ICE

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #10 from Paolo Carlini  ---
Doesn't ICE anymore in mainline. I'm adding the testcase and closing the bug.

[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Unfortunately, I could not replicate this with -Ofast -ffast-math
(isn't -ffast-math part of -Ofast?) and trunk revision 209179.

[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-04-10
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce this, supposedly starting with r208382 when this is rejected as
invalid use of _Cilk_spawn.  So, do you have any testcases that ICE even with
current trunk?

[Bug c++/60807] internal compiler error (basic_string.tcc)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Can't reproduce this on Linux/x86_64.

[Bug c++/60807] internal compiler error (basic_string.tcc)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
   Severity|major   |normal

--- Comment #2 from Markus Trippelsdorf  ---
I cannot reproduce this ICE.

[Bug ada/60411] Ada bootstrap failure on ARM

[ebotcazou at gcc dot gnu.org]

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

--- Comment #22 from Eric Botcazou  ---
> When I tried to build the ARMv5 cross compiler (-march=armv5te) I get the
> following error:
> 
> /tmp//cc5BKnWK.s: Assembler messages:
> /tmp//cc5BKnWK.s:31: Error: selected processor does not support Thumb mode
> `stmfd sp!,{r2,r3,lr}'
> /tmp//cc5BKnWK.s:46: Error: lo register required -- `ldmfd sp,{r2,r3,pc}'
> gmake[8]: *** [sigtramp-armdroid.o] Error 1
> 
> 
> Does this mean effectively nothing lower than ARMv7 can build
> arm-*-linux-androideabi?

Apparently so, but it should be quite easy to fix this in sigtramp-armdroid.c
by means of some preprocessor magic.

[Bug c++/60807] internal compiler error (basic_string.tcc)

[tk at giga dot or.at]

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

--- Comment #1 from Thomas Klausner  ---
This was first filed in the NetBSD bug tracker at
http://gnats.netbsd.org/48731
where it was suggested to file this upstream.

[Bug c++/60807] New: internal compiler error (basic_string.tcc)

[tk at giga dot or.at]

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

Bug ID: 60807
   Summary: internal compiler error (basic_string.tcc)
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tk at giga dot or.at

Created attachment 32578
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32578&action=edit
Result of -save-temps

When compiling gambatte r550
(http://sourceforge.net/projects/gambatte/files/gambatte/r550/gambatte_src-r550.tar.gz)
on NetBSD-6.99.40/amd64 with the g++ coming with that version of NetBSD, a file
in libgambatte/ triggers an internal compiler error:

#  g++ -v -save-temps -o src/cpu.o -c -Wall -Wextra -O2 -fomit-frame-pointer
-fno-exceptions -fno-rtti -DHAVE_STDINT_H -Isrc -Iinclude
-I/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common
src/cpu.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64--netbsd
Configured with: /usr/src6/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=x86_64--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit --with-tune=nocona
--with-mpc-lib=/var/obj/mknative/amd64-x86_64/usr/src6/external/lgpl3/mpc/lib/libmpc
--with-mpfr-lib=/var/obj/mknative/amd64-x86_64/usr/src6/external/lgpl3/mpfr/lib/libmpfr
--with-gmp-lib=/var/obj/mknative/amd64-x86_64/usr/src6/external/lgpl3/gmp/lib/libgmp
--with-mpc-include=/usr/src6/external/lgpl3/mpc/dist/src
--with-mpfr-include=/usr/src6/external/lgpl3/mpfr/dist/src
--with-gmp-include=/usr/src6/external/lgpl3/gmp/lib/libgmp/arch/x86_64
--enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0. --host=x86_64--netbsd
--with-sysroot=/var/obj/mknative/amd64-x86_64/usr/src6/destdir.amd64
Thread model: posix
gcc version 4.8.3 (NetBSD nb2 20140304)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'src/cpu.o' '-c' '-Wall' '-Wextra'
'-O2' '-fomit-frame-pointer' '-fno-exceptions' '-fno-rtti' '-D' 'HAVE_STDINT_H'
'-I' 'src' '-I' 'include' '-I'
'/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common'
'-shared-libgcc' '-mtune=nocona' '-march=x86-64'
 /usr/libexec/cc1plus -E -quiet -v -I src -I include -I
/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common -D
HAVE_STDINT_H src/cpu.cpp -mtune=nocona -march=x86-64 -Wall -Wextra
-fomit-frame-pointer -fno-exceptions -fno-rtti -O2 -fpch-preprocess -o cpu.ii
#include "..." search starts here:
#include <...> search starts here:
 src
 include
 /disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common
 /usr/include/g++
 /usr/include/g++/backward
 /usr/include/gcc-4.8
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'src/cpu.o' '-c' '-Wall' '-Wextra'
'-O2' '-fomit-frame-pointer' '-fno-exceptions' '-fno-rtti' '-D' 'HAVE_STDINT_H'
'-I' 'src' '-I' 'include' '-I'
'/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common'
'-shared-libgcc' '-mtune=nocona' '-march=x86-64'
 /usr/libexec/cc1plus -fpreprocessed cpu.ii -quiet -dumpbase cpu.cpp
-mtune=nocona -march=x86-64 -auxbase-strip src/cpu.o -O2 -Wall -Wextra -version
-fomit-frame-pointer -fno-exceptions -fno-rtti -o cpu.s
GNU C++ (NetBSD nb2 20140304) version 4.8.3 (x86_64--netbsd)
compiled by GNU C version 4.2.1 Compatible Clang 3.5 (trunk 202566),
GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (NetBSD nb2 20140304) version 4.8.3 (x86_64--netbsd)
compiled by GNU C version 4.2.1 Compatible Clang 3.5 (trunk 202566),
GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4054f87540345d4e138a62067c6e8c30
In file included from /usr/include/g++/string:53:0,
 from include/loadres.h:4,
 from src/mem/cartridge.h:22,
 from src/memory.h:22,
 from src/cpu.h:22,
 from src/cpu.cpp:19:
/usr/include/g++/bits/basic_string.tcc: In copy constructor
‘std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::basic_string<_CharT, _Traits, _Alloc>&)’:
/usr/include/g++/bits/basic_string.tcc:173:26: internal compiler error:
Segmentation fault
 __str.get_allocator())
  ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Starting cc1plus in gdb gives the following backtrace:

(gdb) r -quiet -v -I src -I include -I
/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common -D
HAVE_STDINT_H src/cpu.cpp -quiet -dumpbase cpu.cpp -

[Bug ada/60411] Ada bootstrap failure on ARM

[gnugcc at marino dot st]

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

--- Comment #21 from John Marino  ---
Hi Eric,
When I tried to build the ARMv5 cross compiler (-march=armv5te) I get the
following error:

/tmp//cc5BKnWK.s: Assembler messages:
/tmp//cc5BKnWK.s:31: Error: selected processor does not support Thumb mode
`stmfd sp!,{r2,r3,lr}'
/tmp//cc5BKnWK.s:46: Error: lo register required -- `ldmfd sp,{r2,r3,pc}'
gmake[8]: *** [sigtramp-armdroid.o] Error 1


Does this mean effectively nothing lower than ARMv7 can build
arm-*-linux-androideabi?  I don't know which ARM arch supports ldmfd
sp,{r2,r3,pc} but I assume ARMv5 and lower doesn't.

John

[Bug tree-optimization/60502] [4.8 Regression] ICE reassociation and vector types.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.3
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Fixed for 4.8.3+ too.

[Bug tree-optimization/60502] [4.8 Regression] ICE reassociation and vector types.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 09:35:39 2014
New Revision: 209274

URL: http://gcc.gnu.org/viewcvs?rev=209274&root=gcc&view=rev
Log:
Backport from mainline
2014-03-12  Jakub Jelinek  
Marc Glisse  

PR tree-optimization/60502
* tree-ssa-reassoc.c (eliminate_not_pairs): Use build_all_ones_cst
instead of build_low_bits_mask.

* gcc.c-torture/compile/pr60502.c: New test.

2013-06-13  Marc Glisse  

* tree.c (build_all_ones_cst): New function.
* tree.h (build_all_ones_cst): Declare it.

2013-05-10  Marc Glisse  

* tree.c (build_minus_one_cst): New function.
* tree.h (build_minus_one_cst): Declare new function.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-ssa-reassoc.c
branches/gcc-4_8-branch/gcc/tree.c
branches/gcc-4_8-branch/gcc/tree.h

[Bug fortran/60795] [4.7/4.8/4.9 Regression] Wrong length when allocating character array

[kergonath at me dot com]

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

--- Comment #4 from Kergonath  ---
The slightly modified version:
module m
contains
subroutine allocate_array(s_array)
character(:), dimension(:), allocatable, intent(out) :: s_array

allocate(character(2) :: s_array(10))
write(*,*) len(s_array), size(s_array)
end subroutine
end module

program stringtest
use m
character(:), dimension(:), allocatable :: s4
call allocate_array(s4)
write(*,*) len(s4), size(s4)
 end program

gives the result:
   0  10
   0  10

when compiled with: gfortran -o stringtest stringtest.f90

but gives
   0  10
   32767  10

when using the -pg option.

Using -Wall does only show the following warning, which looks similar to that
in PR56670:

stringtest.f90: In function 'allocate_array':
stringtest.f90:7:0: warning: '.s_array' may be used uninitialized in this
function [-Wmaybe-uninitialized]
 write(*,*) len(s_array), size(s_array)
 ^

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
By the C++ FE change, do you mean something like:
--- gcc/cp/method.c.jj2014-03-27 08:06:11.0 +0100
+++ gcc/cp/method.c2014-04-10 10:59:36.226288999 +0200
@@ -387,6 +387,7 @@ use_thunk (tree thunk_fndecl, bool emit_
   thunk_node = cgraph_add_thunk (funcn, thunk_fndecl, function,
  this_adjusting, fixed_offset, virtual_value,
  virtual_offset, alias);
+  thunk_node->forced_by_abi = funcn->forced_by_abi;
   if (DECL_ONE_ONLY (function))
 symtab_add_to_same_comdat_group (thunk_node,
  funcn);
(which fixes this testcase too, but otherwise untested so far), or say change
cgraph_add_thunk so that it has node->forced_by_abi = decl_node->forced_by_abi;
(also untested).

[Bug middle-end/60469] simple cilk plus program ICEs

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
You need to include gimple-expr.h header for that.  But, if you look e.g. at
c/c-typeck.c or c-family/cilk.c, it is already used in the FEs.

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #15)
> This patch fixes the ICE by copying forced_by_abi as part of cgraph fixup in
> ipa visibility.  I would like Jason to comment on this. I think fix at C++
> FE side would be more appropriate if the thunk is indeed keyed.
> 
> If not, I will update partitinoning predicate to always iterate the whole
> group and see if any of symbols is keyed.
> 
> Index: ipa.c
> ===
> --- ipa.c   (revision 209170)
> +++ ipa.c   (working copy)
> @@ -1032,6 +1032,7 @@ function_and_variable_visibility (bool w
>== DECL_COMDAT_GROUP (decl_node->decl));
>   gcc_checking_assert (node->same_comdat_group);
> }
> + decl_node->forced_by_abi = node->forced_by_abi;
>   if (DECL_EXTERNAL (decl_node->decl))
> DECL_EXTERNAL (node->decl) = 1;
> }

Shouldn't that be the other way around though?
  node->forced_by_abi = decl_node->forced_by_abi;
>From what I understand, decl_node is the target of the thunk, and node is
thunk, on this testcase decl_node->forced_by_abi is true originally, while
node->forced_by_abi is false.  So, if the thunks are supposed to inherit the
flag from the thunk target, we should change node->forced_by_abi, similarly how
we e.g. change DECL_EXTERNAL (node->decl).

[Bug middle-end/60469] simple cilk plus program ICEs

[izamyatin at gmail dot com]

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

--- Comment #10 from Igor Zamyatin  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to H.J. Lu from comment #8)
> > (In reply to H.J. Lu from comment #7)
> > > (In reply to Igor Zamyatin from comment #6)
> > > > Yes, I was going to post it after complete testing
> > > 
> > > You should set DECL_SEEN_IN_BIND_EXPR_P when setting
> > > DECL_CONTEXT, similar to gimple_add_tmp_var.
> > 
> > Or we can use create_tmp_var.
> 
> That is much better idea, it will handle tons of other things, like setting
> DECL_ARTIFICIAL/DECL_IGNORED_P flags etc.  In C++ FE, cp-array-notation.c
> apparently uses get_temp_regvar, which is also fine (but only defined in C++
> FE).

 Yes, I tried create_tmp_var but it was undefined so I thought it's not a good
idea...
Will try further with it then

[Bug testsuite/60806] New: libstdc++ abi check should ignore missing TLS symbols

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

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

Bug ID: 60806
   Summary: libstdc++ abi check should ignore missing TLS symbols
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org

baseline_symbols.txt is expected not to contain TLS symbols so that libstdc++
abi check won't complain about them missing in --disable-tls configurations.
This is error prone since people forget to remote them from
baseline_symbols.txt when updating it.  The abi check should go the other way
and ignore missing TLS symbols instead of ignoring added TLS symbols.

[Bug debug/60805] New: Validate const expressions created by var-tracking / debug information across targets.

[ramana at gcc dot gnu.org]

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

Bug ID: 60805
   Summary: Validate const expressions created by var-tracking /
debug information across targets.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org

While fixing PR60655 Jakub noted that the problem really was that var-tracking
and debug info generation can play a bit fast and loose in the types of
expressions that are generated. Particularly the problem is when const
expressions involving sym_refs are created, targets need to be able to handle /
given a chance to decide on what kinds of expressions are valid and what not. 

Additionally const_ok_for_output_1 and friends in dwarf2out.c don't necessarily
have the entire information on this and require some guess work in this.

For 4.10 we need to instrument the compiler to produce some traces of the
typical kinds of debug expressions that are generated, for a variety of targets
and attempt to handle these in a common manner and only allow the basic common
subset and possibly allowing targets to enable further constants to be
generated.

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #17 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/60469] simple cilk plus program ICEs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > (In reply to Igor Zamyatin from comment #6)
> > > Yes, I was going to post it after complete testing
> > 
> > You should set DECL_SEEN_IN_BIND_EXPR_P when setting
> > DECL_CONTEXT, similar to gimple_add_tmp_var.
> 
> Or we can use create_tmp_var.

That is much better idea, it will handle tons of other things, like setting
DECL_ARTIFICIAL/DECL_IGNORED_P flags etc.  In C++ FE, cp-array-notation.c
apparently uses get_temp_regvar, which is also fine (but only defined in C++
FE).

[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list

[akim.demaille at gmail dot com]

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

--- Comment #10 from Akim Demaille  ---
Well, I have finally found a simple workaround for some of the cases: GCC seems
to be right in the order of evaluation when initializing an array so:

template
int f1()
{
  int i = 0;
  swallow{ i = 10 * i + IS... };
  return i;
}

fails, but

template
int f2()
{
  using swallow = int[];
  int i = 0;
  (void) swallow{ i = 10 * i + IS... };
  return i;
}

succeeds.  However, GCC's own libstdc++ is exposed to this bug, for instance
make_tuple.

$ cat foo.cc
#include 
#include 

struct swallow
{
  template
  swallow(Types &&...){}
};

int incr()
{
  static int res = 2;
  return res++;
}

template
int f1()
{
  int i = 0;
  swallow{ i = 10 * i + IS... };
  return i;
}

template
int f2()
{
  using swallow = int[];
  int i = 0;
  (void) swallow{ i = 10 * i + IS... };
  return i;
}

int main()
{
  // `i = i * 2 + 2' should be sequenced before `i = i * 3 + 3'
  std::cerr << f1<2, 3>() << '\t';
  std::cerr << f2<2, 3>() << '\t';
  auto t = std::make_tuple(incr(), incr());
  std::cerr << std::get<0>(t) << std::get<1>(t) << '\n';
}

$ ./a.32
232323
$ ./a.33
232323
$ ./a.34
232323
$ ./a.35
232323
$ ./a.48
322332
$ ./a.49
322332

where 32...35 is clang++, and 48,49 is gcc.

[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

[ramana at gcc dot gnu.org]

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

--- Comment #16 from Ramana Radhakrishnan  ---
Author: ramana
Date: Thu Apr 10 08:13:30 2014
New Revision: 209269

URL: http://gcc.gnu.org/viewcvs?rev=209269&root=gcc&view=rev
Log:
Fix PR debug/60655 part 2.

2014-04-10  Ramana Radhakrishnan  

PR debug/60655
* config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define
(arm_const_not_ok_for_debug_p): Reject MINUS with SYM_REF's
ameliorating the cases where it can be.

2014-04-10  Ramana Radhakrishnan  

PR debug/60655
* gcc.c-torture/compile/pr60655-2.c: Copy from pr60655-1.c without
-fdata-sections.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr60655-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60693] [4.8 Regression] ICE on funny memcpy

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug debug/60603] [4.7 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.8.3
Summary|[4.7/4.8 Regression]|[4.7 Regression]
   |.debug_macinfo/.debug_macro |.debug_macinfo/.debug_macro
   |has wrong line numbers for  |has wrong line numbers for
   |built-in macros |built-in macros

--- Comment #6 from Jakub Jelinek  ---
Fixed for 4.8.3+ too.

[Bug c++/60689] Bogus error with atomic::exchange

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/36282] [4.7 Regression] Spurious warning "asm declaration ignored due to conflict with previous rename"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.8.3
Summary|[4.7/4.8 Regression]|[4.7 Regression] Spurious
   |Spurious warning "asm   |warning "asm declaration
   |declaration ignored due to  |ignored due to conflict
   |conflict with previous  |with previous rename"
   |rename" |

--- Comment #11 from Jakub Jelinek  ---
Fixed also for 4.8.3+.

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
Fixed for 4.8.3+.

[Bug target/60516] [4.7 regression]: cc1plus crashes compiling a method with a huge struct as argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.7/4.8 regression]:   |[4.7 regression]: cc1plus
   |cc1plus crashes compiling a |crashes compiling a method
   |method with a huge struct   |with a huge struct as
   |as argument |argument

--- Comment #13 from Jakub Jelinek  ---
Fixed also for 4.8.3+.

[Bug target/60693] [4.8 Regression] ICE on funny memcpy

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 07:57:09 2014
New Revision: 209268

URL: http://gcc.gnu.org/viewcvs?rev=209268&root=gcc&view=rev
Log:
Backport from mainline
2014-03-28  Jakub Jelinek  

PR target/60693
* config/i386/i386.c (ix86_copy_addr_to_reg): Call copy_addr_to_reg
also if addr has VOIDmode.

* gcc.target/i386/pr60693.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr60693.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/60689] Bogus error with atomic::exchange

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 07:54:08 2014
New Revision: 209267

URL: http://gcc.gnu.org/viewcvs?rev=209267&root=gcc&view=rev
Log:
Backport from mainline
2014-03-28  Jakub Jelinek  

PR c++/60689
* c-tree.h (c_build_function_call_vec): New prototype.
* c-typeck.c (build_function_call_vec): Don't call
resolve_overloaded_builtin here.
(c_build_function_call_vec): New wrapper function around
build_function_call_vec.  Call resolve_overloaded_builtin here.
(convert_lvalue_to_rvalue, build_function_call, build_atomic_assign):
Call c_build_function_call_vec instead of build_function_call_vec.
* c-parser.c (c_parser_postfix_expression_after_primary): Likewise.
* c-decl.c (finish_decl): Likewise.

* c-common.c (add_atomic_size_parameter): When creating new
params vector, push the size argument first.

* c-c++-common/pr60689.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr60689.c
Modified:
branches/gcc-4_8-branch/gcc/c-family/ChangeLog
branches/gcc-4_8-branch/gcc/c-family/c-common.c
branches/gcc-4_8-branch/gcc/c/ChangeLog
branches/gcc-4_8-branch/gcc/c/c-decl.c
branches/gcc-4_8-branch/gcc/c/c-parser.c
branches/gcc-4_8-branch/gcc/c/c-tree.h
branches/gcc-4_8-branch/gcc/c/c-typeck.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug debug/60603] [4.7/4.8 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 07:51:52 2014
New Revision: 209265

URL: http://gcc.gnu.org/viewcvs?rev=209265&root=gcc&view=rev
Log:
Backport from mainline
2014-03-22  Jakub Jelinek  

PR debug/60603
* c-opts.c (c_finish_options): Restore cb_file_change call to
.

* cpp.c (gfc_cpp_init): Restore cb_change_file call to
.

* gcc.dg/debug/dwarf2/dwarf2-macro2.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2-macro2.c
Modified:
branches/gcc-4_8-branch/gcc/c-family/ChangeLog
branches/gcc-4_8-branch/gcc/c-family/c-opts.c
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/cpp.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/60516] [4.7/4.8 regression]: cc1plus crashes compiling a method with a huge struct as argument

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 07:49:02 2014
New Revision: 209264

URL: http://gcc.gnu.org/viewcvs?rev=209264&root=gcc&view=rev
Log:
Backport from mainline
2014-03-17  Jakub Jelinek  

PR target/60516
* config/i386/i386.c (ix86_expand_epilogue): Adjust REG_CFA_ADJUST_CFA
note creation for the 2010-08-31 changes.

* gcc.target/i386/pr60516.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr60516.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/36282] [4.7/4.8 Regression] Spurious warning "asm declaration ignored due to conflict with previous rename"

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 07:47:55 2014
New Revision: 209263

URL: http://gcc.gnu.org/viewcvs?rev=209263&root=gcc&view=rev
Log:
Backport from mainline
2014-03-13  Jakub Jelinek  

PR middle-end/36282
* c-pragma.c (apply_pragma_weak): Only look at
TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) if
DECL_ASSEMBLER_NAME_SET_P (decl).
(maybe_apply_pending_pragma_weaks): Exit early if
vec_safe_is_empty (pending_weaks) rather than only when
!pending_weaks.
(maybe_apply_pragma_weak): Likewise.  If !DECL_ASSEMBLER_NAME_SET_P,
set assembler name back to NULL afterwards.

* c-c++-common/pr36282-1.c: New test.
* c-c++-common/pr36282-2.c: New test.
* c-c++-common/pr36282-3.c: New test.
* c-c++-common/pr36282-4.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-1.c
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-2.c
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-3.c
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-4.c
Modified:
branches/gcc-4_8-branch/gcc/c-family/ChangeLog
branches/gcc-4_8-branch/gcc/c-family/c-pragma.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 10 07:45:21 2014
New Revision: 209262

URL: http://gcc.gnu.org/viewcvs?rev=209262&root=gcc&view=rev
Log:
Backport from mainline
2014-03-06  Jakub Jelinek  
Meador Inge  

PR target/58595
* config/arm/arm.c (arm_tls_symbol_p): Remove.
(arm_legitimize_address): Call legitimize_tls_address for any
arm_tls_referenced_p expression, handle constant addend.  Call it
before testing for !TARGET_ARM.
(thumb_legitimize_address): Don't handle arm_tls_symbol_p here.

2014-03-06  Jakub Jelinek  

PR target/58595
* gcc.dg/tls/pr58595.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/tls/pr58595.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/arm/arm.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c/54554] Undetected use of uninitialized variable

[dominik.muth at gmx dot de]

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

--- Comment #9 from Dominik Muth  ---
Please note that in Bug 60791 no warning is given even with -O3 (except when
using a legacy version of gcc).