gcc-8-20191004 is now available
Snapshot gcc-8-20191004 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20191004/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 276612 You'll find: gcc-8-20191004.tar.xzComplete GCC SHA256=8b33e72402d79140684f926b324f415f15ece21a4e3dfb082472ff527b5bea4e SHA1=3127b83345e9557a8a48a3fae76c8b4c101d367e Diffs from 8-20190927 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: SPEC 2017 profiling question (502.gcc_r and 505.mcf_r fail)
On Fri, 2019-10-04 at 15:58 -0500, Bill Schmidt wrote: > > > Has anyone else seen these failures? > > > Have you tried -fno-strict-aliasing? There is a known issue with > spec_qsort() that affects both of these benchmarks. See > https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D83201&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=Kj0CuWu6MgrNHos80CzrFt4fiXgwrFhMWDTO9Ue_lRU&m=M5tfnhGt9QWxrZvk7eKa9J_EonLqJs6YezVWveUtFhM&s=gesldYv1Oq8frkNSrX4O912SsKENeUKBZZruZ5UZ-NM&e= > . > > Hope this helps, > > Bill Ah, of course, thank you. I verified that this fixes my mcf failure, gcc is still running. I already had -fno-strict-aliasing for perlbench, I should have figured out that it could be affecting other tests too. Steve Ellcey sell...@marvell.com
Re: SPEC 2017 profiling question (502.gcc_r and 505.mcf_r fail)
Am 04.10.19 um 22:58 schrieb Bill Schmidt: Have you tried -fno-strict-aliasing? There is a known issue with spec_qsort() that affects both of these benchmarks. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201. Reading that bug report (another refusal to correct a glaring standards violation) convinces me just a tiny little bit more that SPEC is a cancer.
Re: SPEC 2017 profiling question (502.gcc_r and 505.mcf_r fail)
On 10/4/19 10:13 AM, Steve Ellcey wrote: I am curious if anyone has tried running 'peak' SPEC 2017 numbers using profiling. Now that the cactus lto bug has been fixed I can run all the SPEC intrate and fprate benchmarks with '-Ofast -flto -march=native' on my aarch64 box and get accurate results but when I try to use these options along with -fprofile-generate/-fprofile-use I get two verification errors: 502.gcc_r and 505.mcf_r. The gcc benchmark is generating different assembly language for some of its tests and mcf is generating different numbers that look too large to just be due to unsafe math optimizations. Has anyone else seen these failures? Have you tried -fno-strict-aliasing? There is a known issue with spec_qsort() that affects both of these benchmarks. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201. Hope this helps, Bill Steve Ellcey sell...@marvell.com
SPEC 2017 profiling question (502.gcc_r and 505.mcf_r fail)
I am curious if anyone has tried running 'peak' SPEC 2017 numbers using profiling. Now that the cactus lto bug has been fixed I can run all the SPEC intrate and fprate benchmarks with '-Ofast -flto -march=native' on my aarch64 box and get accurate results but when I try to use these options along with -fprofile-generate/-fprofile-use I get two verification errors: 502.gcc_r and 505.mcf_r. The gcc benchmark is generating different assembly language for some of its tests and mcf is generating different numbers that look too large to just be due to unsafe math optimizations. Has anyone else seen these failures? Steve Ellcey sell...@marvell.com
Re: compatibility of structs/unions/enums in the middle end
Am Freitag, den 04.10.2019, 14:28 +0200 schrieb Richard Biener:
> On Fri, Oct 4, 2019 at 1:55 PM Uecker, Martin
> wrote:
> >
> > Am Freitag, den 04.10.2019, 12:29 +0200 schrieb Richard Biener:
> > > On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
> > > wrote:
> > > >
> > > > Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
> > > >
> > > > ...
> > > >
> > > > > > > Oh, and LTO does _not_ merge types declared inside a function,
> > > > > > > so
> > > > > > >
> > > > > > > void foo () { struct S { int i; }; }
> > > > > > > void bar () { struct S { int i; }; }
> > > > > > >
> > > > > > > the two S are distinct and objects of that type do not conflict.
> > > > > >
> > > > > > This is surprising as these types are compatible across TUs. So
> > > > > > if some pointer is passed between these functions this is
> > > > > > supposed to work.
> > > > >
> > > > > So if they are compatible the frontend needs to mark them so in this
> > > > > case.
> > > >
> > > > It can't. The front end never sees the other TU.
> > >
> > > If the type "leaves" the CU via a call the called function has a prototype
> > > through which it "sees" the CU.
> >
> > The prototype could be local to the function or it could be a void*
> > (or other pointer type) argument.
> >
> >
> >
> > TU1---
> > #include
> >
> > extern void f(void *p);
> >
> > int main()
> > {
> > struct foo { int x; } b;
> > b.x = 2;
> > f(&b);
> > printf("%d\n", b.x);
> > }
> >
> > TU2-
> > extern void f(void *p)
> > {
> > struct foo { int x; } *q = p;
> > q->x = 3;
> > }
>
> If the frontend puts those structures at local scope
> then yes, the above presents a problem to LTO
> at the moment. So, trigger some inlining,
> make main() read b.x after f(&b) and assert that
> it is 3. I think that would fail at the moment.
I expected it to fail, but it seems to work (returns 3).
Maybe by chance.
The example which doesn't work is the one I gave
at the beginning in the thread (even without lto).
Best,
Martin
Re: compatibility of structs/unions/enums in the middle end
On Fri, Oct 4, 2019 at 1:55 PM Uecker, Martin
wrote:
>
> Am Freitag, den 04.10.2019, 12:29 +0200 schrieb Richard Biener:
> > On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
>
> > >
> > > ...
> > >
> > > > > > Oh, and LTO does _not_ merge types declared inside a function,
> > > > > > so
> > > > > >
> > > > > > void foo () { struct S { int i; }; }
> > > > > > void bar () { struct S { int i; }; }
> > > > > >
> > > > > > the two S are distinct and objects of that type do not conflict.
> > > > >
> > > > > This is surprising as these types are compatible across TUs. So
> > > > > if some pointer is passed between these functions this is
> > > > > supposed to work.
> > > >
> > > > So if they are compatible the frontend needs to mark them so in this
> > > > case.
> > >
> > > It can't. The front end never sees the other TU.
> >
> > If the type "leaves" the CU via a call the called function has a prototype
> > through which it "sees" the CU.
>
> The prototype could be local to the function or it could be a void*
> (or other pointer type) argument.
>
>
>
> TU1---
> #include
>
> extern void f(void *p);
>
> int main()
> {
> struct foo { int x; } b;
> b.x = 2;
> f(&b);
> printf("%d\n", b.x);
> }
>
> TU2-
> extern void f(void *p)
> {
> struct foo { int x; } *q = p;
> q->x = 3;
> }
If the frontend puts those structures at local scope
then yes, the above presents a problem to LTO
at the moment. So, trigger some inlining,
make main() read b.x after f(&b) and assert that
it is 3. I think that would fail at the moment.
Richard.
> Best,
> Martin
Re: compatibility of structs/unions/enums in the middle end
Am Freitag, den 04.10.2019, 12:29 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
> wrote:
> >
> > Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
> >
> > ...
> >
> > > > > Oh, and LTO does _not_ merge types declared inside a function,
> > > > > so
> > > > >
> > > > > void foo () { struct S { int i; }; }
> > > > > void bar () { struct S { int i; }; }
> > > > >
> > > > > the two S are distinct and objects of that type do not conflict.
> > > >
> > > > This is surprising as these types are compatible across TUs. So
> > > > if some pointer is passed between these functions this is
> > > > supposed to work.
> > >
> > > So if they are compatible the frontend needs to mark them so in this case.
> >
> > It can't. The front end never sees the other TU.
>
> If the type "leaves" the CU via a call the called function has a prototype
> through which it "sees" the CU.
The prototype could be local to the function or it could be a void*
(or other pointer type) argument.
TU1---
#include
extern void f(void *p);
int main()
{
struct foo { int x; } b;
b.x = 2;
f(&b);
printf("%d\n", b.x);
}
TU2-
extern void f(void *p)
{
struct foo { int x; } *q = p;
q->x = 3;
}
Best,
Martin
Re: [EXT] Re: Modifying types during optimization
On Wed, Oct 2, 2019 at 8:50 PM Gary Oblock wrote: > > On 10/2/19 3:15 AM, Richard Biener wrote: > > External Email > > > > -- > > On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock wrote: > >> I'm working on structure reorganization optimizations and one of the > >> things that needs to happen is that pointers to arrays of structures > >> need to be modified into either being an integer of a structure depending > >> on which optimization is required. > >> > >> I'm seeing something similar happening in omp-low.c where the code in > >> install_var_field and fixup_child_record_type both seem to rebuild the > >> entire type from scratch if a field is either added or modified. Wouldn't > >> it be possible simply modify the field(s) in question and rerun > >> layout_type? > >> > >> I suspect the answer will be no but reasons as to why that wouldn't work > >> will probably be equally valuable to me. > > I think it's undesirable at least. When last discussing "structure reorg" > > I was always arguing that trying to change the "type" is the wrong angle > > to look at (likewise computing something like "type escape"). It's > > really individual objects you are transforming and that you need to track > > so there may be very well instances of the original type T plus the > > modified type T' in the program after the transform. > > > > Richard. > > > >> Thanks, > >> > >> Gary Oblock > >> > Richard, Hope you don't mind I CC the list on my answer. > You are right, in that T' is a whole new type that I'll be creating for > the actual structure > reorganization optimizations but if I have a pointer pointing to to a T' > object I also have > to change "that." Well, actually you don't have to(*). On GIMPLE what matters in the end are the types of the actual memory accesses, the type of a record field isn't important, esp. if it is "only" a pointer. > Unfortunately, if this pointer is an element of a > structure type > then I also have to modify that structure type. Note, there are > situations where that pointer > could possibly point to either T or T' in which case I have to > disqualify the optimization > on T. There are lot's details like that but this is probably not the > best forum to transmit > them. I always thought people are too obsessed on "types" when doing structure layout optimizations. What they really are after is optimizing memory layout and thus the transformation is on the memory accesses. IIRC the original implementation GCC had tried to mostly get away with mangling the types and the actual memory accesses changing "auto-magically". But that severely limits the application since once pointers are involved this "simple" transform does not work. So in my view memory layout optimization has to happen like 1) identify an interesting set of memory objects (a memory allocation point or a variable declaration) 2) make sure you can see _all_ accesses to that object (because you'll need to modify them) 3) cost/benefit/transform decision 4) rewrite the allocation/declaration and the accesses previously identified see how types nowhere appear; they might in deriving a transform in 3), but that's for simplicity only. > Back to my original question about modifying the type, is rerunning > layout_type reasonable? If the layout changes then you'll have a problem unless you modify all accesses anyways in which case you don't need that. > I'm inspired by relayout_decl which clears a half a dozen or so fields > and then calls layout_decl. > > I appreciate your answers and comments, (*) There's the issue of debug information but IIRC that's unsolved for this kind of transforms anyway. > Gary
Re: compatibility of structs/unions/enums in the middle end
On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
wrote:
>
> Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
> > On October 2, 2019 3:55:43 PM GMT+02:00, "Uecker, Martin"
> >
> > wrote:
> > > Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
> > > > On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
> > > > wrote:
> > > > >
> ...
>
> > > > Oh, and LTO does _not_ merge types declared inside a function,
> > > > so
> > > >
> > > > void foo () { struct S { int i; }; }
> > > > void bar () { struct S { int i; }; }
> > > >
> > > > the two S are distinct and objects of that type do not conflict.
> > >
> > > This is surprising as these types are compatible across TUs. So
> > > if some pointer is passed between these functions this is
> > > supposed to work.
> >
> > So if they are compatible the frontend needs to mark them so in this case.
>
> It can't. The front end never sees the other TU.
If the type "leaves" the CU via a call the called function has a prototype
through which it "sees" the CU.
Richard.
> Best,
> Martin
Re: git conversion of GCC wwwdocs repository
Hi Joseph! On 2019-09-30T19:56:39+, Joseph Myers wrote: > As far as I can tell from the discussion, people are happy with the > version of the conversion using @gcc.gnu.org addresses. When shall we (do > a final conversion if there are any commits postdating that one and) > switch over to it as the live repository, set up hooks and update > documentation of editing the website? Given that nobody has raised any adverse opinions: can do that anytime now? Doing 'wwwdocs' before the sources repository conversion, we can use it as a testbed for hooks setup: commit/push hook obviously, but also Bugzilla integration, and fast-forward-only requirement for the 'master' branch, etc. Grüße Thomas signature.asc Description: PGP signature
