[Bug c/65345] New: ICE with _Generic selection on _Atomic int

[Bug c/65345] New: ICE with _Generic selection on _Atomic int

[tijl at coosemans dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

            Bug ID: 65345
           Summary: ICE with _Generic selection on _Atomic int
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tijl at coosemans dot org

gcc49 (FreeBSD Ports Collection) 4.9.3 20150218 (prerelease)

% cat test.c
_Atomic int i;  
int j = _Generic( i+1, int: 1, default: 0 );

% gcc49 -c test.c
tmp.c:2:1: internal compiler error: Segmentation fault
 int j = _Generic( i+1, int: 1, default: 0 );
 ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


The error only happens when "i" is part of an expression, so _Generic(i,...)
works correctly (it returns 1).  Qualifiers like const and volatile instead of
_Atomic also work.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-03-07
                 CC|                            |mpolacek at gcc dot gnu.org
            Version|unknown                     |4.9.2
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Happens with trunk as well.  Taking.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Backtrace:

0xcbc8aa crash_signal
    /home/marek/src/gcc/gcc/toplev.c:383
0x978b80 tree_check
    /home/marek/src/gcc/gcc/tree.h:2845
0x978b80 gimple_body(tree_node*)
    /home/marek/src/gcc/gcc/gimple-expr.c:328
0xa18d07 gimple_add_tmp_var(tree_node*)
    /home/marek/src/gcc/gcc/gimplify.c:721
0x97949a create_tmp_var(tree_node*, char const*)
    /home/marek/src/gcc/gcc/gimple-expr.c:522
0x68051f convert_lvalue_to_rvalue(unsigned int, c_expr, bool, bool)
    /home/marek/src/gcc/gcc/c/c-typeck.c:2042
0x6bd29a c_parser_binary_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:6379
0x6bd7d8 c_parser_conditional_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:6031
0x6bdd80 c_parser_expr_no_commas
    /home/marek/src/gcc/gcc/c/c-parser.c:5949
0x6b39e8 c_parser_generic_selection
    /home/marek/src/gcc/gcc/c/c-parser.c:6856
0x6b39e8 c_parser_postfix_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:7665
0x6b5572 c_parser_unary_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:6602
0x6bcaaa c_parser_cast_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:6440
0x6bcc74 c_parser_binary_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:6255
0x6bd7d8 c_parser_conditional_expression
    /home/marek/src/gcc/gcc/c/c-parser.c:6031
0x6bdd80 c_parser_expr_no_commas
    /home/marek/src/gcc/gcc/c/c-parser.c:5949
0x6c7c0a c_parser_initializer
    /home/marek/src/gcc/gcc/c/c-parser.c:4167
0x6cd107 c_parser_declaration_or_fndef
    /home/marek/src/gcc/gcc/c/c-parser.c:1824
0x6d51c7 c_parser_external_declaration
    /home/marek/src/gcc/gcc/c/c-parser.c:1452
0x6d5a49 c_parser_translation_unit
    /home/marek/src/gcc/gcc/c/c-parser.c:1339
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.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems to be unrelated to _Generic, the following ICEs as well:

_Atomic int i = 5;
int j = i;

[Bug c/65345] ICE with _Generic selection on _Atomic int

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Or e.g.

_Atomic int i = 5;
int j = sizeof (i + 1);

which is valid code not involving _Generic.  And, similarly:

_Atomic int i = 5;
int j = sizeof (i = 0);

or

_Atomic int i = 5;
int j = sizeof (++i);

or

_Atomic int i = 5;
int j = sizeof (i--);

This at first suggests (but see below) that the special-case handling of 
atomics on lvalue-to-rvalue conversion, and on assignment / increment / 
decrement / any other cases where creation of temporaries is involved, 
should be disabled when at file scope - either the expression in question 
is in a context such as sizeof or _Generic where its side effects do not 
occur so the special handling is not needed, or an error will occur for 
the expression being non-constant even without the special handling.

Much the same applies at function prototype scope, e.g.:

_Atomic int i = 5;
void f (int a[i + 1]);

(where [i + 1] means the same as [*]).  But in the case of

_Atomic int i = 5;
void f (int a[i = 1]) {}

you have a valid program, where the atomic assignment must be executed on 
function entry (see the pending_sizes handling in c-decl.c).  So to handle 
such cases, maybe the special handling of atomics needs to be partly 
deferred, so that parsing "i = 1" generates some tree for atomic 
assignment and the temporaries only get added at gimplification time.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #4)
> Or e.g.
> 
> _Atomic int i = 5;
> int j = sizeof (i + 1);
> 
> which is valid code not involving _Generic.  And, similarly:
> 
> _Atomic int i = 5;
> int j = sizeof (i = 0);
> 
> or
> 
> _Atomic int i = 5;
> int j = sizeof (++i);
> 
> or
> 
> _Atomic int i = 5;
> int j = sizeof (i--);
> 
> This at first suggests (but see below) that the special-case handling of 
> atomics on lvalue-to-rvalue conversion, and on assignment / increment / 
> decrement / any other cases where creation of temporaries is involved, 
> should be disabled when at file scope - either the expression in question 
> is in a context such as sizeof or _Generic where its side effects do not 
> occur so the special handling is not needed, or an error will occur for 
> the expression being non-constant even without the special handling.

Yeah, I had an idea of using create_tmp_var_raw that doesn't push the variable
into function's local vars vector.  My thinking was that we don't need such
variables to survive into ME anyway in the valid cases, and in invalid cases,
the FE just rejects the code...

--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -2039,7 +2039,12 @@ convert_lvalue_to_rvalue (location_t loc, struct c_expr
exp,
       /* Remove the qualifiers for the rest of the expressions and 
         create the VAL temp variable to hold the RHS.  */  
       nonatomic_type = build_qualified_type (expr_type, TYPE_UNQUALIFIED);
-      tmp = create_tmp_var (nonatomic_type);
+      /* If we are outside a function, avoid pushing the variable into the
+        current binding.  */
+      if (current_function_decl)
+        tmp = create_tmp_var (nonatomic_type);
+      else
+        tmp = create_tmp_var_raw (nonatomic_type);
       tmp_addr = build_unary_op (loc, ADDR_EXPR, tmp, 0); 
       TREE_ADDRESSABLE (tmp) = 1;
       TREE_NO_WARNING (tmp) = 1;


> Much the same applies at function prototype scope, e.g.:
> 
> _Atomic int i = 5;
> void f (int a[i + 1]);
> 
> (where [i + 1] means the same as [*]).  But in the case of
> 
> _Atomic int i = 5;
> void f (int a[i = 1]) {}
> 
> you have a valid program, where the atomic assignment must be executed on 
> function entry (see the pending_sizes handling in c-decl.c).  So to handle 
> such cases, maybe the special handling of atomics needs to be partly 
> deferred, so that parsing "i = 1" generates some tree for atomic 
> assignment and the temporaries only get added at gimplification time.

... but my patch wouldn't handle this case.  Oh well.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
FWIW, my testcase was

/* PR c/65345 */
/* { dg-do compile } */
/* { dg-options "" } */

_Atomic int i = 3;
int g1 = sizeof (i + 1) + sizeof (-i);
int g2 = __builtin_constant_p (i + 1);
int g3 = 0 && i;
int g4 = 0 || i; /* { dg-error "initializer element is not constant" } */
int g5 = i; /* { dg-error "initializer element is not constant" } */
int g6[i]; /* { dg-error "variably modified" } */
int g7 = (i ? 1 : 2); /* { dg-error "initializer element is not constant" } */
int g8 = _Alignof (-i);
_Atomic long g10 = i; /* { dg-error "initializer element is not constant" } */

_Static_assert (_Generic (i, int: 1, default: 0) == 1, "");
_Static_assert (_Generic (i + 1, int: 1, default: 0) == 1, "");

void
foo (void)
{
  static int q1 = sizeof (i + 1) + sizeof (-i);
  static int q2 = __builtin_constant_p (i + 1);
  static int q3 = 0 && i;
  static int q4 = 0 || i; /* { dg-error "initializer element is not constant" }
*/
  static int q5 = i; /* { dg-error "initializer element is not constant" } */
  static int q6[i]; /* { dg-error "storage size" } */
  static int q7 = (i ? 1 : 2); /* { dg-error "initializer element is not
constant" } */
  static int q8 = _Alignof (-i);
}

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Patch queued for next stage1:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00698.html

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
A note to myself: address the TARGET_ATOMIC_ASSIGN_EXPAND_FENV implementations:
<https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01094.html>.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Apr 23 14:35:12 2015
New Revision: 222370

URL: https://gcc.gnu.org/viewcvs?rev=222370&root=gcc&view=rev
Log:
    PR c/65345
    * c-decl.c (set_labels_context_r): New function.
    (store_parm_decls): Call it via walk_tree_without_duplicates.
    * c-typeck.c (convert_lvalue_to_rvalue): Use create_tmp_var_raw
    instead of create_tmp_var.  Build TARGET_EXPR instead of
    COMPOUND_EXPR.
    (build_atomic_assign): Use create_tmp_var_raw instead of
    create_tmp_var.  Build TARGET_EXPRs instead of MODIFY_EXPR.

    * gcc.dg/pr65345-1.c: New test.
    * gcc.dg/pr65345-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr65345-1.c
    trunk/gcc/testsuite/gcc.dg/pr65345-2.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-decl.c
    trunk/gcc/c/c-typeck.c
    trunk/gcc/testsuite/ChangeLog

[Bug c/65345] ICE with _Generic selection on _Atomic int

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #12 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Is there some reason the TARGET_ATOMIC_ASSIGN_EXPAND_FENV patch -
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00682.html - hasn't been
committed, minus the XFAILing and with a note to all affected target
maintainers who may need to fix their ports as requested in
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01792.html ?

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
No, the only problem is that I sort of forgot about this one ;).  I'll get it
done tomorrow.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #14 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Oct  1 14:53:10 2015
New Revision: 228343

URL: https://gcc.gnu.org/viewcvs?rev=228343&root=gcc&view=rev
Log:
        PR c/65345
        * config/i386/i386.c (ix86_atomic_assign_expand_fenv): Adjust to use
        create_tmp_var_raw rather than create_tmp_var.

        * gcc.dg/atomic/pr65345-4.c: New test.
        * gcc.dg/pr65345-3.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/atomic/pr65345-4.c
    trunk/gcc/testsuite/gcc.dg/pr65345-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be fixed, at least for x86_64/i?86.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Tue Oct  6 09:14:48 2015
New Revision: 228516

URL: https://gcc.gnu.org/viewcvs?rev=228516&root=gcc&view=rev
Log:
        PR c/65345
        * config/sparc/sparc.c (sparc_atomic_assign_expand_fenv): Adjust to
        use create_tmp_var_raw rather than create_tmp_var.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sparc/sparc.c

[Bug c/65345] ICE with _Generic selection on _Atomic int

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clyon at gcc dot gnu.org

--- Comment #17 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
*** Bug 67848 has been marked as a duplicate of this bug. ***

[Bug c/65345] ICE with _Generic selection on _Atomic int

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm, aarch64, x86_64,i386,
                   |                            |sparc, powerpc*
             Status|RESOLVED                    |REOPENED
                 CC|                            |ramana at gcc dot gnu.org
         Resolution|FIXED                       |---

--- Comment #18 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
This is not fixed till all the targets are fixed -

Also the target milestone is set at 5.3 but the fix hasn't been applied to the
5 branch.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #20 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Tue Oct  6 15:09:43 2015
New Revision: 228526

URL: https://gcc.gnu.org/viewcvs?rev=228526&root=gcc&view=rev
Log:
Fix PR c/65345 for AArch64 



2015-10-06  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR c/65345
        * config/aarch64/aarch64-builtins.c
(aarch64_atomic_assign_expand_fenv):
        Use create_tmp_var_raw instead of create_tmp_var.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64-builtins.c

[Bug c/65345] ICE with _Generic selection on _Atomic int

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct  6 15:31:11 2015
New Revision: 228527

URL: https://gcc.gnu.org/viewcvs?rev=228527&root=gcc&view=rev
Log:
        PR c/65345
        * config/alpha/alpha.c (alpha_atomic_assign_expand_fenv): Use
        create_tmp_var_raw instead of create_tmp_var.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/alpha/alpha.c

[Bug c/65345] ICE with _Generic selection on _Atomic int

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #22 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I still have:

arm-linux-gnueabihf-gcc pr65345-3.c 
pr65345-3.c:8:1: internal compiler error: Segmentation fault
 float a3 = sizeof (i++);
 ^
0xaa349f crash_signal
        ../../gcc-6-20151004.orig/gcc/toplev.c:353
0x8692c0 tree_check(tree_node*, char const*, int, char const*, tree_code)
        ../../gcc-6-20151004.orig/gcc/tree.h:2863
0x8692c0 gimple_body(tree_node*)
        ../../gcc-6-20151004.orig/gcc/gimple-expr.c:312
0x88b8e7 gimple_add_tmp_var(tree_node*)
        ../../gcc-6-20151004.orig/gcc/gimplify.c:700
0x86999a create_tmp_var(tree_node*, char const*)
        ../../gcc-6-20151004.orig/gcc/gimple-expr.c:467
0xdd0610 arm_atomic_assign_expand_fenv(tree_node**, tree_node**, tree_node**)
        ../../gcc-6-20151004.orig/gcc/config/arm/arm-builtins.c:2977
0x5de84f build_atomic_assign
        ../../gcc-6-20151004.orig/gcc/c/c-typeck.c:3738
0x5dfbf4 build_unary_op(unsigned int, tree_code, tree_node*, int)
        ../../gcc-6-20151004.orig/gcc/c/c-typeck.c:4131
0x60300d c_parser_postfix_expression_after_primary
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:8089
0x5fbcd7 c_parser_postfix_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:7806
0x5fe352 c_parser_unary_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6693
0x5fefbf c_parser_cast_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6531
0x5ff1a5 c_parser_binary_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6347
0x5ffdf5 c_parser_conditional_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6123
0x6003e0 c_parser_expr_no_commas
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6041
0x600ab2 c_parser_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:8113
0x5fbfc1 c_parser_postfix_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:7309
0x5fe352 c_parser_unary_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6693
0x5fe8aa c_parser_sizeof_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6743
0x5fe8aa c_parser_unary_expression
        ../../gcc-6-20151004.orig/gcc/c/c-parser.c:6664
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.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #23 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Wed Oct  7 08:37:35 2015
New Revision: 228562

URL: https://gcc.gnu.org/viewcvs?rev=228562&root=gcc&view=rev
Log:
Fix PR c/65345 for arm




2015-10-07  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR c/65345
        * config/arm/arm-builtins.c (arm_atomic_assign_expand_fenv):
        Use create_tmp_var_raw instead of create_tmp_var.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm-builtins.c

[Bug c/65345] ICE with _Generic selection on _Atomic int

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schwab@linux-m68k.org

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 67887 has been marked as a duplicate of this bug. ***

[Bug c/65345] ICE with _Generic selection on _Atomic int

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #25 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
Author: krebbel
Date: Thu Oct  8 07:49:41 2015
New Revision: 228594

URL: https://gcc.gnu.org/viewcvs?rev=228594&root=gcc&view=rev
Log:
S/390: Use create_tmp_var_raw in s390_atomic_assign_expand_fenv.

gcc/ChangeLog:

2015-10-08  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

        PR c/65345
        * config/s390/s390.c (s390_atomic_assign_expand_fenv): Use
        create_tmp_var_raw instead of create_tmp_var.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/s390/s390.c