Re: aliasing

e standard accordingly. Yes, where possible and practical, the standard provide the guarantees that programmers need. Failing that, compiler extensions are good too - I'd be very happy with a GCC variable __attribute__ "backing_store" that could be applied to allocator backing stores and provide the aliasing guarantees needed. (It might even be needed anyway, to work well with the "malloc" attribute, even with your change to the standard.) David

Re: aliasing

On 18/03/2024 17:46, David Brown via Gcc wrote: On 18/03/2024 14:54, Andreas Schwab via Gcc wrote: On Mär 18 2024, David Brown wrote: I think it would be possible to have an implementation where "signed char" was 8-bit two's complement except that 0x80 would be a trap representation rather tha

Re: aliasing

On 18/03/2024 14:54, Andreas Schwab via Gcc wrote: On Mär 18 2024, David Brown wrote: I think it would be possible to have an implementation where "signed char" was 8-bit two's complement except that 0x80 would be a trap representation rather than -128. signed char cannot have padding bits, t

Re: aliasing

Am Montag, dem 18.03.2024 um 14:21 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 12:56 PM Martin Uecker wrote: > > > > Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > > > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > > > On Mon, Mar 18, 2024 at 8

Re: aliasing

lowed). Yes, but with C23 this is not possible anymore. I think signed char or char should work equally well now. > > > > > > > Should it also include "uint8_t" (if it exists) ? "uint8_t" is often an > > > alias for "unsigned char", but

Re: aliasing

On Mär 18 2024, David Brown wrote: > I think it would be possible to have an implementation where "signed > char" was 8-bit two's complement except that 0x80 would be a trap > representation rather than -128. signed char cannot have padding bits, thus it cannot have a trap representation. -- An

Re: aliasing

alias for "unsigned char", but it could be something different, like an alias for __UINT8_TYPE__, or "unsigned int __attribute__((mode(QImode)))", which is used in the AVR gcc port. I think this might be a reason to not include it, as it could affect aliasing analysis. At lea

Re: aliasing

On Mon, Mar 18, 2024 at 12:56 PM Martin Uecker wrote: > > Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > > > > > > Let me give you an compli

Re: aliasing

Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > > Let me give you an complication example made valid in C++: > > > > struct B { float x; float

Re: aliasing

(if it exists) ? "uint8_t" is often an > alias for "unsigned char", but it could be something different, like an > alias for __UINT8_TYPE__, or "unsigned int > __attribute__((mode(QImode)))", which is used in the AVR gcc port. I think this might be a reaso

Re: aliasing

Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > Hi, > > > > can you please take a quick look at this? This is intended to align > > the C standard with existing practice w

Re: aliasing

On Mon, 18 Mar 2024 at 09:01, David Brown wrote: > Should it also include "uint8_t" (if it exists) ? "uint8_t" is often an > alias for "unsigned char", but it could be something different, like an > alias for __UINT8_TYPE__, or "unsigned int > __attribute__((mode(QImode)))", which is used in the A

Re: aliasing

which could be ideally be standardised in the C standards or at least added as gcc extensions, but I think that's more than you are looking for here! David On 18/03/2024 08:03, Martin Uecker via Gcc wrote: Hi, can you please take a quick look at this? This is intended to align the

Re: aliasing

On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > Hi, > > can you please take a quick look at this? This is intended to align > the C standard with existing practice with respect to aliasing by > removing the special rules for "objects with no declared t

aliasing

Hi, can you please take a quick look at this? This is intended to align the C standard with existing practice with respect to aliasing by removing the special rules for "objects with no declared type" and making it fully symmetric and only based on types with non-atomic character t

Re: [PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

On Fri, Apr 21, 2023 at 10:27:18PM +0200, Alejandro Colomar wrote: > Link: > Reported-by: Bastien Roucariès > Reported-by: Alejandro Colomar > Reviewed-by: Eric Blake > Cc: glibc > Cc: GCC > Cc: Stefan Puiu > Cc: Igor Sysoev > Cc: Rich Felker >

[PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

b/man3type/sockaddr.3type @@ -117,6 +117,14 @@ .SH HISTORY was invented by POSIX. See also .BR accept (2). +.PP +These structures were invented before modern ISO C strict-aliasing rules. +If aliasing rules are applied strictly, +these structures would be extremely difficult to use +without invoking

Re: [RFC] restricting aliasing by standard containers (PR 98465)

., PR 93971) where a standard container (std::string in > >> this case but the problem applies to any class that owns and manages > >> allocated memory) might trigger warnings for unreachable code. > >> The code is not eliminated due to a missing aliasing constraint: > >

Re: [RFC] restricting aliasing by standard containers (PR 98465)

s and manages allocated memory) might trigger warnings for unreachable code. The code is not eliminated due to a missing aliasing constraint: because GCC doesn't know that the member pointer to the memory managed by the container cannot alias other objects, it emits code that can never be executed

Re: [RFC] restricting aliasing by standard containers (PR 98465)

emory) might trigger warnings for unreachable code. > The code is not eliminated due to a missing aliasing constraint: > because GCC doesn't know that the member pointer to the memory > managed by the container cannot alias other objects, it emits code > that can never be executed i

