Hi,
This is what ISO C says:
Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined,110) but shall be capable of representing the
values of all the members of the enumeration.
110) An implementation may
On Feb 6, 2008 1:18 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> >
> > So, shouldn't gcc allow this without warnings then?
> >
> > typedef enum OMX_ERRORTYPE
> > {
> > OMX_ErrorNone = 0,
> > OMX_ErrorInsufficientResources = 0x
On 06/02/2008, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 06 February 2008 11:05, Felipe Contreras wrote:
>
> > So, shouldn't gcc allow this without warnings then?
> >
> > typedef enum OMX_ERRORTYPE
> > {
> > OMX_ErrorNone = 0,
> > OMX_ErrorInsufficientResources = 0x80001000
> > } OMX_ERRORTYPE;
On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
>
> So, shouldn't gcc allow this without warnings then?
>
> typedef enum OMX_ERRORTYPE
> {
> OMX_ErrorNone = 0,
> OMX_ErrorInsufficientResources = 0x80001000
> } OMX_ERRORTYPE;
>
And what warning do you get and with which version of GC
On 06 February 2008 11:05, Felipe Contreras wrote:
> So, shouldn't gcc allow this without warnings then?
>
> typedef enum OMX_ERRORTYPE
> {
> OMX_ErrorNone = 0,
> OMX_ErrorInsufficientResources = 0x80001000
> } OMX_ERRORTYPE;
>
> Best regards.
Does this work any better?
typedef enum OMX
On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> On Feb 6, 2008 1:18 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > On 06/02/2008, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> > >
> > > So, shouldn't gcc allow this without warnings then?
> > >
> > > typedef enum OMX_ERRORTYPE
>
I have here:
vin:~> /usr/lib/gcc/x86_64-linux-gnu/4.3/cc1 --version
GNU C (Debian 4.3-20080202-1) version 4.3.0 20080202 (experimental) [trunk
revision 132072] (x86_64-linux-gnu)
compiled by GNU C version 4.3.0 20080202 (experimental) [trunk revision
132072], GMP version 4.2.2, MPFR vers
"Felipe Contreras" <[EMAIL PROTECTED]> writes:
> This is what ISO C says:
>
> Each enumerated type shall be compatible with char, a signed integer
> type, or an unsigned integer type. The choice of type is
> implementation-defined,110) but shall be capable of representing the
> values of all the m
On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> I have here:
>
> Shouldn't it give more information about the GMP and MPFR versions,
> such as the library versions used at runtime?
Those are the library versions used at runtime, aren't they?
> FYI, I use the following code (or similar
On Feb 6, 2008 2:47 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Felipe Contreras" <[EMAIL PROTECTED]> writes:
>
> > This is what ISO C says:
> >
> > Each enumerated type shall be compatible with char, a signed integer
> > type, or an unsigned integer type. The choice of type is
> > implementat
On Mon, 4 Feb 2008, Richard Guenther wrote:
> Following the old discussions at
>
> http://gcc.gnu.org/ml/gcc/2007-04/msg00096.html
With starting to prototype the proposed MEM_REF scheme I noticed
a few things that I'd like to add. First let me summarize the
idea again. The idea is to unify
Can I get some help on this.
-- Forwarded message --
From: Pavan R <[EMAIL PROTECTED]>
Date: Jan 29, 2008 5:27 PM
Subject: Fwd: _Unwind_Resume on the stack
To: gcc@gcc.gnu.org
No, We have compiled our application on RHEL 3 with libgcc-3.2.3-34.
On Jan 29, 2008 3:44 PM, Andrew
On 2008-02-06 13:57:06 +0100, Manuel López-Ibáñez wrote:
> See gcc/toplev.c (print_version) for the relevant code in GCC. (It
> gives a warning when there is a mismatch between runtime and header
> versions, otherwise it just prints the latter).
OK, I didn't see that there could be a warning. In f
On 06 February 2008 13:01, Felipe Contreras wrote:
> On Feb 6, 2008 2:47 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> "Felipe Contreras" <[EMAIL PROTECTED]> writes:
>>
>>> This is what ISO C says:
>>>
>>> Each enumerated type shall be compatible with char, a signed integer
>>> type, or an un
Ramana Radhakrishnan wrote:
> Hi ,
>
> I've been investigating an interesting case with the following
> testcase in my private port. I know this is a slightly theoretical
> case but I believe one that should be handled cleanly.
>
> I haven't yet been able to replicate this on any other port yet whi
On 2008-02-06 14:59:21 -, Dave Korn wrote:
> So, how about
>
> typedef enum OMX_ERRORTYPE
> {
>OMX_ErrorNone = 0,
>OMX_ErrorInsufficientResources = (int)0x80001000
> } OMX_ERRORTYPE;
>
> ?
You should get a warning in the cases where 0x80001000 isn't
representable in an int becau
Andrew MacLeod wrote:
There are a few things that I'm considering working on for the 4.4
release, and I figured I'd see what others thought. Is anyone
considering/doing similar or related work?
I'll summarize each, and then go into more details.
1 - Pass cleanup. There have been rumblings
On Wed, Feb 06, 2008 at 10:59:12AM -0500, Kenneth Zadeck wrote:
> > The final code generated appears something like the following.
> >
> > foo:
> > cmpslt $c6,$zero,$c1
> > brz $c6,$link
> > i2cs$c6,@MID_11(4660)
> > i2c $c6,@BOT_11(4660)
> > inc
> I'm not sure what to do about bit-aligned TImode fields
> for example, or other things that appearantly can be done with Ada
> (which allows bit-packing).
I think that we can live without TImode bitfields, up to DImode would be fine.
--
Eric Botcazou
Hi,
Is there any interest in getting the testsuite failures in objc++ fixed?
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00401.html
I generally include it in my testsuite results and I can file bug reports,
etc. but I want to know if it's worthwhile or not. The ChangeLog for it
contains mo
On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> You should get a warning in the cases where 0x80001000 isn't
> representable in an int because it is an implementation-defined
> behavior. Is there any reason why gcc doesn't issue one?
Maybe I don't understand what you are asking but fro
Daniel Jacobowitz wrote:
> On Wed, Feb 06, 2008 at 10:59:12AM -0500, Kenneth Zadeck wrote:
>
>>> The final code generated appears something like the following.
>>>
>>> foo:
>>> cmpslt $c6,$zero,$c1
>>> brz $c6,$link
>>> i2cs$c6,@MID_11(4660)
>>> i2c $
On 2008-02-06 18:52:16 +0100, Manuel López-Ibáñez wrote:
> Maybe I don't understand what you are asking but from reading the code
> and relevant testcases, it seems that:
>
> * Unsigned integer constants for enum values are handled just fine by
> GCC as a extension to the C language. (See testsuit
On 06 February 2008 18:22, Vincent Lefevre wrote:
> On 2008-02-06 18:52:16 +0100, Manuel López-Ibáñez wrote:
>> Maybe I don't understand what you are asking but from reading the code
>> and relevant testcases, it seems that:
>>
>> * Unsigned integer constants for enum values are handled just fine
On Wed, 6 Feb 2008, Eric Botcazou wrote:
> > I'm not sure what to do about bit-aligned TImode fields
> > for example, or other things that appearantly can be done with Ada
> > (which allows bit-packing).
>
> I think that we can live without TImode bitfields, up to DImode would be fine.
I was mai
On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2008-02-06 18:52:16 +0100, Manuel López-Ibáñez wrote:
> > Maybe I don't understand what you are asking but from reading the code
> > and relevant testcases, it seems that:
> >
> > * Unsigned integer constants for enum values are handled
> I was mainly worried about us trying to for example copy a bit-packed
> substructure like
>
> struct A {
> unsigned use_1_bit : 1;
> struct B {
> char large[100];
> } b;
> } a, b;
>
> where b.large[0] is at offset 1 bit of a (I believe this is possible
> with Ada, right?).
Actually no,
> I was mainly worried about us trying to for example copy a bit-packed
> substructure like
>
> struct A {
> unsigned use_1_bit : 1;
> struct B {
> char large[100];
> } b;
> } a, b;
>
> where b.large[0] is at offset 1 bit of a (I believe this is possible
> with Ada, right?).
It is poss
On Wed, 6 Feb 2008, Richard Kenner wrote:
> > I was mainly worried about us trying to for example copy a bit-packed
> > substructure like
> >
> > struct A {
> > unsigned use_1_bit : 1;
> > struct B {
> > char large[100];
> > } b;
> > } a, b;
> >
> > where b.large[0] is at offset 1 bit
On Feb 6, 2008, at 9:58 AM, Kaveh R. GHAZI wrote:
Is there any interest in getting the testsuite failures in objc++
fixed?
Yes, but, if you have other, more important things... :-)
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00401.html
I generally include it in my testsuite results an
On 2008-02-06 21:17:53 +0100, Manuel López-Ibáñez wrote:
> On 06/02/2008, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> > The problem is the cast (suggested by Dave Korn), not the enum itself:
> > (int) 0x80001000
> >
>
> What is the problem with the cast? Do you want a warning for the
> conversion
Snapshot gcc-4.2-20080206 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080206/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Is sh-elf/sim supposed to support profiling? My latest tests show all
the profiling tests failing. For example, the bprob executable has
the name of the gcda file in it, but doesn't attempt to write it out
(verified with strace against the simulator).
We have a bunch of stack alignment run-time tests for C++. We
like to run them with difffernet optimization flags, like
-O0, -O1, -O2, ..., similar to those under gcc.c-torture/execute.
Is there a way to do it for C++?
Thanks.
H.J.
On Feb 6, 2008 2:50 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> We have a bunch of stack alignment run-time tests for C++. We
> like to run them with difffernet optimization flags, like
> -O0, -O1, -O2, ..., similar to those under gcc.c-torture/execute.
> Is there a way to do it for C++?
I guess you
Richard Guenther wrote:
You can apart from the other suggestions also mark the function weak
which will prevent both inlining and pure/const analysis.
How about just writing to a volatile variable from within the callee?
void f() __attribute__((noinline)) {
volatile int i;
i = 3;
}
void
Doug Gregor wrote:
PR c++/34935 illustrates a problem with the way attributes interact
with type identity. The example in question looks something like this:
typedef int X __attribute((may_alias));
void foo(X);
void foo(int);
Note that this is pretty tied up with Mark Mitchell's discus
DJ Delorie <[EMAIL PROTECTED]> wrote:
> Is sh-elf/sim supposed to support profiling? My latest tests show all
> the profiling tests failing. For example, the bprob executable has
> the name of the gcda file in it, but doesn't attempt to write it out
> (verified with strace against the simulator).
> Is your gcc configured with --with-newlib --with-headers?
$TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \
--enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local
I do a two-phase build. I build gcc (and let it fail for libgcc) to
get xgcc/cc1, then build and install newlib,
DJ Delorie <[EMAIL PROTECTED]> wrote:
>> Is your gcc configured with --with-newlib --with-headers?
>
> $TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \
> --enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local
>
> I do a two-phase build. I build gcc (and let it fail for libgcc)
I see the following failure on i386-linux and powerpc-linux
Matthias
/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/xgcc
-B/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/
-B/usr/i486-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall
> Hmm... Did you try --with-headers?
I'll give that a try.
Matthias Klose wrote:
I see the following failure on i386-linux and powerpc-linux
Matthias
/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/xgcc
-B/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080206/build/./prev-gcc/
-B/usr/i486-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer
Hi DJ
> Is sh-elf/sim supposed to support profiling? My latest tests show all
> the profiling tests failing. For example, the bprob executable has
> the name of the gcda file in it, but doesn't attempt to write it out
> (verified with strace against the simulator).
I guess it probably doesn't a
> I guess it probably doesn't apply in this case (if you've straced the
> simulator), but please also keep in mind another gotcha:
>
> http://gcc.gnu.org/ml/gcc/2006-12/msg00561.html
Yeah, doesn't apply. There were no *attempts* at I/O from the
simulator. I'm more inclined to think that th
> Date: Wed, 06 Feb 2008 15:59:21 -0800
> From: Mark Mitchell <[EMAIL PROTECTED]>
> Richard Guenther wrote:
>
> > You can apart from the other suggestions also mark the function weak
> > which will prevent both inlining and pure/const analysis.
>
> How about just writing to a volatile variable f
On Wed, 6 Feb 2008, Richard Guenther wrote:
> (anyone for an Ada tutorial during the summit? ;)
(I wish I didn't see that smiley, because)
For practical reasons, I'd agree that's a very good idea!
I mean, those (hopefully "we") who attend could presumably hear
about some subset that relates to GC
> > (anyone for an Ada tutorial during the summit? ;)
>
> (I wish I didn't see that smiley, because)
> For practical reasons, I'd agree that's a very good idea!
>
> I mean, those (hopefully "we") who attend could presumably hear
> about some subset that relates to GCC developers, instead of
> goi
On Feb 6, 2008 9:02 PM, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Which would be more interesting: a tutorial on the Ada language itself or
> on the "demands" it places on GCC?
I would say that both tutorials sound interesting ;-)
When I first heard a tutorial on the Ada language, I found it ve
Emacs 22.1 has a graphical interface to Gdb which allows the display of
watch expressions in the Speedbar.
Using variable objects, if I display a watch expression for an STL container
in a program compiled with gcc, e.g.,
vector v (3);
v[0] = 1;
v[1] = 11;
v[2] = 22;
in the Speedbar, I
On 12/5/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 05, 2007 at 04:32:00PM -0500, NightStrike wrote:
> > On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > Patch manager will be dying for a week or two while i change hosting.
> > >
> > > of course, if nobody is sti
Hello
I'm working on a gcc port to a hobby operating system. I got it working
partially (cc1 works and I think I'm not far from get the gcc frontend
working).
Now i wanted to rename my target from i386-elf-lost to i386-pc-lost because I
was told that this would be more canonical. (I don't want
52 matches
Mail list logo
