Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127213 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2018-03-01 16:38 -0800 |
| Last post | 2018-03-26 23:04 -0700 |
| Articles | 20 on this page of 150 — 11 participants |
Back to article view | Back to comp.lang.c
lvalue types supercat@casperkitty.com - 2018-03-01 16:38 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 17:17 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-01 17:37 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 22:00 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 23:49 -0800
Re: lvalue types asetofsymbols@gmail.com - 2018-03-05 06:56 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 00:22 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 01:23 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 05:04 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 06:06 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 08:12 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 09:50 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 11:33 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 11:45 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 16:28 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 16:54 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 17:50 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 19:43 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-02 22:51 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 23:07 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 01:44 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-03 13:01 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 22:21 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 09:24 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 00:58 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 01:13 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-03 13:01 -0800
Re: lvalue types supercat <flatfinger@casperkitty.com> - 2018-03-03 17:43 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-04 02:22 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-04 13:03 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-04 13:03 -0800
Re: lvalue types bartc <bc@freeuk.com> - 2018-03-04 22:32 +0000
Re: lvalue types supercat@casperkitty.com - 2018-03-05 09:45 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-19 09:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-19 11:52 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 23:44 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-27 09:14 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-27 12:21 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 17:01 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-29 01:54 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-30 08:32 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-30 09:25 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-03-30 10:58 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-31 00:52 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-02 15:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-03 10:06 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-03 11:33 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-03 12:19 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-03 12:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-05 10:17 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-05 10:52 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-05 12:39 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 06:13 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 16:38 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-27 12:09 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 10:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-19 12:27 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-03 14:02 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 17:32 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-04 20:24 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 08:31 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-11 11:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-11 12:44 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-12 06:45 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-12 07:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-12 14:26 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-12 14:43 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-12 17:40 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 03:02 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 00:27 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-13 07:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 08:52 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-16 10:28 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 13:58 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-16 14:52 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 16:22 -0700
Re: lvalue types Richard Damon <Richard@Damon-Family.org> - 2018-04-16 21:51 -0400
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-16 19:42 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:30 -0700
Re: lvalue types Richard Damon <Richard@Damon-Family.org> - 2018-04-17 07:01 -0400
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 04:22 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-19 02:43 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 07:25 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 08:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 09:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 10:37 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 11:00 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 11:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 12:45 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 19:55 +0000
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 13:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 14:00 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 19:45 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 08:27 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 09:12 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 10:13 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 11:01 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 11:51 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 12:15 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 12:30 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 13:25 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 10:51 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 12:38 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 14:39 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 21:17 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-19 02:40 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-19 03:01 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 06:49 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-19 07:58 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-20 08:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 12:17 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 12:51 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 13:37 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-19 21:08 +0000
Re: lvalue types supercat@casperkitty.com - 2018-04-19 14:50 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 14:56 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 16:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-21 10:27 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:37 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 16:07 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 09:20 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 11:25 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 14:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 15:05 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 19:57 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 08:43 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 09:36 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 11:37 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 20:23 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 09:23 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-18 17:29 +0000
Re: lvalue types supercat@casperkitty.com - 2018-04-18 10:47 -0700
Re: lvalue types bartc <bc@freeuk.com> - 2018-04-18 20:04 +0100
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 10:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 13:23 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 14:26 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 15:36 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 10:39 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 12:42 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:29 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:39 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 02:53 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-04 21:30 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-03 14:19 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 18:03 -0800
Re: lvalue types John Bode <jfbode1029@gmail.com> - 2018-03-21 10:33 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-21 11:53 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 00:11 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-21 11:53 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 23:04 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-18 13:25 -0700 |
| Message-ID | <2ff60b1a-f388-4521-adc8-5724be16abde@googlegroups.com> |
| In reply to | #129426 |
On Wednesday, April 18, 2018 at 2:30:36 PM UTC-5, james...@verizon.net wrote:
> On Wednesday, April 18, 2018 at 3:15:35 PM UTC-4, supe...@casperkitty.com wrote:
> > On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
> > > On Wednesday, April 18, 2018 at 1:13:36 PM UTC-4, supe...@casperkitty.com wrote:
> ...
> > > > I've posted code many times where both gcc and clang create such a
> > > > distinction.
> > >
> > > Could you provide Google Groups message links to identify previous
> > > occasions when you discussed such code? I don't want to waste time on side
> > > issues that have already been taken care of in the previous discussions.
>
> You ignored that request.
>
> ...
> > > That's a start. Now could you provide us with a test harness that
> > > demonstrates the problem? I wrote a simple test drive that didn't
> > > display any obvious problems, so apparently my test driver didn't
> > > trigger the problematic case.
> >
> > struct s1 { int x; };
> > struct s2 { int x; };
> > union u { struct s1 v1; struct s2 v2; } uarr[10];
> >
> > static int readS1x(struct s1 *p) { return p->x; }
> > static void writeS2x(struct s2 *p) { p->x = 5; }
> > int test(int i, int j)
> > {
> > if (readS1x(&uarr[i].v1))
> > writeS2x(&uarr[j].v2);
> > return readS1x(&uarr[i].v1);
> > }
> >
> > int (*volatile vtest)(int,int) = test;
> >
> > #include <stdio.h>
> > volatile int result;
> > int main(void)
> > {
> > uarr[0].v2.x = 1;
> > result = vtest(0,0);
> > printf("Result=%d", result);
> > }
> >
> > The generated code for "test" [gcc 7.3] is:
>
> I didn't ask for disassembled output displaying what you think is a problem. I don't have enough recent assembler experience to make an expert judgement about such code. I asked you for example code whose behavior demonstrates the problem you're talking about.
> I added "static" to test(), and "return 0;" to main(), and "\n" to the printf() format string. After those corrections, it compiled an executed to produce the following output:
>
> Result=5
>
> Which is, as I understand it, precisely what it's supposed to produce.
With which compiler and settings? Disabling optimizations within gcc
and clang will force them to yield correct code. I don't know any nice
test platforms that can execute code while offering control over compiler
settings, or even document what settings they're using.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-19 10:51 -0700 |
| Message-ID | <0ab0a61d-bbc0-49a0-b8f1-72f9c05f64c8@googlegroups.com> |
| In reply to | #129431 |
On Wednesday, April 18, 2018 at 4:26:05 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, April 18, 2018 at 2:30:36 PM UTC-5, james...@verizon.net wrote:
> > On Wednesday, April 18, 2018 at 3:15:35 PM UTC-4, supe...@casperkitty.com wrote:
> > > On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
> > > > On Wednesday, April 18, 2018 at 1:13:36 PM UTC-4, supe...@casperkitty.com wrote:
> > ...
> > > > > I've posted code many times where both gcc and clang create such a
> > > > > distinction.
> > > >
> > > > Could you provide Google Groups message links to identify previous
> > > > occasions when you discussed such code? I don't want to waste time on side
> > > > issues that have already been taken care of in the previous discussions.
> >
> > You ignored that request.
> >
> > ...
> > > > That's a start. Now could you provide us with a test harness that
> > > > demonstrates the problem? I wrote a simple test drive that didn't
> > > > display any obvious problems, so apparently my test driver didn't
> > > > trigger the problematic case.
> > >
> > > struct s1 { int x; };
> > > struct s2 { int x; };
> > > union u { struct s1 v1; struct s2 v2; } uarr[10];
> > >
> > > static int readS1x(struct s1 *p) { return p->x; }
> > > static void writeS2x(struct s2 *p) { p->x = 5; }
> > > int test(int i, int j)
> > > {
> > > if (readS1x(&uarr[i].v1))
> > > writeS2x(&uarr[j].v2);
> > > return readS1x(&uarr[i].v1);
> > > }
> > >
> > > int (*volatile vtest)(int,int) = test;
> > >
> > > #include <stdio.h>
> > > volatile int result;
> > > int main(void)
> > > {
> > > uarr[0].v2.x = 1;
> > > result = vtest(0,0);
> > > printf("Result=%d", result);
> > > }
> > >
> > > The generated code for "test" [gcc 7.3] is:
> >
> > I didn't ask for disassembled output displaying what you think is a problem. I don't have enough recent assembler experience to make an expert judgement about such code. I asked you for example code whose behavior demonstrates the problem you're talking about.
> > I added "static" to test(), and "return 0;" to main(), and "\n" to the printf() format string. After those corrections, it compiled an executed to produce the following output:
> >
> > Result=5
> >
> > Which is, as I understand it, precisely what it's supposed to produce.
>
> With which compiler and settings?
gcc -std=c11 -pedantic -Wall -Wpointer-arith -Wcast-align \
-Wstrict-prototypes -Wmissing-prototypes
When I added -O2, I was able to duplicate Keith's findings.
> ... Disabling optimizations within gcc
> and clang will force them to yield correct code. I don't know any nice
> test platforms that can execute code while offering control over compiler
> settings, or even document what settings they're using.
I do my testing from a terminal window running the tcsh shell. I have
complete control over the compiler settings, since my setup script
defines the value of the environment variable C99FLAGS, which contains
those settings. Presumably you would not consider this a "nice test
platform"? It's how I've done virtually all of my programming during my
entire career. I've been experimenting with Eclipse on my home machine,
but what I'm experimenting on is a program I'm writing to help with
retirement planning, which gives some hint about how long my programming
career has been. However, Eclipse also provides fairly good control over
the compiler options. I'm curious about the test platforms you're talking
about that don't give you such control.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-18 12:38 -0700 |
| Message-ID | <ln1sfcl2zj.fsf@kst-u.example.com> |
| In reply to | #129424 |
supercat@casperkitty.com writes:
> On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
[...]
>> That's a start. Now could you provide us with a test harness that
>> demonstrates the problem? I wrote a simple test drive that didn't
>> display any obvious problems, so apparently my test driver didn't
>> trigger the problematic case.
>
> struct s1 { int x; };
> struct s2 { int x; };
> union u { struct s1 v1; struct s2 v2; } uarr[10];
>
> static int readS1x(struct s1 *p) { return p->x; }
> static void writeS2x(struct s2 *p) { p->x = 5; }
> int test(int i, int j)
> {
> if (readS1x(&uarr[i].v1))
> writeS2x(&uarr[j].v2);
> return readS1x(&uarr[i].v1);
> }
>
> int (*volatile vtest)(int,int) = test;
>
> #include <stdio.h>
> volatile int result;
> int main(void)
> {
> uarr[0].v2.x = 1;
> result = vtest(0,0);
> printf("Result=%d", result);
> }
Thank you for providing a program whose output (I presume) illustrates
the issue. Please consider doing so in the first place for similar
cases in the future.
> The generated code for "test" [gcc 7.3] is:
[SNIP]
I don't care what the generated code is. The behavior of the program is
its output. I don't know that assembly code well enough to draw any
conclusions from a code listing.
> If test() isn't called through a "volatile" pointer, the compiler sometimes
> figures out while in-lining it that uarr[i] and uarr[j] might be related,
> but the standalone machine code for "test" is exactly as above.
I moved the "#include <stdio.h>" to the top of the source file. I think
it's ok where it is, but that's one less thing to worry about. I also
added a newline to the printf call.
With gcc 7.2.0 on Ubuntu, the output is "Result=5" with -O0 and -O1,
"Result=1" with -O2 and -O3. With clang 4.0.1, the output is "Result=5"
at all optimization levels. (tcc 0.9.27, which isn't fully conforming
but doesn't do much optimization, also produces "Result=5".)
With gcc 8.0.1 (experimental) built from source, the output is
"Result=5" at all optimization levels.
I haven't yet taken the time to study the code. I'm providing this
information for others who might want to discuss it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-18 14:39 -0700 |
| Message-ID | <b1efc557-470d-4199-82ca-eaa6cb70c5c2@googlegroups.com> |
| In reply to | #129427 |
On Wednesday, April 18, 2018 at 2:38:18 PM UTC-5, Keith Thompson wrote:
> With gcc 8.0.1 (experimental) built from source, the output is
> "Result=5" at all optimization levels.
>
> I haven't yet taken the time to study the code. I'm providing this
> information for others who might want to discuss it.
Interesting. I've mostly been using godbolt, which only goes up to 7.3;
I'm curious whether 8.0.1 made this code work by adding more kludges, or
by recognizing lvalue derivation as a sequenced action. Note that while
arrays of unions aren't exactly common, I used a union array rather than
two separate union pointers to make clear that any reasonable compiler
must recognize the possibility of uArr[i] and uArr[j] being the same
object.
When I request clang 4.0.1 on godbolt, it does indeed process the code
correctly, but the current 6.0.0 generates essentially the same code as
gcc 7.3. Both take code that should be equivalent to:
if (uArr[i].v1.x)
uArr[j].v2.x = 5;
return uArr[i].v1.x;
and turn it into:
int temp = uArr[i].v1.x;
if (temp)
uArr[j].v2.x = 5;
return temp;
ignoring the possibility that writing uArr[j] might affect the value
stored in uArr[i].
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-18 21:17 -0700 |
| Message-ID | <3e0e19ef-eac4-4528-9882-0bd18a18f39f@googlegroups.com> |
| In reply to | #129427 |
On Wednesday, April 18, 2018 at 3:38:18 PM UTC-4, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
> [...]
> >> That's a start. Now could you provide us with a test harness that
> >> demonstrates the problem? I wrote a simple test drive that didn't
> >> display any obvious problems, so apparently my test driver didn't
> >> trigger the problematic case.
> >
> > struct s1 { int x; };
> > struct s2 { int x; };
> > union u { struct s1 v1; struct s2 v2; } uarr[10];
> >
> > static int readS1x(struct s1 *p) { return p->x; }
> > static void writeS2x(struct s2 *p) { p->x = 5; }
> > int test(int i, int j)
> > {
> > if (readS1x(&uarr[i].v1))
> > writeS2x(&uarr[j].v2);
> > return readS1x(&uarr[i].v1);
> > }
> >
> > int (*volatile vtest)(int,int) = test;
> >
> > #include <stdio.h>
> > volatile int result;
> > int main(void)
> > {
> > uarr[0].v2.x = 1;
> > result = vtest(0,0);
> > printf("Result=%d", result);
> > }
>
> Thank you for providing a program whose output (I presume) illustrates
> the issue. Please consider doing so in the first place for similar
> cases in the future.
>
> > The generated code for "test" [gcc 7.3] is:
> [SNIP]
>
> I don't care what the generated code is. The behavior of the program is
> its output. I don't know that assembly code well enough to draw any
> conclusions from a code listing.
>
> > If test() isn't called through a "volatile" pointer, the compiler sometimes
> > figures out while in-lining it that uarr[i] and uarr[j] might be related,
> > but the standalone machine code for "test" is exactly as above.
>
> I moved the "#include <stdio.h>" to the top of the source file. I think
> it's ok where it is, but that's one less thing to worry about. I also
> added a newline to the printf call.
>
> With gcc 7.2.0 on Ubuntu, the output is "Result=5" with -O0 and -O1,
> "Result=1" with -O2 and -O3. With clang 4.0.1, the output is "Result=5"
> at all optimization levels. (tcc 0.9.27, which isn't fully conforming
> but doesn't do much optimization, also produces "Result=5".)
>
> With gcc 8.0.1 (experimental) built from source, the output is
> "Result=5" at all optimization levels.
>
> I haven't yet taken the time to study the code. I'm providing this
> information for others who might want to discuss it.
I hadn't bothered testing at different optimization levels, which is why I didn't see this.
It seems to me to unambiguously be a defect in gcc, so I checked to see if it had been reported. It has been, at least twice:
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892>
This is really about the common initial sequence rule (6.2.5.3p6), not the anti-aliasing rule (6.5p7), because the common initial sequence rule applies only when the relevant lvalues have compatible types, therefore inherently meeting the requirements of 6.5p7.
I've just added my own two cents' worth to those bug reports.
Those bug reports both have a status of suspended, but unwillingness to fix this bug seems to be primarily motivated by the fact that this rule can result in many anti-aliasing optimizations being disabled throughout long stretches of the code - anywhere that declaration of the complete type of the union is visible. If the relevant members have common types (such as int), that could be a lot of disabled optimizations.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-19 02:40 -0700 |
| Message-ID | <kfnr2nb5ybs.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129446 |
jameskuyper@verizon.net writes: > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319> ] > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892> ] > > This is really about the common initial sequence rule (6.2.5.3p6), > not the anti-aliasing rule (6.5p7), because the common initial > sequence rule applies only when the relevant lvalues have compatible > types, therefore inherently meeting the requirements of 6.5p7. > I've just added my own two cents' worth to those bug reports. > > Those bug reports both have a status of suspended, but unwillingness > to fix this bug seems to be primarily motivated by the fact that this > rule can result in many anti-aliasing optimizations being disabled > throughout long stretches of the code - anywhere that declaration of > the complete type of the union is visible. If the relevant members > have common types (such as int), that could be a lot of disabled > optimizations. Really? You think that would be a lot? ISTM the differences would be very minor.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-19 03:01 -0700 |
| Message-ID | <49f2aa4b-8e0f-47aa-b367-ec1c1c001907@googlegroups.com> |
| In reply to | #129449 |
On Thursday, April 19, 2018 at 2:40:19 AM UTC-7, Tim Rentsch wrote: > jameskuyper@verizon.net writes: > > > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319> ] > > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892> ] > > > > This is really about the common initial sequence rule (6.2.5.3p6), > > not the anti-aliasing rule (6.5p7), because the common initial > > sequence rule applies only when the relevant lvalues have compatible > > types, therefore inherently meeting the requirements of 6.5p7. > > I've just added my own two cents' worth to those bug reports. > > > > Those bug reports both have a status of suspended, but unwillingness > > to fix this bug seems to be primarily motivated by the fact that this > > rule can result in many anti-aliasing optimizations being disabled > > throughout long stretches of the code - anywhere that declaration of > > the complete type of the union is visible. If the relevant members > > have common types (such as int), that could be a lot of disabled > > optimizations. > > Really? You think that would be a lot? ISTM the differences > would be very minor. Just about everything chrisv says about what Flatfish has done is false. He has yet to realize people are not as stupid as he needs them to be. It was chrisv who forged me (and others) and did not even try to hide it. At one point, chrisv said a COLA denizen was "obsessing" over him, which was identified as him posting to himself. Was that meant to be your best shot? -- I Left My Husband & Daughter At Home And THIS happened! http://www.5z8.info/myspace-of-sex_q7q7zl_instant-purchase https://youtu.be/OffkiSAsYo8 https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8 Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-19 06:49 -0700 |
| Message-ID | <2d617783-e8ba-4474-8e55-03364d7cfaba@googlegroups.com> |
| In reply to | #129449 |
On Thursday, April 19, 2018 at 5:40:19 AM UTC-4, Tim Rentsch wrote: > jameskuyper@verizon.net writes: > > > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319> ] > > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892> ] > > > > This is really about the common initial sequence rule (6.2.5.3p6), > > not the anti-aliasing rule (6.5p7), because the common initial > > sequence rule applies only when the relevant lvalues have compatible > > types, therefore inherently meeting the requirements of 6.5p7. > > I've just added my own two cents' worth to those bug reports. > > > > Those bug reports both have a status of suspended, but unwillingness > > to fix this bug seems to be primarily motivated by the fact that this > > rule can result in many anti-aliasing optimizations being disabled > > throughout long stretches of the code - anywhere that declaration of > > the complete type of the union is visible. If the relevant members > > have common types (such as int), that could be a lot of disabled > > optimizations. > > Really? You think that would be a lot? ISTM the differences > would be very minor. I wasn't thinking about it correctly - anti-aliasing optimizations are an issue for the the struct types - not the types of the members of the common initial sequence. As such, I think it would probably be rare for large numbers of anti-aliasing optimization opportunities to be lost because of this rule.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-19 07:58 -0700 |
| Message-ID | <a7a99520-11e0-4c9c-b143-159d2a125db8@googlegroups.com> |
| In reply to | #129455 |
On Thursday, April 19, 2018 at 6:49:51 AM UTC-7, james...@verizon.net wrote: > On Thursday, April 19, 2018 at 5:40:19 AM UTC-4, Tim Rentsch wrote: > > jameskuyper@verizon.net writes: > > > > > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319> ] > > > [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892> ] > > > > > > This is really about the common initial sequence rule (6.2.5.3p6), > > > not the anti-aliasing rule (6.5p7), because the common initial > > > sequence rule applies only when the relevant lvalues have compatible > > > types, therefore inherently meeting the requirements of 6.5p7. > > > I've just added my own two cents' worth to those bug reports. > > > > > > Those bug reports both have a status of suspended, but unwillingness > > > to fix this bug seems to be primarily motivated by the fact that this > > > rule can result in many anti-aliasing optimizations being disabled > > > throughout long stretches of the code - anywhere that declaration of > > > the complete type of the union is visible. If the relevant members > > > have common types (such as int), that could be a lot of disabled > > > optimizations. > > > > Really? You think that would be a lot? ISTM the differences > > would be very minor. > > I wasn't thinking about it correctly - anti-aliasing optimizations are > an issue for the the struct types - not the types of the members of the > common initial sequence. As such, I think it would probably be rare for > large numbers of anti-aliasing optimization opportunities to be lost > because of this rule. MATE is based on Linux. All that Donny Karcie cares about is that Donny Karcie gets to broadcast his automated call and then hang up and giggle about it. The fact that Jessica Lane is an innocent patsy on the other end of the phone is what's funny. That's what Donny Karcie does when he gets humiliated. He of course creates a flood, starts a cross posted thread so he can claim some lie. Don't blame me it was my left hand... and then he babbles to his own post with his right hand. Who are you even blubbering to? What is your evidence? Rambling cretin. Advertising is a wonderful thing and consumer cluelessness is even better. - Puppy Videos! https://youtu.be/5OfWsoPAg7o https://youtu.be/UkAyrfOZaXc https://groups.google.com/forum/#!topic/comp.sys.mac.system/6m_7Z7rQ6Hg Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-20 08:19 -0700 |
| Message-ID | <kfnk1t152i3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129455 |
jameskuyper@verizon.net writes: > On Thursday, April 19, 2018 at 5:40:19 AM UTC-4, Tim Rentsch wrote: > >> jameskuyper@verizon.net writes: >> >>> [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319> ] >>> [ <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892> ] >>> >>> This is really about the common initial sequence rule (6.2.5.3p6), >>> not the anti-aliasing rule (6.5p7), because the common initial >>> sequence rule applies only when the relevant lvalues have compatible >>> types, therefore inherently meeting the requirements of 6.5p7. >>> I've just added my own two cents' worth to those bug reports. >>> >>> Those bug reports both have a status of suspended, but unwillingness >>> to fix this bug seems to be primarily motivated by the fact that this >>> rule can result in many anti-aliasing optimizations being disabled >>> throughout long stretches of the code - anywhere that declaration of >>> the complete type of the union is visible. If the relevant members >>> have common types (such as int), that could be a lot of disabled >>> optimizations. >> >> Really? You think that would be a lot? ISTM the differences >> would be very minor. > > I wasn't thinking about it correctly - anti-aliasing optimizations are > an issue for the the struct types - not the types of the members of the > common initial sequence. As such, I think it would probably be rare for > large numbers of anti-aliasing optimization opportunities to be lost > because of this rule. I see you also followed up in the bugzilla thread. I'm glad that's happening - it looks like the gcc folks are finally starting to see the light.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-19 12:17 -0700 |
| Message-ID | <04a0e8eb-f865-49fd-89fa-9274a1e5c9ac@googlegroups.com> |
| In reply to | #129446 |
On Wednesday, April 18, 2018 at 11:17:45 PM UTC-5, james...@verizon.net wrote:
> On Wednesday, April 18, 2018 at 3:38:18 PM UTC-4, Keith Thompson wrote:
> > supercat@casperkitty.com writes:
> > > On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
> > [...]
> > >> That's a start. Now could you provide us with a test harness that
> > >> demonstrates the problem? I wrote a simple test drive that didn't
> > >> display any obvious problems, so apparently my test driver didn't
> > >> trigger the problematic case.
> > >
> > > struct s1 { int x; };
> > > struct s2 { int x; };
> > > union u { struct s1 v1; struct s2 v2; } uarr[10];
> > >
> > > static int readS1x(struct s1 *p) { return p->x; }
> > > static void writeS2x(struct s2 *p) { p->x = 5; }
> > > int test(int i, int j)
> > > {
> > > if (readS1x(&uarr[i].v1))
> > > writeS2x(&uarr[j].v2);
> > > return readS1x(&uarr[i].v1);
> > > }
> > >
> > > int (*volatile vtest)(int,int) = test;
> > >
> > > #include <stdio.h>
> > > volatile int result;
> > > int main(void)
> > > {
> > > uarr[0].v2.x = 1;
> > > result = vtest(0,0);
> > > printf("Result=%d", result);
> > > }
> >
> > Thank you for providing a program whose output (I presume) illustrates
> > the issue. Please consider doing so in the first place for similar
> > cases in the future.
> >
> > > The generated code for "test" [gcc 7.3] is:
> > [SNIP]
> >
> > I don't care what the generated code is. The behavior of the program is
> > its output. I don't know that assembly code well enough to draw any
> > conclusions from a code listing.
> >
> > > If test() isn't called through a "volatile" pointer, the compiler sometimes
> > > figures out while in-lining it that uarr[i] and uarr[j] might be related,
> > > but the standalone machine code for "test" is exactly as above.
> >
> > I moved the "#include <stdio.h>" to the top of the source file. I think
> > it's ok where it is, but that's one less thing to worry about. I also
> > added a newline to the printf call.
> >
> > With gcc 7.2.0 on Ubuntu, the output is "Result=5" with -O0 and -O1,
> > "Result=1" with -O2 and -O3. With clang 4.0.1, the output is "Result=5"
> > at all optimization levels. (tcc 0.9.27, which isn't fully conforming
> > but doesn't do much optimization, also produces "Result=5".)
> >
> > With gcc 8.0.1 (experimental) built from source, the output is
> > "Result=5" at all optimization levels.
> >
> > I haven't yet taken the time to study the code. I'm providing this
> > information for others who might want to discuss it.
>
> I hadn't bothered testing at different optimization levels, which is why I didn't see this.
> It seems to me to unambiguously be a defect in gcc, so I checked to see if it had been reported. It has been, at least twice:
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892>
> This is really about the common initial sequence rule (6.2.5.3p6), not the anti-aliasing rule (6.5p7), because the common initial sequence rule applies only when the relevant lvalues have compatible types, therefore inherently meeting the requirements of 6.5p7.
> I've just added my own two cents' worth to those bug reports.
>
> Those bug reports both have a status of suspended, but unwillingness to fix this bug seems to be primarily motivated by the fact that this rule can result in many anti-aliasing optimizations being disabled throughout long stretches of the code - anywhere that declaration of the complete type of the union is visible. If the relevant members have common types (such as int), that could be a lot of disabled optimizations.
There would be no need to disable optimizations wholesale if the compiler
paid attention to when code took the address of union members, and made
sure that a pointer to a union member would be usable to access it at least
until the storage was accessed via means not derived from that union member,
or until code entered a function or loop where that would occur.
Are you starting to see, though, why I believe the authors of gcc would
oppose having the Standard say that use of a derived pointer counts as use
of the original for purposes of 6.5p7?
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-19 12:51 -0700 |
| Message-ID | <53a99d45-70aa-4242-b88b-9214770efc88@googlegroups.com> |
| In reply to | #129463 |
On Thursday, April 19, 2018 at 3:17:27 PM UTC-4, supe...@casperkitty.com wrote: > On Wednesday, April 18, 2018 at 11:17:45 PM UTC-5, james...@verizon.net wrote: ... > > It seems to me to unambiguously be a defect in gcc, so I checked to see if it had been reported. It has been, at least twice: > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319> > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892> > > This is really about the common initial sequence rule (6.2.5.3p6), not the > > anti-aliasing rule (6.5p7), because the common initial sequence rule applies > > only when the relevant lvalues have compatible types, therefore inherently > > meeting the requirements of 6.5p7. > > I've just added my own two cents' worth to those bug reports. > > > > Those bug reports both have a status of suspended, but unwillingness to fix > > this bug seems to be primarily motivated by the fact that this rule can > > result in many anti-aliasing optimizations being disabled throughout long > > stretches of the code - anywhere that declaration of the complete type of > > the union is visible. If the relevant members have common types (such as > > int), that could be a lot of disabled optimizations. ... > Are you starting to see, though, why I believe the authors of gcc would > oppose having the Standard say that use of a derived pointer counts as use > of the original for purposes of 6.5p7? Not really. When I wrote that, I shared their opinion of the likely impact; but I now believe that's based upon a misconception about the scope of that rule. Correcting that misconception should, ideally, be sufficient to remove their opposition.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-19 13:37 -0700 |
| Message-ID | <6aec536c-6547-4615-aa38-b1b873acf6df@googlegroups.com> |
| In reply to | #129465 |
On Thursday, April 19, 2018 at 2:52:08 PM UTC-5, james...@verizon.net wrote: > On Thursday, April 19, 2018 at 3:17:27 PM UTC-4, supe...@casperkitty.com wrote: > > Are you starting to see, though, why I believe the authors of gcc would > > oppose having the Standard say that use of a derived pointer counts as use > > of the original for purposes of 6.5p7? > > Not really. When I wrote that, I shared their opinion of the likely > impact; but I now believe that's based upon a misconception about the > scope of that rule. Correcting that misconception should, ideally, be > sufficient to remove their opposition. The authors of gcc have long maintained that code which is incompatible with -fstrict-aliasing is "broken". Making any significant effort to notice places where lvalues of one type are used to derive lvalues of another would make gcc compatible with most of code that the authors of gcc have claimed for over a decade was "broken" and could only be supported by gutting optimizations. I would hope the authors of gcc would be willing to make such a change, but if an easy change would make gcc compatible without significantly impeding optimizations, that would suggest there was never any good reason for gcc's behavior.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-19 21:08 +0000 |
| Message-ID | <Ry7CC.2305$pg3.1653@fx29.iad> |
| In reply to | #129469 |
supercat@casperkitty.com writes: >On Thursday, April 19, 2018 at 2:52:08 PM UTC-5, james...@verizon.net wrote: >> On Thursday, April 19, 2018 at 3:17:27 PM UTC-4, supe...@casperkitty.com wrote: >> > Are you starting to see, though, why I believe the authors of gcc would >> > oppose having the Standard say that use of a derived pointer counts as use >> > of the original for purposes of 6.5p7? >> >> Not really. When I wrote that, I shared their opinion of the likely >> impact; but I now believe that's based upon a misconception about the >> scope of that rule. Correcting that misconception should, ideally, be >> sufficient to remove their opposition. > >The authors of gcc have long maintained that code which is incompatible >with -fstrict-aliasing is "broken". Making any significant effort to >notice places where lvalues of one type are used to derive lvalues of >another would make gcc compatible with most of code that the authors >of gcc have claimed for over a decade was "broken" and could only be >supported by gutting optimizations. Again you impute motive to the gcc team without citation. In fact, it's a highly diverse team of volunteer skilled compiler experts. If one does write such code, which even you must agree is exceedingly rare, one is free to specify -fno-strict-aliasing on the command line (with the desired optimization level still specified via -Ox). I don't see a problem with that, in fact bare-metal, OS and hypervisor code compiled with gcc typically specifies -fno-strict-aliasing.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-19 14:50 -0700 |
| Message-ID | <bec7c4af-a990-40a8-80f9-9288bcdf168b@googlegroups.com> |
| In reply to | #129470 |
On Thursday, April 19, 2018 at 4:08:11 PM UTC-5, Scott Lurndal wrote: > supercat@casperkitty.com writes: > >On Thursday, April 19, 2018 at 2:52:08 PM UTC-5, james...@verizon.net wrote: > >> On Thursday, April 19, 2018 at 3:17:27 PM UTC-4, supe...@casperkitty.com wrote: > >> > Are you starting to see, though, why I believe the authors of gcc would > >> > oppose having the Standard say that use of a derived pointer counts as use > >> > of the original for purposes of 6.5p7? > >> > >> Not really. When I wrote that, I shared their opinion of the likely > >> impact; but I now believe that's based upon a misconception about the > >> scope of that rule. Correcting that misconception should, ideally, be > >> sufficient to remove their opposition. > > > >The authors of gcc have long maintained that code which is incompatible > >with -fstrict-aliasing is "broken". Making any significant effort to > >notice places where lvalues of one type are used to derive lvalues of > >another would make gcc compatible with most of code that the authors > >of gcc have claimed for over a decade was "broken" and could only be > >supported by gutting optimizations. > > Again you impute motive to the gcc team without citation. In fact, > it's a highly diverse team of volunteer skilled compiler experts. Do you disagree that the authors of gcc have long maintained that code which is incompatible with -fstrict-aliasing is "broken"? Do you disagree that recognizing accesses to derived lvalues as accesses to the parent, at least in the context where the derivation takes place and in contexts where an object is used exclusively with the derived value, would make gcc compatible with a lot of "broken" code while still allowing most optimizations -fno-strict-aliasing would otherwise block? I don't know whether the authors of gcc would oppose such recognition because it would be require a major overhaul of their compiler, or because it would require them to admit that they should have done so ages ago, but I doubt they'd approve of the Standard requiring them to do something that they have, as yet, for whatever reason, refused to do. > If one does write such code, which even you must agree is exceedingly > rare, one is free to specify -fno-strict-aliasing on the command > line (with the desired optimization level still specified via -Ox). Code which relies upon the Common Initial Sequence rule applying in cases where a struct member is inspected using a pointer that is visibly derived from the lvalue used for the previous and succeeding accesses is way more common than code which performs such inspection directly upon an object of the union type. > I don't see a problem with that, in fact bare-metal, OS and hypervisor code > compiled with gcc typically specifies -fno-strict-aliasing. Such code often is compiled with that flag, but most of it wouldn't have to be if a compiler made any effort at all to recognize derived lvalues in straight-line code or in functions where any storage accessed using them was accessed *exclusively* using them.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-19 14:56 -0700 |
| Message-ID | <916de3ee-e0c7-4e3a-909e-c2f9a8ba91f6@googlegroups.com> |
| In reply to | #129469 |
On Thursday, April 19, 2018 at 4:37:38 PM UTC-4, supe...@casperkitty.com wrote: > On Thursday, April 19, 2018 at 2:52:08 PM UTC-5, james...@verizon.net wrote: > > On Thursday, April 19, 2018 at 3:17:27 PM UTC-4, supe...@casperkitty.com wrote: > > > Are you starting to see, though, why I believe the authors of gcc would > > > oppose having the Standard say that use of a derived pointer counts as use > > > of the original for purposes of 6.5p7? > > > > Not really. When I wrote that, I shared their opinion of the likely > > impact; but I now believe that's based upon a misconception about the > > scope of that rule. Correcting that misconception should, ideally, be > > sufficient to remove their opposition. > > The authors of gcc have long maintained that code which is incompatible > with -fstrict-aliasing is "broken". Insofar as such code violates the committee's intent when writing 6.5p7, I agree with them (I don't believe that they or any other sane implementor takes advantage of the ways in which 6.5p7 fails to correctly describe the intent of the committee). Insofar as such code relies upon 6.5.2.3p6, I believe they are dead wrong. > Making any significant effort to > notice places where lvalues of one type are used to derive lvalues of > another would make gcc compatible with most of code that the authors > of gcc have claimed for over a decade was "broken" and could only be > supported by gutting optimizations. Correcting their code generation to be consistent with 6.5.2.3p6 should only slightly reduce their opportunities to take advantage of 6.5p7; it shouldn't required gutting optimizations. I'm not sure what your suggestion actually means, but if it would require such gutting, it isn't the right solution to this problem. > I would hope the authors of gcc would be willing to make such a change, > but if an easy change would make gcc compatible without significantly > impeding optimizations, ... I'm not sure it's an easy change, only that if done properly, it shouldn't have a major impact on the speed of the generated code. That's because cases where 6.5.2.3p6 constrains such optimizations are relatively rare - but determining whether 6.5.2.3p6 constrains such optimizations might be fairly expensive.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-19 16:13 -0700 |
| Message-ID | <aca4ba97-8a4a-473b-9c7e-15c1086b257a@googlegroups.com> |
| In reply to | #129474 |
On Thursday, April 19, 2018 at 4:56:58 PM UTC-5, james...@verizon.net wrote:
> On Thursday, April 19, 2018 at 4:37:38 PM UTC-4, supe...@casperkitty.com wrote:
> > Making any significant effort to
> > notice places where lvalues of one type are used to derive lvalues of
> > another would make gcc compatible with most of code that the authors
> > of gcc have claimed for over a decade was "broken" and could only be
> > supported by gutting optimizations.
>
> Correcting their code generation to be consistent with 6.5.2.3p6 should only slightly reduce their opportunities to take advantage of 6.5p7; it shouldn't required gutting optimizations. I'm not sure what your suggestion actually means, but if it would require such gutting, it isn't the right solution to this problem.
Consider the following two functions:
struct s1 { int x; };
struct s2 { int x; };
void update_s2(struct s2 *p2) { p2->x=2; }
int test1(struct s1 *p1, struct s2 *p2)
{
if (p1->x)
update_s2(p2);
return p1->x;
}
int test2(struct s1 *p1, struct s1 *p2)
{
if (p1->x)
update_s2((struct s2*)p2);
return p1->x;
}
Requiring that a compiler recognize the possibility of aliasing in all
functions that look like "test1" would impair many useful optimizations
in cases where the structs are used for totally different purposes. I
don't think much code that relies upon the CIS rule would resemble the
first pattern; it would be far more likely to resemble the second, where
uses as type "struct s1" and "struct s2" are separated by a conversion
from "struct s1*" to "struct s2*", and where that conversion is performed
during the execution of the function where the structure will next be
used as a "struct s1".
Note that when "update_s2" is called from test2(), it may have no way
of knowing that the object being updated will be accessed as a "struct s1",
but in cases where it can't know it shouldn't need to care. If the
code is being compiled "stand-alone" a compiler won't be able to optimize
out the write as s2, and the calling code wouldn't be able to optimize out
the next read as s1. If the code is being in-lined, a compiler would be
able to see that the pointer being passed is derived from a "struct s1*",
and thus recognize that operations on that pointer might affect a "struct
s1".
The problem is that for whatever reason the authors of gcc seem to view
test1() and test2() as equivalent. Making code like test1() recognize
the possibility of aliasing would be expensive, and the authors of gcc use
that as an excuse not to allow for the possibility of aliasing in test2().
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-21 10:27 -0700 |
| Message-ID | <4b0e4b95-e008-4739-9dc5-62f308402bd2@googlegroups.com> |
| In reply to | #129474 |
On Thursday, April 19, 2018 at 4:56:58 PM UTC-5, james...@verizon.net wrote:
> On Thursday, April 19, 2018 at 4:37:38 PM UTC-4, supe...@casperkitty.com wrote:
> > I would hope the authors of gcc would be willing to make such a change,
> > but if an easy change would make gcc compatible without significantly
> > impeding optimizations, ...
>
> I'm not sure it's an easy change, only that if done properly, it shouldn't have a major impact on the speed of the generated code. That's because cases where 6.5.2.3p6 constrains such optimizations are relatively rare - but determining whether 6.5.2.3p6 constrains such optimizations might be fairly expensive.
The Standard has a few bodges that try to define behaviors in cases where
6.5p7 should but doesn't. While unrelated structure types aren't likely
to appear together in a union declaration unless at least some code expects
to use type punning, and thus the cost of regarding a union declaration as
a warning that type punning might occur would be relatively slight [cheaper
than the costs of complying with the Effective Type bodge], such recognition
would still merely be a bodge that wouldn't be necessary if the Standard
were to address the fundamental problem with 6.5p7.
Given the pattern of steps [not necessarily within the same function]
nonCharacterType *p;
... do stuff
p = &aggregate.member;
... do more stuff
... operate upon *p here and never again
... still more stuff in function that used *p
the Committee clearly intended that there be some situations where
the operation upon *p should have defined behavior equivalent to
an operation upon aggregate.member, and there should be some situations
where it should invoke UB. If the Standard were to say that behavior
is equivalent *except* when code does certain incompatible operations
within "...do more stuff" or "...still more stuff", that would render
the other bodges unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-23 11:37 -0700 |
| Message-ID | <kfn36zl4vmq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129474 |
jameskuyper@verizon.net writes: > On Thursday, April 19, 2018 at 4:37:38 PM UTC-4, supe...@casperkitty.com wrote: > >> On Thursday, April 19, 2018 at 2:52:08 PM UTC-5, james...@verizon.net wrote: >> >>> On Thursday, April 19, 2018 at 3:17:27 PM UTC-4, supe...@casperkitty.com wrote: >>> >>>> Are you starting to see, though, why I believe the authors of gcc would >>>> oppose having the Standard say that use of a derived pointer counts as use >>>> of the original for purposes of 6.5p7? >>> >>> Not really. When I wrote that, I shared their opinion of the likely >>> impact; but I now believe that's based upon a misconception about the >>> scope of that rule. Correcting that misconception should, ideally, be >>> sufficient to remove their opposition. >> >> The authors of gcc have long maintained that code which is incompatible >> with -fstrict-aliasing is "broken". > > Insofar as such code violates the committee's intent when writing > 6.5p7, I agree with them (I don't believe that they or any other sane > implementor takes advantage of the ways in which 6.5p7 fails to > correctly describe the intent of the committee). Insofar as such > code relies upon 6.5.2.3p6, I believe they are dead wrong. The usage of "insofar" here seems a bit off. I understand what you mean (at least, I think I understand what I think you mean): basically, you agree with their judgment in cases where 6.5 p7 is not satisfied, and you don't agree with their judgment in cases where (in your view) the conditions of 6.5.3.2 p6 are met, but they don't think they are. Even though the meaning comes through I don't think how "insofar" is used here is a good way to express it.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-18 16:07 -0700 |
| Message-ID | <fef3673f-02a7-4d73-97d5-88ef02e9d4d8@googlegroups.com> |
| In reply to | #129408 |
On Wednesday, April 18, 2018 at 9:12:49 AM UTC-7, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] > > The ability to pass the address of an object to functions that can use > > the object, at least until the next time the object is addressed via other > > means, is no less fundamental than the ability to use the structure > > directly. Both clang and gcc, however, *invent* a distinction between > > direct and indirect use of objects. > > I'm probably going to regret asking this, but can you support the > claim in your last sentence? (I request that you do so without > asking rhetorical questions.) > > [...] > > -- > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > Working, but not speaking, for JetHead Development, Inc. > "We must do something. This is something. Therefore, we must do this." > -- Antony Jay and Jonathan Lynn, "Yes Minister" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It was me and "trolling" meant pointing out your inconsistencies: "He has lied about the war on Iraq. An illegal war. One that makes him a war criminal." - Snit A week later: "Right: I can not unequivocally state that Bush is a war criminal." - Snit The following week: "Bush is a war criminal". - Snit Just mass confusion from you: "Ok... Morally he is a war criminal. Legally, it has not been decided." - Snit This is really no different than what owl just complained about in this thread, your obvious confusion is causing you to make inconsistent statements. Maybe someday, when you lay off the meds long enough, your brain may come back... but I doubt it ;) -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVRYkSAAoJEC03b6bOr/+dr7IP/1Z9K8QBaI8IfhOHC80aLVVu TLB1Cioe7BOV6KJ7kDCwS3llCPvgBLiLOMieFQDxMu6TogniEJzuZVBQL8Ivl4AT hbr36JSgN1GYnUHR3W14tficgW2Y/An7oYv3jYW5WjRM3hBUBq1A5FKtOUGObygp g1cNoNz2nd5rbEhfEApK9HBY3GsZjKUr120dp9bx8dKjSEklPXMWH7Qi2poOLATg RFemLCwUTn5+FwOIclI1Sxqi1CC3oYSS9nhk+Y1kdH89kfF7n91k2T7Bj00166qH erkm7wC07bnfq02omMqnjvaSc4BnRDtFLuZwa4U8zo+QtqRsfr6skT2Dbacj9rSH 1qVVsGqI6etckD3NLnOclstu+l/hRfGT7iQR8+YTRl+aZ9p/CJGc1XCCUlB5DyT4 Ffk2JRIwbHCbwcIxSdJOGxmzFpScTfh/pHUVmhuI1XXxprnxZoNCBI6PKhCB3lNh h0VbWixAwlQy5GOmqlH3W12eX0jQDdpEoPZbDYuAwugrvPEQXkho3Fsg1Hc1xkYW 6Qag+8MPxEOzIesTmMlQTLR6FLo38uoG9XCS0ykemcCQaWTdJ8sWm51cF9aRz1w7 lKVEiulNtiQIKKnMXhMgJPt0avNxZUZDEo6erzyoCaBmqisv6C4aqQWRNMnElFWJ uVezR4u0/sYGCYa1InhL =fdE9 -----END PGP SIGNATURE----- - Live on Kickstarter! https://goo.gl/Fho5Nq http://bit.ly/2oNYRgv http://comp.os.linux.advocacy.narkive.com/711dskzA/steven-petruzzellis-admits-he-can-not-back-his-claims-about-snit Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web