[Bug lto/65380] New: [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[Bug lto/65380] New: [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

            Bug ID: 65380
           Summary: [5 Regression] LTO: ICE in add_symbol_to_partition_1,
                    at lto/lto-partition.c:158
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org

Created attachment 35003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35003&action=edit
one.ii

Follow up to PR65276, PR65302, PR65316, PR65361 - still for the same program.

Somewhat reduced test case (NOTE: The order one.ii/two.ii matters; if one
reverses it, it compiles):

 g++ -c -w -O2 -flto -std=c++11 one.ii two.ii
 gcc -r -nostdlib one.o two.o

fails with:

lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:158
0x637bd0 add_symbol_to_partition_1
        ../../gcc/lto/lto-partition.c:157
0x637a1a add_symbol_to_partition_1
        ../../gcc/lto/lto-partition.c:202
0x63942c lto_balanced_map(int)
        ../../gcc/lto/lto-partition.c:640
0x632089 do_whole_program_analysis
        ../../gcc/lto/lto.c:3304
0x632089 lto_main()
        ../../gcc/lto/lto.c:3465

[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 35004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35004&action=edit
two.ii

[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-03-10
           Assignee|unassigned at gcc dot gnu.org      |hubicka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Will take a look.  Is it an open source program? I may include it into my
testing :)

[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #2)
> Will take a look.  Is it an open source program?

Thanks. Unfortunately, it isn't open source; it's mostly used in house and
there were talks about open-sourcing it, but it has not (yet) happened.

[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
 Hmm, this one compiles just fine for me with today mainline.  Does the problem
still reproduce for you?  Can you possibly dump out node->debug() and c?

[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #4)
> Hmm, this one compiles just fine for me with today mainline.  Does the
> problem still reproduce for you?  Can you possibly dump out node->debug()
> and c?

Unfortunately, it still fails for me with today's r221445 (for the very first
invocation of line lto-partition.c:158). For

157   gcc_assert (c != SYMBOL_EXTERNAL
158               && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));


Running

lto1 -quiet -dumpbase one.o -mtune=generic -march=x86-64 -mtune=generic
-march=x86-64 -auxbase one -O2 -version -fexceptions -fmath-errno
-fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccX5yPa0.ltrans.out -fwpa -fresolution=two.res
@/tmp/ccYbGLe0

in the debugger gives:


(gdb) p c
$1 = SYMBOL_EXTERNAL

(gdb) p node->debug()
_ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So/188
(_ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So) @0x7ffff1d38880
  Type: variable definition analyzed alias
  Visibility: externally_visible external public visibility_specified
visibility:hidden virtual artificial
  References: _ZTCN7Utility2IO12GUnzipStreamE0_So/7 (alias)
  Referring: _ZTTSt14basic_ofstreamIcSt11char_traitsIcEE/178
(addr)_ZTTSt14basic_ofstreamIcSt11char_traitsIcEE/178 (addr)
  Availability: available
  Varpool flags: read-only const-value-known
$2 = void

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[5 Regression] LTO: ICE in  |[5 Regression][ICF] LTO:
                   |add_symbol_to_partition_1,  |ICE in
                   |at lto/lto-partition.c:158  |add_symbol_to_partition_1,
                   |                            |at lto/lto-partition.c:158

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Note that it compiles if I add "-fno-ipa-icf".

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> ---
> Note that it compiles if I add "-fno-ipa-icf".

Yeah, but it is partitioning bug; it should be able to deal with whatever
aliases ICF creates.
I will take a look tonight or tomorrow.

Honza

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I am with terrible internet connection and it still does not reproduce for me
(I suppose difference between GNU LD and gold).
It is however clear what happens, we try to add symbol's alias that is external
and we do not expect external symbols to be in partitions.

Does the following (untested) help?
Index: lto-partition.c
===================================================================
--- lto-partition.c     (revision 221399)
+++ lto-partition.c     (working copy)
@@ -198,7 +198,7 @@
   /* Add all aliases associated with the symbol.  */

   FOR_EACH_ALIAS (node, ref)
-    if (!node->weakref)
+    if (!node->weakref && !DECL_ExTERNAL (node->decl))
       add_symbol_to_partition_1 (part, ref->referring);

   /* Ensure that SAME_COMDAT_GROUP lists all allways added in a group.  */

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
please also attachg WPA dump of -fdump-ipa-cgraph. I would be interested what
visibility _ZTCN7Utility2IO12GUnzipStreamE0_So/7 has.

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Actually perhaps we manage to produce external alias of non-external symbol
that also should not happen.
Index: ipa-icf.c
===================================================================
--- ipa-icf.c   (revision 221461)
+++ ipa-icf.c   (working copy)
@@ -809,6 +809,15 @@ sem_function::merge (sem_item *alias_ite
   bool original_address_matters = original->address_matters_p ();
   bool alias_address_matters = alias->address_matters_p ();

+  if (DECL_EXTERNAL (alias->decl))
+    {
+      if (dump_file)
+       fprintf (dump_file,
+                "Not unifying; "
+                "alias is external.\n\n");
+      return false;
+    }
+
   if (DECL_NO_INLINE_WARNING_P (original->decl)
       != DECL_NO_INLINE_WARNING_P (alias->decl))
     {
@@ -1767,6 +1870,14 @@ sem_variable::merge (sem_item *alias_ite
                 "Symbol aliases are not supported by target\n\n");
       return false;
     }
+  if (DECL_EXTERNAL (alias->decl))
+    {
+      if (dump_file)
+       fprintf (dump_file,
+                "Not unifying; "
+                "alias is external.\n\n");
+      return false;
+    }

   sem_variable *alias_var = static_cast<sem_variable *> (alias_item);


May help.

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6185 bytes --]

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 35050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35050&action=edit
one.o.000i.cgraph: -fdump-ipa-cgraph for the LTO step for the unpatched GCC
(r221482)

(In reply to Jan Hubicka from comment #8, #9 and #10)

First, I can still reproduce the issue with the unpatched GCC. In addition, the
big program also compiles successfully with -fno-ipa-icf.

Regarding "ld": As /usr/bin/ld is very old, that's with the current "ld" from
the binutils-gdb GIT (via GCC's --with-plugin-ld=) - it fails identical when I
replace the ld.bfd by ld.gold.

Regarding -fdump-ipa-cgraph: If you prefer the dump of a patched version,
please tell me.

Regarding the patch in comment 8 (with "ExTERNAL" typo fixed): Unfortunately,
it doesn't solve the problem - I still get the same ICE.


Regarding the patch in comment 9: I had to change "alias" to "alias_item" due
to

../../gcc/ipa-icf.c:1779:22: error: ‘alias’ was not declared in this scope
   if (DECL_EXTERNAL (alias->decl))

but afterwards: It no longer has an ICE!
>From gcc-bugs-return-480624-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 18 08:22:24 2015
Return-Path: <gcc-bugs-return-480624-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 101370 invoked by alias); 18 Mar 2015 08:22:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 101299 invoked by uid 48); 18 Mar 2015 08:22:19 -0000
From: "ma.jiang at zte dot com.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65459] New: munaligned-access still produce split access codes
Date: Wed, 18 Mar 2015 08:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ma.jiang at zte dot com.cn
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65459-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01768.txt.bz2
Content-length: 1221

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

            Bug ID: 65459
           Summary: munaligned-access still produce split access codes
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ma.jiang at zte dot com.cn

Hi all,
  The munaligned-access option on ARM can not stop gcc from producing split
access codes. A very simple test 
char mt[20];
void main()
{
    void *mm=&(mt[1]);
  *(( int *)mm)=4;
}
  compiled with -O2 -munaligned-access could reproduce this problem.As we can
see,"*(( int *)mm)=4;"  cause gcc to emit 4 strb instructions not a unaligned
stw .
  In my opinion, this bug is caused by the SLOW_UNALIGNED_ACCESS macro,which is
defined to be 1 in arm.h. It is very strange that  the munaligned-access option
can affect neither  SLOW_UNALIGNED_ACCESS nor STRICT_ALIGNMENT. On PPC,the
mstrict-align can affect STRICT_ALIGNMENT， and SLOW_UNALIGNED_ACCESS is
determined by STRICT_ALIGNMENT, ALIGN, and MODE(args of the
SLOW_UNALIGNED_ACCESS macro). This is a good example for ARM, I think.
>From gcc-bugs-return-480625-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 18 08:48:49 2015
Return-Path: <gcc-bugs-return-480625-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 42555 invoked by alias); 18 Mar 2015 08:48:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 42527 invoked by uid 48); 18 Mar 2015 08:48:45 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65458] parloops transforms omp-thread functions
Date: Wed, 18 Mar 2015 08:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-65458-4-vOJY6Ea1RT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65458-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65458-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01769.txt.bz2
Content-length: 214

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide458

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 35051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5051&actioníit
tentative patch

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #11)
> Created attachment 35050 [details]
> one.o.000i.cgraph: -fdump-ipa-cgraph for the LTO step for the unpatched GCC
> (r221482)
> 
> (In reply to Jan Hubicka from comment #8, #9 and #10)
> 
> First, I can still reproduce the issue with the unpatched GCC. In addition,
> the big program also compiles successfully with -fno-ipa-icf.
> 
> Regarding "ld": As /usr/bin/ld is very old, that's with the current "ld"
> from the binutils-gdb GIT (via GCC's --with-plugin-ld=) - it fails identical
> when I replace the ld.bfd by ld.gold.
> 
> Regarding -fdump-ipa-cgraph: If you prefer the dump of a patched version,
> please tell me.
> 
> Regarding the patch in comment 8 (with "ExTERNAL" typo fixed):
> Unfortunately, it doesn't solve the problem - I still get the same ICE.
> 
> 
> Regarding the patch in comment 9: I had to change "alias" to "alias_item"
> due to
> 
> ../../gcc/ipa-icf.c:1779:22: error: ‘alias’ was not declared in this scope
>    if (DECL_EXTERNAL (alias->decl))
> 
> but afterwards: It no longer has an ICE!

Hello.

What's your target where you have the PR? I'm also unable to reproduce the
issue. Even with BFD.

Thanks,
Martin
>From gcc-bugs-return-480681-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 18 13:19:14 2015
Return-Path: <gcc-bugs-return-480681-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19464 invoked by alias); 18 Mar 2015 13:19:14 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19395 invoked by uid 48); 18 Mar 2015 13:19:10 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
Date: Wed, 18 Mar 2015 13:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-65238-4-5NDXB0thTl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65238-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65238-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01825.txt.bz2
Content-length: 291

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide238

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Ah, thanks! The patch fixed as in coment #10 is OK for mainline.  We obviously
should not try to do any merging of external symbols; it is pointless. We only
want to calculate equivalences on these to merge non-externals referencing
them.

Patch is OK with the fixes and testcase.

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed in 5.0.0.
>From gcc-bugs-return-480856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 19 17:45:33 2015
Return-Path: <gcc-bugs-return-480856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 82815 invoked by alias); 19 Mar 2015 17:45:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 82736 invoked by uid 48); 19 Mar 2015 17:45:25 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
Date: Thu, 19 Mar 2015 18:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65238-4-GvCurqzlmW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65238-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65238-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02000.txt.bz2
Content-length: 194

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide238

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Patch awaiting ack:
http://gcc.gnu.org/ml/gcc-patches/2015-03/msg00647.html