GCC 12.0.0 Status Report (2021-10-01), Stage 3 to start Nov 15th
Status == The GCC development branch is open for general development (Stage 1), but the two-month general bugfixing period (Stage 3) is ahead with historical data telling us to expect it to start Nov 15th and last through the Christmas holidays. Take the quality data below with a big grain of salt - most of the new P3 classified bugs will become P1 or P2 (generally every regression against GCC 11 is to be considered P1 if it concerns primary or secondary platforms). Quality Data Priority # Change from last report --- --- P1 15 + 15 P2 282 + 33 P3 193 + 159 P4 202 + 2 P5 25 + 1 --- --- Total P1-P3 490 + 207 Total 717 + 209 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-April/235831.html
Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.
> On 29 Sep 2021, at 21:21, Andrew MacLeod wrote: > > On 9/29/21 7:59 AM, Maxim Kuvyrkov wrote: >> >>> Does it run like once a day/some-time-period, and if you note a >>> regression, narrow it down? >> Configurations that track master branches have 3-day intervals. >> Configurations that track release branches — 6 days. If a regression is >> detected it is narrowed down to component first — binutils, gcc or glibc — >> and then the commit range of the component is bisected down to a specific >> commit. All. Done. Automatically. >> >> I will make a presentation on this CI at the next GNU Tools Cauldron. >> >>> Regardless, I think it could be very useful to be able to see the results >>> of anything you do run at whatever frequency it happens. >> Thanks! >> >> -- > > One more follow on question.. is this information/summary of the results > every 3rd day interval of master published anywhere? ie, to a web page or > posted somewhere?that seems like it could useful, especially with a +/- > differential from the previous run (which you obviously calculate to > determine if there is a regression). It’s our next big improvement — to provide a dashboard with current performance numbers and historical stats. Performance summary information is publicly available as artifacts in jenkins jobs (e.g., [1]), but one needs to know exactly where to look. We plan to implement the dashboard before the end of the year. We also have raw perf.data files and benchmark executables stashed for detailed inspection. I /think/, we can publish these for SPEC CPU2xxx benchmarks — they are all based on open-source software. For other benchmarks (EEMBC, CoreMark Pro) we can’t publish much beyond time/size metrics. [1] https://ci.linaro.org/view/tcwg_bmk_ci_gnu/job/tcwg_bmk_ci_gnu-build-tcwg_bmk_tx1-gnu-master-aarch64-spec2k6-O2/237/artifact/artifacts/11-check_regression/results.csv/*view*/ Regards, -- Maxim Kuvyrkov https://www.linaro.org
Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.
On Wed, 29 Sep 2021, Maxim Kuvyrkov via Gcc wrote: > Configurations that track master branches have 3-day intervals. > Configurations that track release branches — 6 days. If a regression is > detected it is narrowed down to component first — binutils, gcc or glibc > — and then the commit range of the component is bisected down to a > specific commit. All. Done. Automatically. > > I will make a presentation on this CI at the next GNU Tools Cauldron. Yes, please! :-) On Fri, 1 Oct 2021, Maxim Kuvyrkov via Gcc wrote: > It’s our next big improvement — to provide a dashboard with current > performance numbers and historical stats. Awesome. And then we can even link from gcc.gnu.org. Gerald
Re: replacing the VRP threader
On Wed, 22 Sep 2021, Aldy Hernandez via Gcc wrote: > Well, it turns out we're considerably better than reported. > > Andrew just found a one-line change in the path solver that improves > our VRP threading goodness to 18.5% and our overall jump threading > gains to 1.28%. Would that make a great news item, gcc-12/changes.html for sure, maybe even our home page (possibly with a subpage under projects/ like in the old days)? Gerald
TYPE_NEEDS_CONSTRUCTING zero for std::string?
I'd expect TYPE_NEEDS_CONSTRUCTING to be non-zero in the middle end for any C++ type with a user-defined ctor, but in some of my testing I see it's actually zero for std::string, at least in some instances (but nonzero for other types with ctors). Is there something special about std::string that makes it so? (If this is intentional, how can I create my own type that has a user-defined ctor and also a zero TYPE_NEEDS_CONSTRUCTING?) Thanks Martin
GCC LM32 bug: reordering instructions in stack
Hello.
Firstly I want to apologize for this long post, but in a way this post also
is meant for documenting the work that I have done hunting down this issue.
Secondly I must say that I do not have much insights on the GCC internals,
only the basic stuff. I know what a function prologue and epilogue is, but
I am not able to read GIMPLE or RTL for instance...
So I have a C function that basically starts this way (after CPP
pre-processing):
void e_printf( const charptr ctrl1, ...){
int long_flag;
int dot_flag;
int skip_switch;
params_t par;
char ch;
va_list argp;
charptr ctrl = ctrl1;
__builtin_va_start(argp,ctrl1);
for ( ; *ctrl; ctrl++) {
()
This C code function when compiled with the GCC version currently in git
trunk, compiled for target lm32-elf, generates the following assembly code:
(...)
.global e_printf
.type e_printf, @function
e_printf:
addi sp, sp, -116
sw (sp+56), r11
sw (sp+52), r12
sw (sp+48), r13
sw (sp+44), r14
sw (sp+40), r15
sw (sp+36), r16
sw (sp+32), r17
sw (sp+28), r18
sw (sp+24), r19
sw (sp+20), r20
sw (sp+16), r21
sw (sp+12), r22
sw (sp+8), r23
sw (sp+4), ra
lw r9, (sp+88)
sw (sp+92), r2
sw (sp+88), r1
lbu r1, (r9+0)
sw (sp+96), r3
sw (sp+100), r4
sw (sp+104), r5
sw (sp+108), r6
sw (sp+112), r7
sw (sp+116), r8
sw (sp+60), r9
be r1,r0,.L1
(...)
Now this code in part is suboptimal because all 'pushed registers' from r2
to r8 to the stack are never "poped" back but that is not the issue I am
referring.
Assuming that the "const charptr ctrl1" is passed to the function in
register r1, the following sequence is obviously wrong (the "sw
(sp+88), r1" instruction should appear first in this small sequence of
instructions for this snip of code to be correct):
lw r9, (sp+88)
sw (sp+92), r2
sw (sp+88), r1
lbu r1, (r9+0)
Something went horrible wrong in this reordering instructions in the stack.
So, I compiled about a dozen of GCC released versions and determined that
GCC 4.9.2 was the last version where this code was compiled into assembly
correctly and GCC 5.1.0 is the first one containing erroneous generated
assembly. All versions tested after GCC 5.1.0 all generated the same above
assembly erroneous code. I should also mention that GCC 4.9.4 also
generates assembly code correctly, but it seems that GCC 5.1.0 evolved from
GCC 4.9.2...
The correct assembly code is the following (although suboptimal, but not
the issue I am reporting):
.global e_printf
.type e_printf, @function
e_printf:
addi sp, sp, -124
sw (sp+64), r11
sw (sp+60), r12
sw (sp+56), r13
sw (sp+52), r14
sw (sp+48), r15
sw (sp+44), r16
sw (sp+40), r17
sw (sp+36), r18
sw (sp+32), r19
sw (sp+28), r20
sw (sp+24), r21
sw (sp+20), r22
sw (sp+16), r23
sw (sp+12), r24
sw (sp+8), r25
sw (sp+4), ra
lbu r9, (r1+0)
sw (sp+96), r1
sw (sp+100), r2
sw (sp+104), r3
sw (sp+108), r4
sw (sp+112), r5
sw (sp+116), r6
sw (sp+120), r7
sw (sp+124), r8
sw (sp+68), r1
be r9,r0,.L1
I then cloned GCC git repository and run a "git bisect" command. Something
in the lines of:
git bisect start
git bisect bad 659e39f1bcb277ddcc701b9ed7d41776ab8b4214
git bisect good 5fbb36f4a4e85956c241dafe603f1fc1be10472e
git bisect run ../test/git_bisect_testscript.sh
I determined that commit d5e254e19c59fcc49265dda64007690af08b6e28 from Nov
5th 2014 was the first commit where GCC compiled for target lm32-elf
started to emit the wrong sequence of instructions.
This commit has a huge amount of changes, but I was able to pinpoint that
erasing the following code:
assign_parm_adjust_stack_rtl (&data);
if (assign_parm_setup_block_p (&data))
assign_parm_setup_block (&all, parm, &data);
else if (data.passed_pointer || use_register_for_decl (parm))
assign_parm_setup_reg (&all, parm, &data);
else
assign_parm_setup_stack (&all, parm, &data);
from the gcc/functions.c file around line 3670 was the major culprit for
the generation of erroneous sequence of instructions.
Meanwhile this piece of code was at some point in time reinstated to
gcc/functions.c file but instead of 'data.passed_pointer' there is now a
'data.arg.pass_by_reference'. The struct data does not have a
passed_pointer field anymore and operations that were dependent of that
struct field were deleted from the gcc/functions.c file, so I cannot
simply add that condition back and see what happens.
I understand that most likely there is a bug in the backed port of lm32,
and not in the common code of GCC, but there have been no updates to the
lm32 port (besides maintenance ones), and as I mentioned I do not have much
knowledge of GCC internals, so my focus was more identifying which change
led to this erroneou
Re: TYPE_NEEDS_CONSTRUCTING zero for std::string?
* Martin Sebor via Gcc: > I'd expect TYPE_NEEDS_CONSTRUCTING to be non-zero in the middle end > for any C++ type with a user-defined ctor, but in some of my testing > I see it's actually zero for std::string, at least in some instances > (but nonzero for other types with ctors). Is there something special > about std::string that makes it so? (If this is intentional, how can > I create my own type that has a user-defined ctor and also a zero > TYPE_NEEDS_CONSTRUCTING?) I assume by writing an explicit default constructor: T() = default; Thanks, Florian
Re: Can gcc itself be tested with ubsan? If so, how?
I suppose I should answer my own question Yes, the final compiler built has ubsan enabled. Gary PS. The faint hearted should note this is an overnight build. It would be nice if this wasn't tied to building a bootstrap compiler. From: Gary Oblock Sent: Wednesday, September 29, 2021 11:55 AM To: Toon Moene ; Erick Ochoa Cc: gcc@gcc.gnu.org Subject: Re: Can gcc itself be tested with ubsan? If so, how? Toon, I assume the final compiler built this way has ubsan? I ask because I'm trying to spot a bug in a new optimization so I want to run it on a specific test case with the new optimization enabled. Thanks, Gary From: Toon Moene Sent: Monday, September 27, 2021 11:47 PM To: Erick Ochoa ; Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: Can gcc itself be tested with ubsan? If so, how? [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote: >> Can ubsan be used on the compiler itself? I regularly build the compiler(s) natively with ubsan enabled, see for instance: https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html The configure line tells you how to do it (towards the end of the mail): configure flags: --prefix=/home/toon/compilers/install/gcc --with-gnu-as --with-gnu-ld --enable-languages=all,ada --disable-multilib --disable-nls --with-build-config=bootstrap-ubsan --enable-checking=all (the enable-checking part is not relevant, and can be omitted). Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: TYPE_NEEDS_CONSTRUCTING zero for std::string?
On 10/1/21 11:44 AM, Florian Weimer wrote: * Martin Sebor via Gcc: I'd expect TYPE_NEEDS_CONSTRUCTING to be non-zero in the middle end for any C++ type with a user-defined ctor, but in some of my testing I see it's actually zero for std::string, at least in some instances (but nonzero for other types with ctors). Is there something special about std::string that makes it so? (If this is intentional, how can I create my own type that has a user-defined ctor and also a zero TYPE_NEEDS_CONSTRUCTING?) I assume by writing an explicit default constructor: T() = default; Yes, but in a class that also defines (non-defaulted) ctors TYPE_NEEDS_CONSTRUCTING() is nonzero. I'm looking for a type that defines a ctor (the above just declares one) that has a zero for TYPE_NEEDS_CONSTRUCTING(T). GCC documents the macro as: /* Indicates that objects of this type must be initialized by calling a function when they are created. */ So assuming TYPE_NEEDS_CONSTRUCTING(std::string) is supposed to return zero (i.e., it's not a bug or some oddity I'm seeing) I want to know how to define a class like it, with one or more user-defined ctors, for which TYPE_NEEDS_CONSTRUCTING() also returns zero. Otherwise, if it's a bug, I'll see if I can come up with a test case for it. Martin
gcc-10-20211001 is now available
Snapshot gcc-10-20211001 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20211001/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 3bc634079e6b141de0e6de3577584ebbd82ec0b9 You'll find: gcc-10-20211001.tar.xz Complete GCC SHA256=b79bd04715e08ca76625b6a20b0537bc3543316364b2976d6cd370ce57b55b1e SHA1=84659cb0fce1d63d9c377d5b77e05f73eb957a2c Diffs from 10-20210924 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 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.
