Ralf Corsepius writes:
> However, the rationale why autoconf is doing so, so far escapes me.
Read the comments.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
On 31 January 2011 12:16, Hagen Paul Pfeifer wrote:
>
> On Mon, 31 Jan 2011 09:19:07 +, Jonathan Wakely wrote:
>
>> The code is wrong. sizeof expects either an expression, or a
>> parenthesized type-id. (long) is not a type-id so ((long)) is not a
>> parenthesized type-id, therefore it must be
On 01/31/2011 01:02 PM, Andreas Schwab wrote:
Ralf Corsepius writes:
ATM, I am not sure, if what autoconf does actually is useful, but this
is a different matter.
autoconf needs to deliberately trigger errors in a lot of its tests in
order to do the right thing.
I know, but ...
... the auto
On Mon, 31 Jan 2011 09:19:07 +, Jonathan Wakely wrote:
> The code is wrong. sizeof expects either an expression, or a
> parenthesized type-id. (long) is not a type-id so ((long)) is not a
> parenthesized type-id, therefore it must be interpreted as an
> expression, but it's not a valid
Ralf Corsepius writes:
> ATM, I am not sure, if what autoconf does actually is useful, but this
> is a different matter.
autoconf needs to deliberately trigger errors in a lot of its tests in
order to do the right thing.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8
On 01/31/2011 10:19 AM, Jonathan Wakely wrote:
On 31 January 2011 08:59, Ralf Corsepius wrote:
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo’:
On 31 January 2011 08:59, Ralf Corsepius wrote:
> Hi,
>
> gcc emits an error, when compiling this code-snippet:
>
> --- snip ---
> extern int x;
>
> void
> foo (void)
> {
> x = sizeof ((long));
> }
> --- snip ---
>
> # gcc -Wall -o tmp.o -c tmp.c
> tmp.c: In function ‘foo’:
> tmp.c:6:21: error: e
Bruce Korb wrote:
> Hi,
>
> I was trying to figure out how come a memory allocation was short.
> I think I've stumbled onto the issue. "evt_t" is a 48 byte structure
> and "tpd_uptr" is a uintptr_t. "sz" initializes to 52 (decimal).
> The value would be correct if I were not trying to multiply t
On Wed, Apr 09, 2008 at 01:22:15PM +0100, Andrew Haley wrote:
> [EMAIL PROTECTED] wrote:
> > Dear gcc users and developers,
> >
> > This might be a stupid question, nevertheless...
> >
> > I've been wondering for a long time, why the behaviour of
> > variable-length arrays w.r.t. the sizeof
[EMAIL PROTECTED] wrote:
> Dear gcc users and developers,
>
> This might be a stupid question, nevertheless...
>
> I've been wondering for a long time, why the behaviour of
> variable-length arrays w.r.t. the sizeof operator is different
> for local/auto variables and for function arguments
On Feb 16, 2007, at 8:57 AM, Rutger Hofman wrote:
If I declare the struct 'packed', then it is size 2. That is enough
for my purposes. I hope that won't greatly change through versions...
Also, there is:
@item [EMAIL PROTECTED]
@opindex mstructure-size-boundary
The size of all structures and
Paul Brook wrote:
My (embedded) development system is gcc-3.2.1 arm-elf. I don't really
understand its value for sizeof(struct { short x }).
sizeof s_sh 4
sizeof short 2
This is a feature of the ARM ABI you are using. All structures are word
aligned (which implies being word sized).
Paul
> My (embedded) development system is gcc-3.2.1 arm-elf. I don't really
> understand its value for sizeof(struct { short x }).
> sizeof s_sh 4
> sizeof short 2
This is a feature of the ARM ABI you are using. All structures are word
aligned (which implies being word sized).
Paul
On Fri, Jul 01, 2005 at 10:45:19AM +0200, Etienne Lorrain wrote:
> The result of this funtion is 1, is there a C lawyer around?
The parameter is treated as unsigned* since an array is converted to
a pointer when passed through a function.
C99 says in 6.7.5.3:
[#7] A declaration of a parame
Etienne Lorrain writes:
> The result of this funtion is 1, is there a C lawyer around?
>
> $ cat tmp.c
> unsigned fct (unsigned array[10])
> {
> return sizeof(array) / sizeof(array[0]);
> }
This is 6.7.5.3, Para. 7.
Andrew.
Am Freitag, 3. Juni 2005 10:48 schrieb Mark Mitchell:
> DJ Delorie wrote:
> > Do we have a standard way of telling the testsuite how big target
> > types are, or some standard "this test assumes 32 bit int" dejagnu
> > flag?
>
> I don't think we have any way of doing this at present. I could be
>
> struct-layout-1_generate.c is run on the host, not on the target.
> And for hosts AFAIK GCC requires 32-bit int.
But the structures it generates assume 32-bit ints:
T(0,enum E2 a:31;,B(0,a,e2_m1,e2_0))
You can't have a 31 bit enum on a 16 bit target. You get messages
like this:
On Fri, Jun 03, 2005 at 11:14:15AM +0200, Jakub Jelinek wrote:
> On Fri, Jun 03, 2005 at 02:07:57AM -0700, Mark Mitchell wrote:
> > >Doesn't "is-effective-target ilp32" test for 32 bits int?
> >
> > Good point! I forgot about that. My brain is stuck in some other year.
> >
> > That doesn't let
On Thu, Jun 02, 2005 at 09:49:03PM -0400, DJ Delorie wrote:
>
> gcc.dg/compat/struct-layout-1_generate.c assumes sizeof(int) is 4.
> This of course fails on any target where sizeof(int) is 2. They may
> fail when sizeof(int) is 8 too, or at least they won't be testing the
> full range of possibil
On Fri, Jun 03, 2005 at 02:07:57AM -0700, Mark Mitchell wrote:
> >Doesn't "is-effective-target ilp32" test for 32 bits int?
>
> Good point! I forgot about that. My brain is stuck in some other year.
>
> That doesn't let you adjust the test based on the compiler, but it does
> let you skip test
Steven Bosscher wrote:
On Friday 03 June 2005 10:48, Mark Mitchell wrote:
DJ Delorie wrote:
Do we have a standard way of telling the testsuite how big target
types are, or some standard "this test assumes 32 bit int" dejagnu
flag?
I don't think we have any way of doing this at present. I c
On Friday 03 June 2005 10:48, Mark Mitchell wrote:
> DJ Delorie wrote:
> > Do we have a standard way of telling the testsuite how big target
> > types are, or some standard "this test assumes 32 bit int" dejagnu
> > flag?
>
> I don't think we have any way of doing this at present. I could be
> wro
DJ Delorie wrote:
Do we have a standard way of telling the testsuite how big target
types are, or some standard "this test assumes 32 bit int" dejagnu
flag?
I don't think we have any way of doing this at present. I could be
wrong, though. We could certainly add logic to compute this, using
23 matches
Mail list logo
