This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lto] RFC: How should gimple represent enums?


On Thu, Mar 12, 2009 at 13:08, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo <dnovillo@google.com> wrote:
>> This is related to the different FE behaviour on const arguments that
>> I posted earlier (http://gcc.gnu.org/ml/gcc/2009-03/msg00316.html).
>> When an enum E is compiled by two different front ends, when we try to
>> combine them in lto1, we trigger an ODR violation because we try to
>> assert that both enums have the same type bounds (TYPE_MIN_VALUE and
>> TYPE_MAX_VALUE).
>
> Actually... Question.
> You have an enum and you compile it with C and C++. ÂBut the semantics
> for the enum are different for the two languages, AFAIU. So why do we
> try to combine/merge the types to begin with?

It's to handle this case:

$ cat f.h
enum Values { ONE, TWO, THREE };

$ cat f1.cc
#include "f.h"
extern "C" { extern enum Values x; };

$ cat f2.c
#include "f.h"
enum Values x = TWO;

$ g++ -flto -c f1.cc
$ gcc -flto -c f2.c
$ gcc -flto -o f f1.o f2.o


The symbol 'x' is provided by the C file, but both FEs have a slightly
different notion of what the enum values are.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]