Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 04:03:53PM GMT, Jakub Jelinek wrote: > E.g. consider GCC > #define iterative_hash_object(OB,INIT) iterative_hash (&OB, sizeof (OB), INIT) > macro. > If one uses it on the function parameters declared as arrays but turned into > pointers and you know what

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 03:42:06PM +0200, Jakub Jelinek via Gcc wrote: > On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote: > > The problem with that is that the error will still be enforced _after_ > > GCC would change the behavior of sizeof(aparam). > > I

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, 9 Aug 2024, Alejandro Colomar via Gcc wrote: > Since I don't see any legitimate uses of sizeof(aparam) as of today, I > don't expect having any consequences on existing code. (But please > point me wrong if there are any, maybe in generic macros.) It's perfectly

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote: > The problem with that is that the error will still be enforced _after_ > GCC would change the behavior of sizeof(aparam). I don't think it should unless C2Y requires that. > Admittedly, I could write confi

Re: Promote -Wno-sizeof-array-argument to an error

Hi Jakub, On Fri, Aug 09, 2024 at 02:24:48PM GMT, Jakub Jelinek wrote: > You can compile your sources with -Werror=sizeof-array-argument if you want > it to be an error, The problem with that is that the error will still be enforced _after_ GCC would change the behavior of sizeof(

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 02:19:26PM +0200, Alejandro Colomar via Gcc wrote: > On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > > Hi Martin, > > > > > > Can we promote

Re: Promote -Wno-sizeof-array-argument to an error

Hi Martin, On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's

Re: Promote -Wno-sizeof-array-argument to an error

On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's any legiti

Re: Promote -Wno-sizeof-array-argument to an error

Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > Hi Martin, > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > think there's any legitimate use sizeof() on such a parameter. I am a bit worried that it might prevent p

Re: Promote -Wno-sizeof-array-argument to an error

On Thu, Aug 08, 2024 at 02:36:36AM GMT, Alejandro Colomar wrote: > Hi Martin, > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't D'oh! I obviously meant -Wsizeof-array-argument. > think there's any legitimate use sizeof() on such a par

Promote -Wno-sizeof-array-argument to an error

Hi Martin, Can we promote -Wno-sizeof-array-argument to a hard error? I don't think there's any legitimate use sizeof() on such a parameter. It would be an incompatible extension to ISO C, which would make sure that there are no remaining uses of sizeof(array_param), which would itsel

Re: [ARM] unexpected sizeof() of a complex packed type

w5; > unsigned short addr_high_high; > unsigned short length; > } __attribute((packed)); > > struct wil_rx_enhanced_desc { > struct wil_ring_rx_enhanced_mac mac; > struct wil_ring_rx_enhanced_dma dma; > } __attribute((packed)); > > union wil_rx_desc { &

[ARM] unexpected sizeof() of a complex packed type

; } __attribute((packed)); union wil_rx_desc { struct vring_rx_desc legacy; struct wil_rx_enhanced_desc enhanced; } __attribute__((packed)); union wil_ring_desc { union wil_tx_desc tx; union wil_rx_desc rx; } __attribute__((packed)); int f (void) { return sizeof

Re: Should GCC warn about sizeof(flexible_struct)?

mention there to the FAM case in a comment: > <https://software.codidact.com/comments/thread/7169#comment-21254> > >> >> I any case, I am not so concerned about the whether this UB,  >> but that a programmer might do: >> >> struct s = { .. } >> s

Re: Should GCC warn about sizeof(flexible_struct)?

any case, I am not so concerned about the whether this UB,  > but that a programmer might do: > > struct s = { .. } > struct s* p = malloc(...) > memcpy(p, &s, sizeof s); // copy header. That's (or could be) a bug, and just another manifestation of why sizeof(s) is

Re: Should GCC warn about sizeof(flexible_struct)?

r structures, as the size of the enclosing >> aggregate type would be... inconsistent. >> >> In general, sizeof(flexible_struct) is a problematic thing that rarely >> means what programmers think it means. It is not the size of the >> structure up to the f

Re: Should GCC warn about sizeof(flexible_struct)?

Am Montag, dem 14.08.2023 um 11:51 +0200 schrieb Alejandro Colomar via Gcc: > Hi Richard, > > On 2023-08-14 08:41, Richard Biener wrote: > > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc > > wrote: > > [...] > > > > How about some -Wfam-size

Re: Should GCC warn about sizeof(flexible_struct)?

Hi Richard, On 2023-08-14 08:41, Richard Biener wrote: > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc > wrote: [...] >> How about some -Wfam-sizeof-arithmetic that would not warn about taking >> sizeof(s) but would warn if that sizeof is used in any arithmet

Re: Should GCC warn about sizeof(flexible_struct)?

On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc wrote: > > Hi! > > Structures with flexible array members have restrictions about being > used in arrays or within other structures, as the size of the enclosing > aggregate type would be... inconsistent. >

Re: Should GCC warn about sizeof(flexible_struct)?

On 2023-08-11 20:29, Alejandro Colomar wrote: > Hi! > > Structures with flexible array members have restrictions about being > used in arrays or within other structures, as the size of the enclosing > aggregate type would be... inconsistent. > > In general, sizeof(

Should GCC warn about sizeof(flexible_struct)?

Hi! Structures with flexible array members have restrictions about being used in arrays or within other structures, as the size of the enclosing aggregate type would be... inconsistent. In general, sizeof(flexible_struct) is a problematic thing that rarely means what programmers think it means

Re: RFC noipa sizeof function for record relayout at link time

On Mon, 29 Jun 2020, Erick Ochoa wrote: > We are not targeting C++ at the moment. What contexts exist in C where we > require constant expressions? On the top of my head I have array sizes and > initialization of static variables? In such cases, then yes we agree that we Bit-field widths, static

Re: RFC noipa sizeof function for record relayout at link time

[...] >> >>> * Disable constant propagation and other optimizations: >>> * possibly __attribute__((noipa)) >> >> [...] >> >>> == What's the WORST CASE performance of having an unknown sizeof? == >>> >>> I was concerned tha

Re: RFC noipa sizeof function for record relayout at link time

CASE performance of having an unknown sizeof? == I was concerned that the values generated by sizeof might be used by constant propagation and other optimizations might depend on this value. So, in order to have an idea of the impact of this transformation might have on code, I manually changed all s

Re: RFC noipa sizeof function for record relayout at link time

Hi, On Mon, Jun 29 2020, Erick Ochoa wrote: > == How do we get what we want? == > > Ideally what we want is to: > [...] > * Disable constant propagation and other optimizations: >* possibly __attribute__((noipa)) [...] > == What's the WORST CASE performance o

Re: RFC noipa sizeof function for record relayout at link time

results we have so far, but there are a couple of missing pieces left to work on: Implementations of sizeof and offsetof that support this change in struct layout at link time. == What is the problem? == Currently, for both sizeof and offsetof, the C parser will replace these statements with

Re: RFC noipa sizeof function for record relayout at link time

pieces left to work on: Implementations of sizeof and offsetof that support this change in struct layout at link time. == What is the problem? == Currently, for both sizeof and offsetof, the C parser will replace these statements with trees that correspond to the value returned by sizeof and

Re: RFC noipa sizeof function for record relayout at link time

On Mon, Jun 29, 2020 at 01:05:20PM +0200, Richard Biener via Gcc wrote: > > // source code > > struct astruct a; > > memset(a, 0, sizeof(a)); > > > > // parse time > > memset(a, 0, 64); Actually, I don't see the point at all, it doesn't matter if

Re: RFC noipa sizeof function for record relayout at link time

e to sharing the results we > > have so far, but there are a couple of missing pieces left to work on: > > > > Implementations of sizeof and offsetof that support this change in > > struct layout at link time. > > > > == What is the problem? == > > > >

Re: RFC noipa sizeof function for record relayout at link time

es left to work on: > > Implementations of sizeof and offsetof that support this change in > struct layout at link time. > > == What is the problem? == > > Currently, for both sizeof and offsetof, the C parser will replace these > statements with trees that correspond to the value retur

RFC noipa sizeof function for record relayout at link time

Hello, I have been working on link time optimization for C that may change the size of structs (at link time). We are close to sharing the results we have so far, but there are a couple of missing pieces left to work on: Implementations of sizeof and offsetof that support this change in

Re: Question about sizeof after struct change

> struct S { int unused; int used; }; > static_assert( sizeof(S) == 8 ); > S s[4]; > int* s2_used = (int*)((char*)s + 20); > > Accessing the field doesn't refer to S::used or S::unused directly, > and doesn't use sizeof(S) or sizeof(int) explicitly. > > So if your p

Re: Question about sizeof after struct change

On Fri, 3 Jan 2020 at 16:09, Erick Ochoa wrote: > Do you mean something like taking the address of a struct and adding an offset > to access a field? Yes, the following code is valid: struct S { int unused; int used; }; static_assert( sizeof(S) == 8 ); S s[4]; int* s2_used = (int*)((char*)

Re: Question about sizeof after struct change

On 2019-12-24 2:37 a.m., Richard Biener wrote: > On December 23, 2019 6:30:31 PM GMT+01:00, Erick Ochoa > wrote: >> Hi, >> >> I am working on an LTO pass which drops unused fields on structs. On my >> tests, I found that the gimple generated for `sizeof` is a co

Re: Question about sizeof after struct change

On 12/23/19 12:30 PM, Erick Ochoa wrote: Hi, I am working on an LTO pass which drops unused fields on structs. On my tests, I found that the gimple generated for `sizeof` is a constant. For example, for the following C code: ``` you also need to pay attention to offsetof. nathan -- Nathan

Re: Question about sizeof after struct change

On December 23, 2019 6:30:31 PM GMT+01:00, Erick Ochoa wrote: >Hi, > >I am working on an LTO pass which drops unused fields on structs. On my >tests, I found that the gimple generated for `sizeof` is a constant. >For >example, for the following C code: > >``` >struct a

Question about sizeof after struct change

Hi, I am working on an LTO pass which drops unused fields on structs. On my tests, I found that the gimple generated for `sizeof` is a constant. For example, for the following C code: ``` struct astruct_s { _Bool c; _Bool a; _Bool b; }; struct astruct_s astruct; int main() { int size = sizeof

Re: alignof(type, field); sizeof(type, field); typeof(type, field): getting type information on nested field

struct A > { > struct > { > type_t t; > } B; > }; > > typeof(((struct A *)NULL)->B.t) V; > > It would have been some much pleasing to have 2 parameters version of > sizeof(), typeof(), and alignof(), which would look like a lot like > offs

alignof(type, field); sizeof(type, field); typeof(type, field): getting type information on nested field

It would have been some much pleasing to have 2 parameters version of sizeof(), typeof(), and alignof(), which would look like a lot like offsetof() usage: typeof(struct A, B.t) V; if (sizeof(struct A, B.t) != sizeof(long)) ... ; if (alignof(struct A, B.t) < alignof(long)) ... ; As siz

Feature Request: sizeof/typeof/offsetof for bit-fields

I'm writing a binding generator and would love a way to get the size, type, and offset of bit fields of an arbitrary struct. To implement, it appears that 'bit_position' in tree.c has the information required. As a stranger to GCC development, what is the process to get such an extension? Daurn.

Re: Next question: sizeof(char buf[2042])

On Wed, Jun 20, 2018 at 11:47:45AM -0700, Bruce Korb wrote: > Yeah, I guess this is Clang, but is it a legal interpretation for Clang? > > In file included from gnu-pw-mgr.c:24: > > In file included from ./fwd.h:288: > > *./seed.c:178:43: **warning: **sizeof on pointer

Re: Next question: sizeof(char buf[2042])

288: > > *./seed.c:178:43: **warning: **sizeof on pointer operation will return > size of 'const char *' instead of 'const char [2042]'* > > * [-Wsizeof-array-decay]* > > char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG))); > > *

Next question: sizeof(char buf[2042])

Yeah, I guess this is Clang, but is it a legal interpretation for Clang? In file included from gnu-pw-mgr.c:24: In file included from ./fwd.h:288: *./seed.c:178:43: **warning: **sizeof on pointer operation will return size of 'const char *' instead of 'const char [2042]'

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On 10 November 2014 16:49, Joel Sherrill wrote: > I just submitted a patch using stdint.h and uintptr_t to gcc-patches. libstdc++ patches must be CCd to the libstdc++ list.

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On 11/10/2014 10:59 AM, Joseph Myers wrote: > On Mon, 10 Nov 2014, Joel Sherrill wrote: > >> On 11/10/2014 10:32 AM, Joseph Myers wrote: >>> On Sat, 8 Nov 2014, Paolo Carlini wrote: >>> Good. Sorry, if I missed some relatively recent development: is now GCC installing its own stdint.h on

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On Mon, 10 Nov 2014, Joel Sherrill wrote: > On 11/10/2014 10:32 AM, Joseph Myers wrote: > > On Sat, 8 Nov 2014, Paolo Carlini wrote: > > > >> Good. Sorry, if I missed some relatively recent development: is now GCC > >> installing its own stdint.h on *all* the supported targets, thus we can > >> s

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

Hi, On 11/10/2014 05:49 PM, Joel Sherrill wrote: On 11/10/2014 10:32 AM, Joseph Myers wrote: On Sat, 8 Nov 2014, Paolo Carlini wrote: Good. Sorry, if I missed some relatively recent development: is now GCC installing its own stdint.h on *all* the supported targets, thus we can safely No; I s

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On 11/10/2014 10:32 AM, Joseph Myers wrote: > On Sat, 8 Nov 2014, Paolo Carlini wrote: > >> Good. Sorry, if I missed some relatively recent development: is now GCC >> installing its own stdint.h on *all* the supported targets, thus we can >> safely > No; I sent a list of targets missing the infor

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On Sat, 8 Nov 2014, Paolo Carlini wrote: > Good. Sorry, if I missed some relatively recent development: is now GCC > installing its own stdint.h on *all* the supported targets, thus we can safely No; I sent a list of targets missing the information in

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

Hi, On 11/08/2014 04:33 PM, Jonathan Wakely wrote: On 8 November 2014 15:30, Joel Sherrill wrote: This didn't compile. Ended with an error about requiring C++11 in a header file. This code is in a c++98 subdirectory so it dues make sense. I can't cut and paste it at home. Yep, that makes sen

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On 8 November 2014 15:30, Joel Sherrill wrote: > This didn't compile. Ended with an error about requiring C++11 in a header > file. This code is in a c++98 subdirectory so it dues make sense. I can't cut > and paste it at home. Yep, that makes sense, I'd just stick with stdint.h

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On November 8, 2014 9:04:14 AM CST, Joel Sherrill wrote: > > >On November 8, 2014 9:00:02 AM CST, Jonathan Wakely > wrote: >>On 7 November 2014 16:56, Joel Sherrill wrote: >>> >>> On 11/7/2014 9:25 AM, Paolo Carlini wrote: Hi, On 11/07/2014 04:07 PM, Joel Sherrill wrote: > Hi

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On November 8, 2014 9:00:02 AM CST, Jonathan Wakely wrote: >On 7 November 2014 16:56, Joel Sherrill wrote: >> >> On 11/7/2014 9:25 AM, Paolo Carlini wrote: >>> Hi, >>> >>> On 11/07/2014 04:07 PM, Joel Sherrill wrote: Hi On m32c-rtems, we have a build error in C++ because size_t >

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On November 8, 2014 9:00:02 AM CST, Jonathan Wakely wrote: >On 7 November 2014 16:56, Joel Sherrill wrote: >> >> On 11/7/2014 9:25 AM, Paolo Carlini wrote: >>> Hi, >>> >>> On 11/07/2014 04:07 PM, Joel Sherrill wrote: Hi On m32c-rtems, we have a build error in C++ because size_t >

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On 7 November 2014 16:56, Joel Sherrill wrote: > > On 11/7/2014 9:25 AM, Paolo Carlini wrote: >> Hi, >> >> On 11/07/2014 04:07 PM, Joel Sherrill wrote: >>> Hi >>> >>> On m32c-rtems, we have a build error in C++ because size_t >>> is 16-bits and pointers are 24 bits. m32c-elf probably does not >>> e

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

On 11/7/2014 9:25 AM, Paolo Carlini wrote: > Hi, > > On 11/07/2014 04:07 PM, Joel Sherrill wrote: >> Hi >> >> On m32c-rtems, we have a build error in C++ because size_t >> is 16-bits and pointers are 24 bits. m32c-elf probably does not >> enable __GTHREAD support like rtems does. Since this is co

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

Hi, On 11/07/2014 04:07 PM, Joel Sherrill wrote: Hi On m32c-rtems, we have a build error in C++ because size_t is 16-bits and pointers are 24 bits. m32c-elf probably does not enable __GTHREAD support like rtems does. Since this is code shared across targets, what is the best way to fix this? I

Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

Attached is a patch which changes size_t to uintptr_t. It is enough to let the build continue. But I would appreciate feedback given the code. --joel On 11/7/2014 9:07 AM, Joel Sherrill wrote: > Hi > > On m32c-rtems, we have a build error in C++ because size_t > is 16-bits and pointers are 24 bits

mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)

Hi On m32c-rtems, we have a build error in C++ because size_t is 16-bits and pointers are 24 bits. m32c-elf probably does not enable __GTHREAD support like rtems does. Since this is code shared across targets, what is the best way to fix this? My first inclination would be to use uintptr_t for t

Re: printf format warning when sizeof(float) == sizeof(double)

On September 10, 2014 3:40:05 PM CDT, "Joseph S. Myers" wrote: >On Wed, 10 Sep 2014, Joel Sherrill wrote: > >> Hi >> >> We have a few RTEMS BSPs which use CPUs where float, double, >> and long double are the same. This triggers the printf format >> warning because promoting float to double re

Re: printf format warning when sizeof(float) == sizeof(double)

On Wed, 10 Sep 2014, Joel Sherrill wrote: > Hi > > We have a few RTEMS BSPs which use CPUs where float, double, > and long double are the same. This triggers the printf format > warning because promoting float to double results in float. That was PR c/35649, which should be fixed in 4.9. -- J

printf format warning when sizeof(float) == sizeof(double)

Hi We have a few RTEMS BSPs which use CPUs where float, double, and long double are the same. This triggers the printf format warning because promoting float to double results in float. At least that's what I think is happening. This happens on at least the h8sx and sh2e. $ h8300-rtems4.11-gcc -

Re: making sizeof(void*) different from sizeof(void(*)())

Michael Meissner wrote: > On Sat, Apr 28, 2012 at 02:32:18PM -0500, Peter Bigot wrote: >> The MSP430's split address space and ISA make it expensive to place >> data above the 64 kB boundary, but cheap to place code there. So I'm >> looking for a way to use HImode for data pointers, but PSImode fo

Re: making sizeof(void*) different from sizeof(void(*)())

On Sat, Apr 28, 2012 at 02:32:18PM -0500, Peter Bigot wrote: > The MSP430's split address space and ISA make it expensive to place > data above the 64 kB boundary, but cheap to place code there. So I'm > looking for a way to use HImode for data pointers, but PSImode for > function pointers. If gc

Re: making sizeof(void*) different from sizeof(void(*)())

On Wed, May 2, 2012 at 8:08 AM, Paulo J. Matos wrote: > On 30/04/12 13:01, Peter Bigot wrote: >> >> I would like to see the technical details, if your code is released >> somewhere. >> > > Hi Peter, > > Sorry for the delay. > The code is not released, however I can send you a patch against GCC 4.6

Re: making sizeof(void*) different from sizeof(void(*)())

On 30/04/12 13:01, Peter Bigot wrote: I would like to see the technical details, if your code is released somewhere. Hi Peter, Sorry for the delay. The code is not released, however I can send you a patch against GCC 4.6.3 sources (our GCC 4.7.0 port is not yet stable) of our changes and wi

Re: making sizeof(void*) different from sizeof(void(*)())

On Mon, Apr 30, 2012 at 4:50 AM, Robert Dewar wrote: > On 4/30/2012 4:16 AM, Paulo J. Matos wrote: >> >> Peter, >> >> We have a working backend for an Harvard Architecture chip where >> function pointer and data pointers have necessarily different sizes. We >> couldn't do this without changing GCC

Re: making sizeof(void*) different from sizeof(void(*)())

On 4/30/2012 4:16 AM, Paulo J. Matos wrote: Peter, We have a working backend for an Harvard Architecture chip where function pointer and data pointers have necessarily different sizes. We couldn't do this without changing GCC itself in strategic places and adding some extra support in our backen

Re: making sizeof(void*) different from sizeof(void(*)())

Peter, We have a working backend for an Harvard Architecture chip where function pointer and data pointers have necessarily different sizes. We couldn't do this without changing GCC itself in strategic places and adding some extra support in our backend. We haven't used address spaces or any

Re: making sizeof(void*) different from sizeof(void(*)())

Basile Starynkevitch writes: > `dlsym` is the obvious hint Most programs don't use dlsym. > also simply that most (probably nearly all) Linux/ELF systems and Unix > systems have same > size for data and function pointers. Those that don't use function descriptors. Andreas. -- Andreas Schwa

Re: making sizeof(void*) different from sizeof(void(*)())

On 4/29/2012 1:19 PM, Basile Starynkevitch wrote: For instance, I don't think that porting the Linux kernel (or the FreeBSD one) to such an architecture (having data pointers of different size that function pointers) is easy. Well it doesnt' surprise me too much that GNU/Linux has non-standa

Re: making sizeof(void*) different from sizeof(void(*)())

got a system where they have been different -with the important exception of some programming models for early PC/AT (and PC/286) systems of the MSDOS area (e.g. Borland Turbo C v1). IIRC correctly, CrayY/MP have various size for some data pointers so it had sizeof(char*) != sizeof (double*) but

Re: making sizeof(void*) different from sizeof(void(*)())

On 4/29/2012 12:47 PM, Basile Starynkevitch wrote: My biased point of view is that designing a processor instruction set (for POSIX-like systems or standard C software in mind) with function pointers of different size than data pointers is today a mistake: most software make the implicit assum

Re: making sizeof(void*) different from sizeof(void(*)())

On Sun, 29 Apr 2012 09:43:02 -0400 Robert Dewar wrote: > On 4/29/2012 9:25 AM, Andreas Schwab wrote: > > Robert Dewar writes: > > > >> Just to be clear, there is nothing in the standard that forbids the > >> sizes being different AFAIK? I understand that both gcc and apps > >> may make unwarrant

Re: making sizeof(void*) different from sizeof(void(*)())

Peter Bigot a écrit: Georg-Johann Lay wrote: Peter Bigot a écrit: The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. I

Re: making sizeof(void*) different from sizeof(void(*)())

On 4/29/2012 9:25 AM, Andreas Schwab wrote: Robert Dewar writes: Just to be clear, there is nothing in the standard that forbids the sizes being different AFAIK? I understand that both gcc and apps may make unwarranted assumptions. POSIX makes that assumption, via the dlsym interface. that

Re: making sizeof(void*) different from sizeof(void(*)())

Robert Dewar writes: > Just to be clear, there is nothing in the standard that forbids the > sizes being different AFAIK? I understand that both gcc and apps > may make unwarranted assumptions. POSIX makes that assumption, via the dlsym interface. Andreas. -- Andreas Schwab, sch...@linux-m68k

Re: making sizeof(void*) different from sizeof(void(*)())

On Sun, Apr 29, 2012 at 7:51 AM, Georg-Johann Lay wrote: > Peter Bigot a écrit: > >> The MSP430's split address space and ISA make it expensive to place >> data above the 64 kB boundary, but cheap to place code there.  So I'm >> looking for a way to use HImode for data pointers, but PSImode for >>

Re: making sizeof(void*) different from sizeof(void(*)())

On 4/29/2012 8:51 AM, Georg-Johann Lay wrote: Peter Bigot a écrit: The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. If

Re: making sizeof(void*) different from sizeof(void(*)())

Peter Bigot a écrit: The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. If gcc supports this, it's not obvious how. I get

making sizeof(void*) different from sizeof(void(*)())

The MSP430's split address space and ISA make it expensive to place data above the 64 kB boundary, but cheap to place code there. So I'm looking for a way to use HImode for data pointers, but PSImode for function pointers. If gcc supports this, it's not obvious how. I get partway there with FUNC

Re: sizeof((..))

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."

Re: sizeof((..))

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

Re: sizeof((..))

(sizeof ($1)) return 0;])], [AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT([$4])], [if (sizeof (($1))) return 0;])], [], [AS_VAR_SET([ac_Type], [yes])])])]) AS_VAR_IF([ac_Type], [yes], [$2], [$3])[]dnl AS_VAR_POPDEF([ac_Type])dnl ])# _AC_CHECK_TYPE_NEW

Re: sizeof((..))

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&#

Re: sizeof((..))

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

Re: sizeof((..))

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

Re: sizeof((..))

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 &g

sizeof((..))

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: expected expression before ‘)’ token # gcc --version gcc (GCC) 4.5.1

Re: Usage of sizeof in testsuite/g++.dg/cpp0x/rv[1..8]p.C

Uros Bizjak writes: > A problem arises with the code in testsuite/g++.dg/cpp0x/rv[1..8]p.C. > These tests use "sizeof(..character array...) == ", but sizeof char > array depends heavily on the value of #define STRUCTURE_SIZE_BOUNDARY. > Targets that define this value to i.

Usage of sizeof in testsuite/g++.dg/cpp0x/rv[1..8]p.C

Hello! A problem arises with the code in testsuite/g++.dg/cpp0x/rv[1..8]p.C. These tests use "sizeof(..character array...) == ", but sizeof char array depends heavily on the value of #define STRUCTURE_SIZE_BOUNDARY. Targets that define this value to i.e. 32 (for performance reasons,

Re: sizeof in initializer expression not working as expected

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

sizeof in initializer expression not working as expected

ltiply the size of the pointer by 4. The result should be 64. Below is a fragment of a GDB session: 79 size_t sz = sizeof (evt_t) + (4 * sizeof (tpd_uptr)); (gdb) n 85 if (sv_name == NULL) sv_name = (char *)null_z; (gdb) p sizeof(evt_t) $15 = 48 (gdb) p (4 * sizeof (tpd_upt

Re: sizeof(array) with variable-length array parameter

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 > &

Re: sizeof(array) with variable-length array parameter

[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

sizeof(array) with variable-length array parameter

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 (in C99): #include void foo(

Re: Where can I find "sizeof" implementation in front end

[EMAIL PROTECTED] wrote: > Hello all: > > I am reading codes of gcc front end. But I can not find the implementation > of "sizeof". How does gcc front end calculate size of UNION and STRUCT? > Where is the codes for these work. Can anybody give me some advices? Thank >

RE: Where can I find "sizeof" implementation in front end

On 19 June 2007 16:35, bjzheng wrote: > Hello all: > > I am reading codes of gcc front end. But I can not find the implementation > of "sizeof". How does gcc front end calculate size of UNION and STRUCT? > Where is the codes for these work. Can anybody give me some adv

Where can I find "sizeof" implementation in front end

Hello all: I am reading codes of gcc front end. But I can not find the implementation of "sizeof". How does gcc front end calculate size of UNION and STRUCT? Where is the codes for these work. Can anybody give me some advices? Thank you so much !

Re: sizeof struct { short x } on arm gcc-3.2.1

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

  1   2   >