[RFC] restricting aliasing by standard containers (PR 98465)

d due to a missing aliasing constraint: because GCC doesn't know that the member pointer to the memory managed by the container cannot alias other objects, it emits code that can never be executed in a valid program and that's prone to causing false positives. To illustrate, at

Re: Aliasing rules for unannotated SYMBOL_REFs

overlap, >> we win. */ >> if (!cmp || !offset_overlap_p (c, xsize, ysize)) >> return 0; >> >> So we seem to be taking cmp==-1 to mean that although we don't know >> the relationship between the symbols, it must be the case that either >

Re: Aliasing rules for unannotated SYMBOL_REFs

decls are different or we know by offsets that there is no > overlap, >we win. */ > if (!cmp || !offset_overlap_p (c, xsize, ysize)) > return 0; > > So we seem to be taking cmp==-1 to mean that although we don't know > the relationship between the symbols, it

Aliasing rules for unannotated SYMBOL_REFs

king cmp==-1 to mean that although we don't know the relationship between the symbols, it must be the case that either (a) the symbols are equal (e.g. via aliasing) or (b) the accesses are to non-overlapping objects. In other words, one of the situations described by cmp==1 or cmp==0 must b

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

On Fri, Aug 10, 2018 at 6:08 PM, Sam McCall wrote: > json::Value in JSON.h is a discriminated union. > The storage is a char array of appropriate type and alignment. The storage > holds one object at a time, it's initialized (and for nontrivial types, > destroyed) at the right times to ensure this

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

> `std::byte` (in C++) can alias objects. > > Yes. > > > That is to say, in order to eliminate the aliasing problem an > > intermediate lvalue pointer is required. > > Not exactly. You can cast a pointer to a pointer to some character > type or the type of the

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

On 08/10/2018 05:30 AM, Liu Hao wrote: > Only an lvalue of a pointer to (possibly CV-qualified) `void` or a > pointer to a character type (in C) / any of `char`, `unsigned char` or > `std::byte` (in C++) can alias objects. Yes. > That is to say, in order to eliminate the aliasin

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

在 2018-08-10 18:53, Kim Gräsman 写道: I'm worried that this might only serve to trick the compiler. It shouldn't. If it was merely a trick then `std::aligned_storage` would be completely unusable. Explicitly using `-fno-strict-aliasing` for GCC < 6 would seem more direc

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

, the solution is simple: > > Only an lvalue of a pointer to (possibly CV-qualified) `void` or a pointer > to a character type (in C) / any of `char`, `unsigned char` or `std::byte` > (in C++) can alias objects. > > That is to say, in order to eliminate the aliasing problem an interm

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

在 2018-08-10 06:20, Kim Gräsman 写道: On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely wrote: If GCC 4.9.3 thinks there's an aliasing violation it might misoptimise. It doesn't matter if it's right or not, it matters if it treats the code as undefined or not. And apparently

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely wrote: > > If GCC 4.9.3 thinks there's an aliasing violation it might > misoptimise. It doesn't matter if it's right or not, it matters if it > treats the code as undefined or not. > > And apparently GCC does thin

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

