https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #16 from Christophe Lyon ---
Author: clyon
Date: Fri Apr 5 15:10:12 2019
New Revision: 270168
URL: https://gcc.gnu.org/viewcvs?rev=270168=gcc=rev
Log:
[testsuite] PR71598: Fix testcases again
2019-04-05 Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #15 from Christophe Lyon ---
Author: clyon
Date: Wed Apr 3 13:17:04 2019
New Revision: 270126
URL: https://gcc.gnu.org/viewcvs?rev=270126=gcc=rev
Log:
[testsuite] PR71598: Fix testcases
2019-04-13 Christophe Lyon
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #13 from Richard Biener ---
Author: rguenth
Date: Mon Apr 1 07:16:38 2019
New Revision: 270052
URL: https://gcc.gnu.org/viewcvs?rev=270052=gcc=rev
Log:
2019-04-01 Richard Biener
PR c/71598
* gimple.c: Include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #12 from Richard Biener ---
Created attachment 45973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45973=edit
patch I am testing
I am testing the following. I needed to adjust the testcase a bit to make
the C++ FE happy, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #11 from Eric Botcazou ---
> I see. Do you prefer a langhook solution that would "fix" this only
> for C/C++ and LTO then?
That sounds like the best approach to me, but I'm no expert here.
> OK, I see. VRP still expects it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #10 from rguenther at suse dot de ---
On Fri, 15 Mar 2019, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
>
> --- Comment #9 from Eric Botcazou ---
> > Btw, I tried to use TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #9 from Eric Botcazou ---
> Btw, I tried to use TREE_TYPE (TYPE_MIN_VALUE ()) of the ENUMERAL_TYPE but
> that breaks with Ada (bah, no libbacktrace support there...):
Probably because of:
/* Note that the bounds are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #7 from joseph at codesourcery dot com ---
The relation definitely is not transitive (so you can't declare the same
function to return two different enum types, for example).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #6 from Alexander Monakov ---
... and even considering that the standard never actually says that "compatible
type" relation is transitive, and so two enums technically need not be
compatible with each other, the following should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #5 from Alexander Monakov ---
C11 6.7.2.2 p4 says,
Each enumerated type shall be compatible with char, a signed integer type, or
an unsigned integer type [...]
and 6.5 p7 says,
An object shall have its stored value accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #4 from Richard Biener ---
Note I can't find any bit in the C standard that would make the testcase
well-defined and support reporters view. My clang version doesn't "miscompile"
it though.
With LTO we'd treat both enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Alexander Monakov changed:
What|Removed |Added
Keywords||wrong-code
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
16 matches
Mail list logo
