Re: Issue with a flag that I defined getting set to zero
On Fri, Jan 7, 2022 at 9:12 AM Gary Oblock via Gcc wrote: > > An optimization flag that I recently added is being > set to zero in push_cfun (which after a couple of > levels of calls cl_optimization_restore to this.) > > The flag defined like this: > > finterleaving-index-32-bits > Common Var(flag_interleaving_index_32_bits) Init(0) Optimization > Structure reorganization optimization, instance interleaving. > > Note, I'm working around this but l'd really like > to not have to do so therefore I'm wondering if somebody > could explain what's happening and what I'd need > to do instead? Did you rebuild all of GCC after adding the option? Note that when you look at the option from LTO and from within an IPA pass then you have to use opt_for_fn (..) since the "global" option at link time will be not set (unless you specify it again at link time), it will be only present on the functions of the compile TU it was set globally. > > Thanks, > > Gary > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
Re: Help with an ABI peculiarity
* Jeff Law via Gcc: > Most targets these days use registers for parameter passing and > obviously we can run out of registers on all of them. The key > property is the size/alignment of the argument differs depending on if > it's pass in a register (get promoted) or passed in memory (not > promoted). I'm not immediately aware of another ABI with that > feature. Though I haven't really gone looking. I think what AArch64 Darwin does is not compatible with a GCC extension that allows calling functions defined with a prototype without it (for pre-ISO-C compatibility). Given that, anyone defining an ABI in parallel with a GCC implementation probably has paused, reconsidered what they were doing, and adjusted the ABI for K&R compatibility. Thanks, Florian
Re: reordering of trapping operations and volatile
On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote:
>
> Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc
> > wrote:
> > >
> > > Hi Richard,
> > >
> > > I have a question regarding reodering of volatile
> > > accesses and trapping operations. My initial
> > > assumption (and hope) was that compilers take
> > > care to avoid creating traps that are incorrectly
> > > ordered relative to observable behavior.
> > >
> > > I had trouble finding examples, and my cursory
> > > glace at the code seemed to confirm that GCC
> > > carefully avoids this. But then someone showed
> > > me this example, where this can happen in GCC:
> > >
> > >
> > > volatile int x;
> > >
> > > int foo(int a, int b, _Bool store_to_x)
> > > {
> > > if (!store_to_x)
> > > return a / b;
> > > x = b;
> > > return a / b;
> > > }
> > >
> > >
> > > https://godbolt.org/z/vq3r8vjxr
> >
> > The question becomes what is a trapping instruction vs an undefined
> > instruction?
> > For floating point types, it is well defined what is a trapping
> > instruction while for integer types it is not well defined.
> > On some (many?) targets dividing by 0 is just undefined and does not
> > trap (powerpc, aarch64, arm and many others; MIPS it depends on the
> > options passed to GCC if the conditional trap should be inserted or
> > not).
>
> > The other side is if there is undefined code on the path, should
> > observable results happen first (stores to volatile/atomics, etc.)?
>
> I think for volatile stores and I/O, I think it would be
> nice of we could guarantee that those happen before the UB
> ruins the day. (I am not sure about atomics, those are
> not directly obsevable)
>
> For I/O this is probably already the case (?).
I/O usually happens through function calls where this is usually
already guaranteed as GCC doesn't know whether the function
will always return normally so the UB of a divide by zero might
be properly guarded.
> For volatile, it seems this would need some tweaks.
Yes, likewise when re-ordering (observable) traps like
r = a / b;
q = c / d;
> I am trying to figure out whether this is feasible.
For PRE yes, you'd just need to include the observable stmts you
care in the set of stmts that cause PRE to set BB_MAY_NOTRETURN.
In general this is of course harder.
> > GCC assumes by default that divide is trappable but stores not are not
> > observable. This is where -fnon-call-exceptions come into play.
>
> Ok, thanks! I will look at this!
>
> > In the second case, GCC assumes reducing trappable instructions are
> > fine.
>
> -fnon-call-exceptions would treat trapping instructions
> as defined (and trapping) instead of UB? This is
> then probably even stronger than the requirement above.
No, I don't think it turns UB into defined behavior. Some frontends might
expect that to some extent. So even with -fnon-call-exceptions we'd
happily do the re-ordering unless the exception is catched in the same
function.
> > Note I thought -fno-delete-dead-exceptions would fix the sink
> > but it didn't.
>
>
> Martin
>
>
Re: Help with an ABI peculiarity
Iain Sandoe writes: > Hi Folks, > > In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of > the calling convention. > > When an argument is passed *in a register* and it is integral and less than > SI it is promoted (with appropriate signedness) to SI. This applies when the > function parm is named only. > > When the same argument would be placed on the stack (i.e. we ran out of > registers) - it occupies its natural size, and is naturally aligned (so, for > instance, 3 QI values could be passed as 3 registers - promoted to SI .. or > packed into three adjacent bytes on the stack).. > > The key is that we need to know that the argument will be placed in a > register before we decide whether to promote it. > (similarly, the promotion is not done in the callee for the in-register case). > > I am trying to figure out where to implement this. > > * the code that (in regular cases) decides on such promotions is called > _before_ we call target’s function_arg. > > * OVERRIDE_ABI_FORMAT seems to be called too early (we don’t have enough > information on the function - to decide to set the PARM passed-as type). > > I’ve experimented with various schemes - specifically that tm.function_arg > can alter the mode of the register in the appropriate cases, and then calls.c > can act on the case that the mode has been changed by that callback. > > It seems probable that this approach can be made non-invasive - but... > ... if someone can point me at a better solution - I’m interested. I agree there doesn't seem to be an out-of-the-box way of doing this. I'm not sure about having two different ways of specifying promotion though. (For one thing, it should be possible to query promotion without generating “garbage” rtl.) An alternative might be to make promote_function_arg a “proper” ABI hook, taking a cumulative_args_t and a function_arg_info. Perhaps the return case should become a separate hook at the same time. That would probably require more extensive changes than just updating the call sites, and I haven't really checked how much work it would be, but hopefully it wouldn't be too bad. The new hook would still be called before function_arg, but that should no longer be a problem, since the new hook arguments would give the target the information it needs to decide whether the argument is passed in registers. Thanks, Richard
GCC 12.0.0 Status Report (2022-01-10), Stage 3 ends Jan 16th
Status == The GCC development branch is open for general bugfixing (Stage 3) and will transition to regression and documentation fixing only (Stage 4) on the end of Jan 16th. 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 30 - 4 P2 307 + 1 P3 279 + 42 P4 220 + 13 P5 25 --- --- Total P1-P3 616 + 39 Total 861 + 52 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-November/237741.html
GCC: Option -MF can not deal with long path name on Windows
Hello,
When below code is compiled with -MF option the Compilation failed when the
path of Windows is more than 256 characters. Do let me know if it is a
feature or a bug in GCC.
Test code in a.c:
int main()
{
int a = 100;
int b = 200;
return a+b;
}
Compilation:
gcc -M -MF
E:\ppc\issue\workspace\test1\test2\test3\test4\test5\test6\test7\test8\test9
\test10\test11\test12\test13\test14\test15\test16\test17\test18\test19\test2
0\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test
31\test32\test33\test34\test35\test36\test37\test38\test39\test40\test41\tes
t42\test43\a.d -c a.c
Error:
fatal error: opening dependency file
E:\ppc\issue\workspace\test1\test2\test3\test4\test5\test6\test7\test8\test9
\test10\test11\test12\test13\test14\test15\test16\test17\test18\test19\test2
0\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test
31\test32\test33\test34\test35\test36\test37\test38\test39\test40\test41\tes
t42\test43\a.d: No such file or directory
compilation terminated.
--
Thanks,
Sundeep K.
Re: Help with an ABI peculiarity
> On 10 Jan 2022, at 10:46, Richard Sandiford wrote: > > Iain Sandoe writes: >> Hi Folks, >> >> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature >> of the calling convention. >> >> When an argument is passed *in a register* and it is integral and less than >> SI it is promoted (with appropriate signedness) to SI. This applies when >> the function parm is named only. >> >> When the same argument would be placed on the stack (i.e. we ran out of >> registers) - it occupies its natural size, and is naturally aligned (so, for >> instance, 3 QI values could be passed as 3 registers - promoted to SI .. or >> packed into three adjacent bytes on the stack).. >> >> The key is that we need to know that the argument will be placed in a >> register before we decide whether to promote it. >> (similarly, the promotion is not done in the callee for the in-register >> case). >> >> I am trying to figure out where to implement this. >> >> * the code that (in regular cases) decides on such promotions is called >> _before_ we call target’s function_arg. >> >> * OVERRIDE_ABI_FORMAT seems to be called too early (we don’t have enough >> information on the function - to decide to set the PARM passed-as type). >> >> I’ve experimented with various schemes - specifically that tm.function_arg >> can alter the mode of the register in the appropriate cases, and then >> calls.c can act on the case that the mode has been changed by that callback. >> >> It seems probable that this approach can be made non-invasive - but... >> ... if someone can point me at a better solution - I’m interested. > > I agree there doesn't seem to be an out-of-the-box way of doing this. > I'm not sure about having two different ways of specifying promotion > though. (For one thing, it should be possible to query promotion > without generating “garbage” rtl.) In this case, it does not appear to be possible to do that without the cumulative args info .. so your next point is the logical design. > An alternative might be to make promote_function_arg a “proper” > ABI hook, taking a cumulative_args_t and a function_arg_info. > Perhaps the return case should become a separate hook at the > same time. > > That would probably require more extensive changes than just > updating the call sites, and I haven't really checked how much > work it would be, but hopefully it wouldn't be too bad. > > The new hook would still be called before function_arg, but that > should no longer be a problem, since the new hook arguments would > give the target the information it needs to decide whether the > argument is passed in registers. Yeah, this was my next port of call (I have looked at it ~10 times and then decided “not today, maybe there’s a simpler way”). thanks Iain
Re: Help with an ABI peculiarity
Hi Florian, > On 10 Jan 2022, at 08:38, Florian Weimer wrote: > > * Jeff Law via Gcc: > >> Most targets these days use registers for parameter passing and >> obviously we can run out of registers on all of them. The key >> property is the size/alignment of the argument differs depending on if >> it's pass in a register (get promoted) or passed in memory (not >> promoted). I'm not immediately aware of another ABI with that >> feature. Though I haven't really gone looking. > > I think what AArch64 Darwin does is not compatible with a GCC extension > that allows calling functions defined with a prototype without it (for > pre-ISO-C compatibility). AFAIU the implementation: In the case that a call is built and no prototype is available, the assumption is that all parms are named. The promotion is then done according to the C promotion rules. [for the number of args that can be passed in int regs] the callee will happen to observe the same rules in this case. It will, however, break once we overflow the number of int regs.. :/ The case that is fundamentally broken from scratch is of a variadic function called without a prototype - since the aarch64-darwin ABI places unnamed parms differently. So that the absence of a prototype causes us to place all args as if they were named. Wmissing-prototype Wstrict-prototypes would wisely be promoted to errors for this platform, (the ABI is obviously not up for change, since it’s already on millions of devices). > Given that, anyone defining an ABI in > parallel with a GCC implementation probably has paused, reconsidered > what they were doing, My guess is that this step was omitted - i.e. the port was designed in the LLVM framework. I can raise a query with the ABI owners, I guess. > and adjusted the ABI for K&R compatibility. FWIW, we bootstrap sucessfully including the K&R code in intl/ Given we have 8 int regs available, probably many calls will work .. As of now, I must assume that what is broken by the cases above will remain broken, and I just need to find a way to implement the cases that will work (i.e. when proper prototypes are available) thanks Iain
Re: Help with an ABI peculiarity
* Iain Sandoe: > In the case that a call is built and no prototype is available, the > assumption is that all parms are named. The promotion is then done > according to the C promotion rules. > > [for the number of args that can be passed in int regs] the callee > will happen to observe the same rules in this case. > > It will, however, break once we overflow the number of int regs.. :/ Exactly. > The case that is fundamentally broken from scratch is of a variadic function > called without a prototype - since the aarch64-darwin ABI places unnamed > parms differently. That part is true for powerpc64le as well, due to the caller-provided saved parameter area which only exists with variadic calls. This already happens in very simple cases, like the POSIX open function. The corruption is quite difficult to diagnose, too. 8-( But it's also quite rare to see such bugs. > Given we have 8 int regs available, probably many calls will work .. Oh, I didn't know that so many registers were available. Maybe that's enough to paper over the lack of ABI compatibility for now. Presumably you could count the number of arguments and emit a warning at least? C++ metaprogramming involving many parameters tends to use variadic templates of non-variadic functions, so that shouldn't be a problem. Thanks, Florian
Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)
Hi David, May I kindly ping you on that? Or anyone with knowledge of the static analyzer? Thanks, FX > Le 23 déc. 2021 à 22:49, FX a écrit : > > Hi David, hi everone, > > I’m trying to understand how best to fix or silence the several failures in > gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to > gcc-testresults, also occur on other non-Linux targets. See for example, the > test results at > https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html > > ## gcc.dg/analyzer/torture/asm-x86-linux-*.c > > Are these supposed to be run only on Linux (as the name implies)? Four of > them fail on x86_64-apple-darwin, because they use assembly that is not > supported: > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > > Should they be restricted to Linux targets? There is another one that has the > same error, as well, although it doesn’t have linux in the name: > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c > > > ## Builtin-related failures > > Those four cases fail: > > gcc.dg/analyzer/data-model-1.c > > gcc.dg/analyzer/pr103526.c > gcc.dg/analyzer/taint-size-1.c > gcc.dg/analyzer/write-to-string-literal-1.c > > but pass if the function calls (memset and memcpy) are replaced by the > built-in variant (__builtin_memset and __builtin_memcpy). The reason for that > is the darwin headers, in (included from ) does > this: > > #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) > #undef memcpy > /* void *memcpy(void *dst, const void *src, size_t n) */ > #define memcpy(dest, ...) \ >__builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 > (dest)) > #endif > > where __darwin_obsz0 is defined thusly: > > #define __darwin_obsz0(object) __builtin_object_size (object, 0) > > > Does the analyzer not handle the _chk builtin variants? Should it? > I’m happy to investigate more, but I’m not sure what to do. > > > Best, > FX
Re: reordering of trapping operations and volatile
Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
> On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote:
> > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc
> > > wrote:
> > > > Hi Richard,
> > > >
> > > > I have a question regarding reodering of volatile
> > > > accesses and trapping operations. My initial
> > > > assumption (and hope) was that compilers take
> > > > care to avoid creating traps that are incorrectly
> > > > ordered relative to observable behavior.
> > > >
> > > > I had trouble finding examples, and my cursory
> > > > glace at the code seemed to confirm that GCC
> > > > carefully avoids this. But then someone showed
> > > > me this example, where this can happen in GCC:
> > > >
> > > >
> > > > volatile int x;
> > > >
> > > > int foo(int a, int b, _Bool store_to_x)
> > > > {
> > > > if (!store_to_x)
> > > > return a / b;
> > > > x = b;
> > > > return a / b;
> > > > }
> > > >
> > > >
> > > > https://godbolt.org/z/vq3r8vjxr
> > >
> > > The question becomes what is a trapping instruction vs an undefined
> > > instruction?
> > > For floating point types, it is well defined what is a trapping
> > > instruction while for integer types it is not well defined.
> > > On some (many?) targets dividing by 0 is just undefined and does not
> > > trap (powerpc, aarch64, arm and many others; MIPS it depends on the
> > > options passed to GCC if the conditional trap should be inserted or
> > > not).
> > > The other side is if there is undefined code on the path, should
> > > observable results happen first (stores to volatile/atomics, etc.)?
> >
> > I think for volatile stores and I/O, I think it would be
> > nice of we could guarantee that those happen before the UB
> > ruins the day. (I am not sure about atomics, those are
> > not directly obsevable)
> >
> > For I/O this is probably already the case (?).
>
> I/O usually happens through function calls where this is usually
> already guaranteed as GCC doesn't know whether the function
> will always return normally so the UB of a divide by zero might
> be properly guarded.
Yes.
> > For volatile, it seems this would need some tweaks.
>
> Yes, likewise when re-ordering (observable) traps like
>
> r = a / b;
> q = c / d;
I think this could also be useful. But at the moment I am
concerned about the effect previous defined behavior
being affected. For this, reordering traps is OK. Also
sinking traps across observable behavior is OK. Just
hoisting it up across observable behavior would
be a problem.
> > I am trying to figure out whether this is feasible.
>
> For PRE yes, you'd just need to include the observable stmts you
> care in the set of stmts that cause PRE to set BB_MAY_NOTRETURN.
> In general this is of course harder.
What other passes would need to be checked?
And do you think there is any negative impact on
an important optimization (considering this affects
only volatile accesses)?
> > > GCC assumes by default that divide is trappable but stores not are not
> > > observable. This is where -fnon-call-exceptions come into play.
> >
> > Ok, thanks! I will look at this!
> >
> > > In the second case, GCC assumes reducing trappable instructions are
> > > fine.
> >
> > -fnon-call-exceptions would treat trapping instructions
> > as defined (and trapping) instead of UB? This is
> > then probably even stronger than the requirement above.
>
> No, I don't think it turns UB into defined behavior. Some frontends might
> expect that to some extent. So even with -fnon-call-exceptions we'd
> happily do the re-ordering unless the exception is catched in the same
> function.
Thanks,
Martin
> > > Note I thought -fno-delete-dead-exceptions would fix the sink
> > > but it didn't.
> >
> > Martin
> >
> >
Re: Issue with a flag that I defined getting set to zero
Richard, That's nice to know but I added the option itself months ago. Also, it's on the lto1 command line, cc1 command line and shows up in the COLLECT_GCC_OPTIONS so I assume it universally applied. Thanks, Gary From: Richard Biener Sent: Monday, January 10, 2022 12:36 AM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: Issue with a flag that I defined getting set to zero [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] On Fri, Jan 7, 2022 at 9:12 AM Gary Oblock via Gcc wrote: > > An optimization flag that I recently added is being > set to zero in push_cfun (which after a couple of > levels of calls cl_optimization_restore to this.) > > The flag defined like this: > > finterleaving-index-32-bits > Common Var(flag_interleaving_index_32_bits) Init(0) Optimization > Structure reorganization optimization, instance interleaving. > > Note, I'm working around this but l'd really like > to not have to do so therefore I'm wondering if somebody > could explain what's happening and what I'd need > to do instead? Did you rebuild all of GCC after adding the option? Note that when you look at the option from LTO and from within an IPA pass then you have to use opt_for_fn (..) since the "global" option at link time will be not set (unless you specify it again at link time), it will be only present on the functions of the compile TU it was set globally. > > Thanks, > > Gary > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)
On Mon, 2022-01-10 at 17:13 +0100, FX wrote: > Hi David, > > May I kindly ping you on that? Or anyone with knowledge of the static > analyzer? Sorry about the delay in responding; I was on vacation and am still getting caught up. Various answers inline below... > > Thanks, > FX > > > > Le 23 déc. 2021 à 22:49, FX a écrit : > > > > Hi David, hi everone, > > > > I’m trying to understand how best to fix or silence the several > > failures in gcc.dg/analyzer that occur on x86_64-apple-darwin. Some > > of them, according to gcc-testresults, also occur on other non- > > Linux targets. See for example, the test results at > > https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html > > > > ## gcc.dg/analyzer/torture/asm-x86-linux-*.c > > > > Are these supposed to be run only on Linux (as the name implies)? > > Four of them fail on x86_64-apple-darwin, because they use assembly > > that is not supported: > > > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout- > > full.c > > > > Should they be restricted to Linux targets? There is another one > > that has the same error, as well, although it doesn’t have linux in > > the name: > > > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c The purpose of these asm tests is to verify that the analyzer doesn't get confused by various inline assembler directives used in the source of the Linux kernel. So in theory they ought to work on any host, with a gcc configured for a suitable target. These tests are marked with "dg-do assemble" directives, which I'd hoped would mean it uses -S for the tests (to make a .s file), but looking at a log locally, it appears to be using -c (to make a .o file), so maybe that's what's going wrong for you as well? > > > > > > ## Builtin-related failures > > > > Those four cases fail: > > > > gcc.dg/analyzer/data-model-1.c > > > > gcc.dg/analyzer/pr103526.c > > gcc.dg/analyzer/taint-size-1.c > > gcc.dg/analyzer/write-to-string-literal-1.c > > > > but pass if the function calls (memset and memcpy) are replaced by > > the built-in variant (__builtin_memset and __builtin_memcpy). The > > reason for that is the darwin headers, in > > (included from ) does this: > > > > #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) > > #undef memcpy > > /* void *memcpy(void *dst, const void *src, size_t n) */ > > #define memcpy(dest, ...) \ > > __builtin___memcpy_chk (dest, __VA_ARGS__, > > __darwin_obsz0 (dest)) > > #endif > > > > where __darwin_obsz0 is defined thusly: > > > > #define __darwin_obsz0(object) __builtin_object_size (object, 0) > > > > > > Does the analyzer not handle the _chk builtin variants? Should it? > > I’m happy to investigate more, but I’m not sure what to do. Can you file a bug about this and attach the preprocessed source from the test (using -E). Thanks Dave
Re: What's wrong with this RTL?
On Sun, 2022-01-09 at 22:19 -0800, Andrew Pinski wrote:
> On Sun, Jan 9, 2022 at 8:49 PM Andras Tantos > wrote:
> > All!
> >
> > I'm trying to port GCC to a new target, I call 'brew'. I've based
> > it on
> > the Moxie target mostly because of it's simplicity.
> >
> > I must be doing something horribly wrong as the following C code
> > crokes
> > in the LRA path:
> >
> >long long foo (long long a, long long *w)
> >{
> > return __builtin_add_overflow (a, a, w);
> >}
> >
> > The error message I get is the following:
> >
> >during RTL pass: reload
> >../brew-gcc-build/second.c: In function ‘foo’:
> >../brew-gcc-build/second.c:5:1: internal compiler error: maximum
> >number of generated reload insns per insn achieved (90)
> >5 | }
> > | ^
> >0xd23854 lra_constraints(bool)
> > ../../brew-gcc/gcc/lra-constraints.c:5095
> >0xd10322 lra(_IO_FILE*)
> > ../../brew-gcc/gcc/lra.c:2336
> >0xcc86d9 do_reload
> > ../../brew-gcc/gcc/ira.c:5932
> >0xcc86d9 execute
> > ../../brew-gcc/gcc/ira.c:6118
> >Please submit a full bug report,
> >with preprocessed source if appropriate.
> >Please include the complete backtrace with any bug report.
> >See
GSoC: Working on the static analyzer
Hi everyone, I intend to work on the static analyzer. Are these documents enough to get started: https://gcc.gnu.org/onlinedocs/gccint and https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals . Thank you.
Re: reordering of trapping operations and volatile
On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
>
> Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
> > On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc
> > wrote:
> > > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc
> > > > wrote:
> > > > > Hi Richard,
> > > > >
> > > > > I have a question regarding reodering of volatile
> > > > > accesses and trapping operations. My initial
> > > > > assumption (and hope) was that compilers take
> > > > > care to avoid creating traps that are incorrectly
> > > > > ordered relative to observable behavior.
> > > > >
> > > > > I had trouble finding examples, and my cursory
> > > > > glace at the code seemed to confirm that GCC
> > > > > carefully avoids this. But then someone showed
> > > > > me this example, where this can happen in GCC:
> > > > >
> > > > >
> > > > > volatile int x;
> > > > >
> > > > > int foo(int a, int b, _Bool store_to_x)
> > > > > {
> > > > > if (!store_to_x)
> > > > > return a / b;
> > > > > x = b;
> > > > > return a / b;
> > > > > }
> > > > >
> > > > >
> > > > > https://godbolt.org/z/vq3r8vjxr
> > > >
> > > > The question becomes what is a trapping instruction vs an undefined
> > > > instruction?
> > > > For floating point types, it is well defined what is a trapping
> > > > instruction while for integer types it is not well defined.
> > > > On some (many?) targets dividing by 0 is just undefined and does not
> > > > trap (powerpc, aarch64, arm and many others; MIPS it depends on the
> > > > options passed to GCC if the conditional trap should be inserted or
> > > > not).
> > > > The other side is if there is undefined code on the path, should
> > > > observable results happen first (stores to volatile/atomics, etc.)?
> > >
> > > I think for volatile stores and I/O, I think it would be
> > > nice of we could guarantee that those happen before the UB
> > > ruins the day. (I am not sure about atomics, those are
> > > not directly obsevable)
> > >
> > > For I/O this is probably already the case (?).
> >
> > I/O usually happens through function calls where this is usually
> > already guaranteed as GCC doesn't know whether the function
> > will always return normally so the UB of a divide by zero might
> > be properly guarded.
>
> Yes.
>
> > > For volatile, it seems this would need some tweaks.
> >
> > Yes, likewise when re-ordering (observable) traps like
> >
> > r = a / b;
> > q = c / d;
>
> I think this could also be useful. But at the moment I am
> concerned about the effect previous defined behavior
> being affected. For this, reordering traps is OK. Also
> sinking traps across observable behavior is OK. Just
> hoisting it up across observable behavior would
> be a problem.
But in general that would apply to all UB. Consider
int foo (int a, int b)
{
if (a < b)
return a + b;
bar ();
return a + b;
}
we are happily hoisting a + b to the start of the function
but of course a + b can invoke UB. We consider that to
not matter because we eventually invoke this UB anyway.
Unless of course bar() does not return.
I realize that UB in a + b isn't (usually) observable but
UB resulting in traps are.
So I'm still wondering why you think that 'volatile' makes
a critical difference we ought to honor? I don't remember
'volatile' being special in the definition of the abstract
machine with regarding to observability (as opposed to
sequence points).
> > > I am trying to figure out whether this is feasible.
> >
> > For PRE yes, you'd just need to include the observable stmts you
> > care in the set of stmts that cause PRE to set BB_MAY_NOTRETURN.
> > In general this is of course harder.
>
> What other passes would need to be checked?
All that do code motion by design or by accident. The difficulty is
that the resulting "wrong IL" is not wrong per se, just the difference is
which is hard to write a checker for (well, in priciple you could copy the
IL before passes and compare to the IL after)
> And do you think there is any negative impact on
> an important optimization (considering this affects
> only volatile accesses)?
Probably not. But then semantics of 'volatile' are very weak defined
so I'd like
to see a reference to a part of the standard that supports declaring this
(and only this - the 'volatile' case) a bug.
> > > > GCC assumes by default that divide is trappable but stores not are not
> > > > observable. This is where -fnon-call-exceptions come into play.
> > >
> > > Ok, thanks! I will look at this!
> > >
> > > > In the second case, GCC assumes reducing trappable instructions are
> > > > fine.
> > >
> > > -fnon-call-exceptions would treat trapping instructions
> > > as defined (and trapping) instead of UB? This is
> > > then probably even stronger than the requirement above.
> >
> > No, I don't think it turns UB into defined behavior. Some frontends might
> > expect that to some extent. So even with -fnon-c