ng is a false positive (anyone disagree?) > > The little I've read about strict aliasing rules leaves me firmly > incompetent to judge what's valid and not :) > > But since both Clang and GCC 6+ are happy with this, it seems > plausible that this would be a false positive.

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

Thanks all for pitching in to help! On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote: > > Obviously if there really is something illegal here we should fix it in > LLVM, but it looks like this warning is a false positive (anyone disagree?) The little I've read about strict aliasin

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

: new (reinterpret_cast(Union.buffer)) T(std::forward(V)...); } template T &as() const { +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstrict-aliasing" return *reinterpret_cast(Union.buffer); +#pragma GCC diagnostic pop } template 在 2018年08月09日 19:25

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

Author of the problematic code here. Thanks everyone, and sorry to have caused difficulty! Obviously if there really is something illegal here we should fix it in LLVM, but it looks like this warning is a false positive (anyone disagree?) Still if there's a simple source-level workaround, or we c

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

On Thu, 9 Aug 2018 at 12:04, Leslie Zhai wrote: > > Hi Jonathan, > > Thanks for your response! > > So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5 > to build old clang, then bootstrap latest LLVM with old clang. It would be much easier to jus

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

Hi Jonathan, Thanks for your response! So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5 to build old clang, then bootstrap latest LLVM with old clang. 在 2018年08月09日 17:16, Jonathan Wakely 写道: On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote: Could you test to compile

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote: > Could you test to compile LLVM with GCC old versions 4/5/6? Does it need > to backport your patch to GCC old version? GCC versions before 6.4 are not supported, so no backports will happen to 4.x or 5 releases and I doubt anybody's going to routine

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

/Support/JSON.h: In instantiation of ‘T& llvm::json::Value::as() const [with T = bool]’: /home/loongson/llvm/include/llvm/Support/JSON.h:393:23: required from here /home/loongson/llvm/include/llvm/Support/JSON.h:455:47: warning: dereferencing type-punned pointer will break strict-aliasing r

Re: aliasing between internal zero-length-arrays and other members

On Tue, Jun 05, 2018 at 01:38:21PM +0200, Richard Biener wrote: > On Tue, Jun 5, 2018 at 1:39 AM Martin Sebor wrote: > > > > GCC silently (without -Wpedantic) accepts declarations of zero > > length arrays that are followed by other members in the same > > struct, such as in: > > > >struct A {

Re: aliasing between internal zero-length-arrays and other members

On Tue, Jun 5, 2018 at 1:39 AM Martin Sebor wrote: > > GCC silently (without -Wpedantic) accepts declarations of zero > length arrays that are followed by other members in the same > struct, such as in: > >struct A { char a, b[0], c; }; > > Is it intended that accesses to elements of such arra

aliasing between internal zero-length-arrays and other members

GCC silently (without -Wpedantic) accepts declarations of zero length arrays that are followed by other members in the same struct, such as in: struct A { char a, b[0], c; }; Is it intended that accesses to elements of such arrays that alias other members be well-defined? In my tests, GCC ass

Re: [std-discussion] Is this union aliasing code well-defined?

In math, once you reach a contradiction, you realize that one of your premises was false. In religion, once you reach a contradiction, you write books of theology to paper over the mess. I guess we know what category type-based alias analysis falls under.

Re: [std-discussion] Is this union aliasing code well-defined?

gt;> p3->v2.x = temp; >> write_s2x(&p2->v2,1234); >> temp = p3->v2.x; >> p3->v1.x = temp; >> } >> return read_s1x(&p1->v1); >> } >> int test2(int x) >> { >> union s1s2 q[2]; >> q->v1.x

Re: [std-discussion] Is this union aliasing code well-defined?

>>>> if (read_s1x(&p1->v1)) >>>> { >>>> unsigned short temp; >>>> temp = p3->v1.x; >>>> p3->v2.x = temp; >>>> write_s2x(&p2->v2,1234); >>>> temp = p3->v2.x; >>>>

Re: [std-discussion] Is this union aliasing code well-defined?

>> write_s2x(&p2->v2,1234); >>> temp = p3->v2.x; >>> p3->v1.x = temp; >>> } >>> return read_s1x(&p1->v1); >>> } >>> int test2(int x) >>> { >>> union s1s2 q[2]; >>> q->v1.x

Re: [std-discussion] Is this union aliasing code well-defined?

>> } >> int test2(int x) >> { >> union s1s2 q[2]; >> q->v1.x = 4321; >> return test(q,q+x,q+x); >> } >> #include >> int main(void) >> { >> printf("%d\n",test2(0)); >> } >> >> >> Both GCC

Re: [std-discussion] Is this union aliasing code well-defined?

gt; temp = p3->v2.x; > p3->v1.x = temp; > } > return read_s1x(&p1->v1); > } > int test2(int x) > { > union s1s2 q[2]; > q->v1.x = 4321; > return test(q,q+x,q+x); > } > #include > int main(void) > { > printf("%d\n",test2(0));

Re: GCC aliasing extension for C

On September 18, 2017 4:12:07 PM GMT+02:00, Andrew Haley wrote: >On 18/09/17 10:48, Florian Weimer wrote: >> Is this a property of the char type, or would other types work as >well, >> for example, double or long double? > >It has to be a character type, I believe. It can be any type. All store

Re: GCC aliasing extension for C

On 18/09/17 10:48, Florian Weimer wrote: > Is this a property of the char type, or would other types work as well, > for example, double or long double? It has to be a character type, I believe. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF

GCC aliasing extension for C

I know that GCC implements a C extension (which is more or less required by POSIX) which allows you to define a buffer char buf[1024]; and then allocate objects from that (assuming that the buffer is sufficiently large and the pointers to subobjects are suitably aligned). In short, it is p

Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

On Tue, 2017-05-02 at 12:17 +0200, Richard Biener wrote: > But this shows > an issue with GCC 7 so please open a bugreport. Here it is - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 Regards, FCh

Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

> first RC), it started to produce a warning about aliasing. The code > basically boils down to this: > > -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- > > #include > > std::aligned_storage::type storage; > > int main()

GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

Hello! A code that I wrote was warning-free in GCC 4.9, GCC 5 and GCC 6. It was also warning-free with some older GCC 7 experimental snapshots (for example 7-20170409). But in the most recent snapshot (including the first RC), it started to produce a warning about aliasing. The code basically

Re: Aliasing of arrays

y object of known size really constitutes an object in that sense. > > This is one of the ambiguous cases about which objects are relevant for > type-based aliasing rules. I think it's best not to optimize this (that > is, to treat the objects as being the individual array elements, so th

Re: Aliasing of arrays

the ambiguous cases about which objects are relevant for type-based aliasing rules. I think it's best not to optimize this (that is, to treat the objects as being the individual array elements, so the arrays can overlap by an exact multiple of the element size - meaning the ultimate eleme

Re: Aliasing of arrays

UNUSED, tree base1, ... /* If both references are through the same type, they do not alias if the accesses do not overlap. This does extra disambiguation for mixed/pointer accesses but requires strict aliasing. */ if ((TREE_CODE (base1) != TARGET_MEM_REF || (!TMR

Aliasing of arrays

Hi! Pascal Cuoq communicated to me the following example: int ar1(int (*p)[3], int (*q)[3]) { (*p)[0] = 1; (*q)[1] = 2; return (*p)[0]; } gcc of versions 4.9.2 and 7.0.0 20161129 optimize it with -O2 on the premise that elements with different indices don't alias: :

Re: C++17 std::launder and aliasing

On Tue, Oct 18, 2016 at 1:06 PM, Jakub Jelinek wrote: > Hi! > > http://wg21.link/p0137 > adds std::launder which is supposed to be some kind of aliasing optimization > barrier. > > What is unclear to me is if we really need compiler support for that. > I have unfortunately

C++17 std::launder and aliasing

Hi! http://wg21.link/p0137 adds std::launder which is supposed to be some kind of aliasing optimization barrier. What is unclear to me is if we really need compiler support for that. I have unfortunately not found many examples: http://stackoverflow.com/questions/39382501/what-is-the-purpose-of

Re: Handling aliasing memory accesses in gimple/ssa

On 10/05/16 14:46, Richard Biener wrote: On Tue, May 10, 2016 at 3:41 PM, Kyrill Tkachov wrote: Hi all, I'm taking a stab at fixing PR 22141 by merging adjacent stores into wider stores in a late gimple pass. My current plan is to go through all the assignments in a basic block and keep trac

Re: Handling aliasing memory accesses in gimple/ssa

On Tue, May 10, 2016 at 3:41 PM, Kyrill Tkachov wrote: > Hi all, > > I'm taking a stab at fixing PR 22141 by merging adjacent stores into wider > stores in a late gimple pass. > > My current plan is to go through all the assignments in a basic block and > keep track of > LHS expressions that are C

Handling aliasing memory accesses in gimple/ssa

Hi all, I'm taking a stab at fixing PR 22141 by merging adjacent stores into wider stores in a late gimple pass. My current plan is to go through all the assignments in a basic block and keep track of LHS expressions that are COMPONENT_REF, BIT_FIELD_REF, ARRAY_REF or ARRAY_RANGE_REF until we

Re: Some aliasing questions

On April 12, 2016 5:11:45 PM GMT+02:00, Richard Henderson wrote: >On 04/11/2016 05:30 PM, Alan Modra wrote: >> Either way, when we split to >> set (reg tmp) (high (const (minus ((symbol_ref) (reg 2) >> .. mem (lo_sum (reg tmp) (const (minus ((symbol_ref) (reg 2) >> both high and

Re: Some aliasing questions

On 04/11/2016 05:30 PM, Alan Modra wrote: Either way, when we split to set (reg tmp) (high (const (minus ((symbol_ref) (reg 2) .. mem (lo_sum (reg tmp) (const (minus ((symbol_ref) (reg 2) both high and lo_sum reference r2 and the linker could happily replace rtmp in the lo

Re: Some aliasing questions

reg 2) > both high and lo_sum reference r2 and the linker could happily replace > rtmp in the lo_sum insn with r2 when the high address is known to be > zero. Yes, this sounds promising. And it really helps to know the history here -- you saved me a lot of digging through the archive

Re: Some aliasing questions

On Fri, Apr 08, 2016 at 01:41:05PM -0700, Richard Henderson wrote: > On 04/08/2016 11:10 AM, Bill Schmidt wrote: > > The first is an issue with TOC-relative addresses on PowerPC. These are > > symbolic addresses that are to be loaded from a fixed slot in the table > > of contents, as addressed by

Re: Some aliasing questions

On Fri, 2016-04-08 at 13:41 -0700, Richard Henderson wrote: > On 04/08/2016 11:10 AM, Bill Schmidt wrote: > > The first is an issue with TOC-relative addresses on PowerPC. These are > > symbolic addresses that are to be loaded from a fixed slot in the table > > of contents, as addressed by the TOC

Re: Some aliasing questions

On 04/08/2016 11:10 AM, Bill Schmidt wrote: > The first is an issue with TOC-relative addresses on PowerPC. These are > symbolic addresses that are to be loaded from a fixed slot in the table > of contents, as addressed by the TOC pointer (r2). In the RTL phases > prior to register allocation, th

Re: Some aliasing questions

On April 8, 2016 8:10:16 PM GMT+02:00, Bill Schmidt wrote: >Hi, > >I ran into a couple of aliasing issues with a project I'm working on, >and have some questions. > >The first is an issue with TOC-relative addresses on PowerPC. These >are >symbolic addresses that

Some aliasing questions

Hi, I ran into a couple of aliasing issues with a project I'm working on, and have some questions. The first is an issue with TOC-relative addresses on PowerPC. These are symbolic addresses that are to be loaded from a fixed slot in the table of contents, as addressed by the TOC pointe

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

On Sun, Oct 12, 2014 at 7:44 PM, Uros Bizjak wrote: >>> Right. And my question is what happens if we aren't as aggressive here. >>> What happens if before this check we return nonzero if X or Y is a VALUE? >>> Do we then get into memrefs_conflict_p and does it do the right thing? >> >> Following

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

On Fri, Oct 10, 2014 at 8:37 PM, Uros Bizjak wrote: >> Right. And my question is what happens if we aren't as aggressive here. >> What happens if before this check we return nonzero if X or Y is a VALUE? >> Do we then get into memrefs_conflict_p and does it do the right thing? > > Following patc

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

On Fri, Oct 10, 2014 at 8:18 PM, Jeff Law wrote: >>>> I'd like to bring PR 63475 to the attention of RTL maintainers. The >>>> problem in the referred PR exposed the RTL infrastructure problem, >>>> where VALUE expressions are leaked instead of MEM expre

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

sions are leaked instead of MEM expresions into various parts of aliasing-detecting support functions. As an example, please consider following patch for base_alias_check: --cut here-- Index: alias.c === --- alias.c (revision 2

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

here VALUE expressions are leaked instead of MEM expresions into >> various parts of aliasing-detecting support functions. >> >> As an example, please consider following patch for base_alias_check: >> >> --cut here-- >> Index: alias.c >> =

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

On 10/09/14 06:14, Uros Bizjak wrote: Hello! I'd like to bring PR 63475 to the attention of RTL maintainers. The problem in the referred PR exposed the RTL infrastructure problem, where VALUE expressions are leaked instead of MEM expresions into various parts of aliasing-detecting su

RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

Hello! I'd like to bring PR 63475 to the attention of RTL maintainers. The problem in the referred PR exposed the RTL infrastructure problem, where VALUE expressions are leaked instead of MEM expresions into various parts of aliasing-detecting support functions. As an example, please con

Re: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)

t guarantees alignment of certain variables as long > as the structure itself is aligned properly? How can I do so with 4.6+ > GCC with full optimizations enabled with strict aliasing enabled (e.g. > without passing -fno-strict-aliasing). > > Pseudo code: > > struct my_array > {

Re: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)‏

alignment of certain variables as long > as the structure itself is aligned properly? How can I do so with 4.6+ > GCC with full optimizations enabled with strict aliasing enabled (e.g. > without passing -fno-strict-aliasing). > > Pseudo code: > > struct my_array > { >c

Re: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)

t guarantees alignment of certain variables as long > as the structure itself is aligned properly? How can I do so with 4.6+ > GCC with full optimizations enabled with strict aliasing enabled (e.g. > without passing -fno-strict-aliasing). > > Pseudo code: > > struct my_array > {

RE: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)‏

s long > as the structure itself is aligned properly? How can I do so with 4.6+ > GCC with full optimizations enabled with strict aliasing enabled (e.g. > without passing -fno-strict-aliasing). > > Pseudo code: > > struct my_array > { >char data[]; > }; > > vo

Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)‏

itself is aligned properly? How can I do so with 4.6+ GCC with full optimizations enabled with strict aliasing enabled (e.g. without passing -fno-strict-aliasing). Pseudo code: struct my_array {    char data[]; }; void * buffer = alloca(sizeof(my_array) + 32); void * buffer32 = (((uintptr_t

Re: strict aliasing: cast from char[] or char *

which I'd like to disable.  How can I do that?  Currently I'm >>>> using >>>> -Wno-strict-aliasing, but I'd like to have a better solution.  I tried to >>>> cast (void*) before the cast to (OBJECT*), it didn't help.  Is it possible &g

Re: strict aliasing: cast from char[] or char *

On Tue, Jun 7, 2011 at 4:31 PM, Jonathan Wakely wrote: > On 7 June 2011 15:20, Richard Guenther wrote: >>> >>> However, for my construct, which appears to be completely legal, I get a >>> warning, which I'd like to disable.  How can I do that?  Currently I&#x

Re: strict aliasing: cast from char[] or char *

On 7 June 2011 15:20, Richard Guenther wrote: >> >> However, for my construct, which appears to be completely legal, I get a >> warning, which I'd like to disable.  How can I do that?  Currently I'm using >> -Wno-strict-aliasing, but I'd like to have a bet

Re: strict aliasing: cast from char[] or char *

7, 2011 at 5:51 AM, Herman, Geza    wrote: >>>>> >>>>> Hi, >>>>> >>>>> Sorry, if it has been discussed before, I found a lot of information on >>>>> strict aliasing in gcc, but nothing about this particular case.  I&#x

Re: strict aliasing: cast from char[] or char *

On 7 June 2011 15:05, Herman, Geza wrote: > > However, for my construct, which appears to be completely legal, I get a > warning, which I'd like to disable.  How can I do that?  Currently I'm using > -Wno-strict-aliasing, but I'd like to have a better solution.  I tri

Re: strict aliasing: cast from char[] or char *

aliasing in gcc, but nothing about this particular case. I'd like to code a custom container class: it has a char[] (or dynamically allocated "char *") for storage, putting an element is done with placement new, getting an element is done with reinterpret_cast'ing the storage,

Re: strict aliasing: cast from char[] or char *

On 06/07/2011 12:27 PM, Richard Guenther wrote: On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote: Hi, Sorry, if it has been discussed before, I found a lot of information on strict aliasing in gcc, but nothing about this particular case. I'd like to code a custom container class: it

Re: strict aliasing: cast from char[] or char *

On Tue, Jun 7, 2011 at 2:58 PM, Herman, Geza wrote: > On 06/07/2011 12:27 PM, Richard Guenther wrote: >> >> On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza  wrote: >>> >>> Hi, >>> >>> Sorry, if it has been discussed before, I found a lot of inf

Re: strict aliasing: cast from char[] or char *

On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote: > Hi, > > Sorry, if it has been discussed before, I found a lot of information on > strict aliasing in gcc, but nothing about this particular case.  I'd like to > code a custom container class: it has a char[] (or dynamical

Re: strict aliasing: cast from char[] or char *

Please send questions about using GCC to gcc-h...@gcc.gnu.org, this mailing list is for discussing development of GCC, thanks. On 7 June 2011 04:51, Herman, Geza wrote: > > Here, gcc warns on the reinterpret_cast line. Which version?

strict aliasing: cast from char[] or char *

Hi, Sorry, if it has been discussed before, I found a lot of information on strict aliasing in gcc, but nothing about this particular case. I'd like to code a custom container class: it has a char[] (or dynamically allocated "char *") for storage, putting an element is done

Re: Why is -fstrict-aliasing excluded from function "optimize" attribute?

On 11/04/2010 11:28 AM, Bingfeng Mei wrote: I think of adding a warning too. Should I submit a patch? That's always a good idea. :) Paolo

RE: Why is -fstrict-aliasing excluded from function "optimize" attribute?

: Re: Why is -fstrict-aliasing excluded from function "optimize" > attribute? > > On 11/03/2010 08:44 PM, Richard Guenther wrote: > > On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote: > >> On 11/03/2010 04:49 PM, Bingfeng Mei wrote: > >>> Hello, > &

Re: Why is -fstrict-aliasing excluded from function "optimize" attribute?

On 11/03/2010 08:44 PM, Richard Guenther wrote: > On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote: >> On 11/03/2010 04:49 PM, Bingfeng Mei wrote: >>> Hello, >>> I came across an issue with function "optimize" attribute. The code is like: >>>

Re: Why is -fstrict-aliasing excluded from function "optimize" attribute?

On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote: > On 11/03/2010 04:49 PM, Bingfeng Mei wrote: >> Hello, >> I came across an issue with function "optimize" attribute. The code is like: >> __attribute__((optimize("-fno-strict-aliasing"))) >> void

Re: Why is -fstrict-aliasing excluded from function "optimize" attribute?

On 11/03/2010 04:49 PM, Bingfeng Mei wrote: > Hello, > I came across an issue with function "optimize" attribute. The code is like: > __attribute__((optimize("-fno-strict-aliasing"))) > void foo() > { >... > } > > When compiling with -O2, we exp

Why is -fstrict-aliasing excluded from function "optimize" attribute?

Hello, I came across an issue with function "optimize" attribute. The code is like: __attribute__((optimize("-fno-strict-aliasing"))) void foo() { ... } When compiling with -O2, we expect this function is compiled without following strict aliasing rule, whereas other c

  1   2   3   4   5   6   >