Re: reordering of trapping operations and volatile
Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
Hi Richard,
> > > > 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.
Yes.
> I realize that UB in a + b isn't (usually) observable but
> UB resulting in traps are.
Code motion for UB which then does not cause
a change in observable behavior would still be ok.
So my understanding is that you can not hoist a potentially
trapping operation across a function call, but if it is
UB which is implemented in way that just produces some
random result but does not trap then this is ok.
It would also be wrong if it affects the arguments for
the function call. Here MSVC seems to do this:
https://godbolt.org/z/8a8fTW8qP
This seems incorect because if the call does not
return there is no UB. I did not observe this with
GCC or another compiler.
> 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).
It is because it is used for I/O. Sequence points only
matter for the semantics of the abstract machine, so
according to "as-if" rule optimizers can do whatever
they want as long as the observable behavior is the same
"as-if" it followed the rules of the abstract machine.
This observable behavior that needs to be preserved is
defined as I/O and volatile accesses. The relevant
part o the standard is this:
"5.1.2.3 Program execution" paragraph 6
The least requirements on a conforming implementation are:
— Accesses to volatile objects are evaluated strictly
according to the rules of the abstract machine.
— At program termination, all data written into files
shall be identical to the result that execution
of the program according to the abstract semantics would
have produced.
— The input and output dynamics of interactive devices
shall take place as specified in 7.21.3.
The intent of these requirements is that unbuffered or
line-buffered output appear as soon as possible, to
ensure that prompting messages actually appear prior
to a program waiting for input.
This is the observable behavior of the program."
Martin
> > > > 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-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: reordering of trapping operations and volatile
On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote:
>
> Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
>
> Hi Richard,
>
> > > > > 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.
>
> Yes.
>
> > I realize that UB in a + b isn't (usually) observable but
> > UB resulting in traps are.
>
> Code motion for UB which then does not cause
> a change in observable behavior would still be ok.
>
> So my understanding is that you can not hoist a potentially
> trapping operation across a function call, but if it is
> UB which is implemented in way that just produces some
> random result but does not trap then this is ok.
>
> It would also be wrong if it affects the arguments for
> the function call. Here MSVC seems to do this:
>
> https://godbolt.org/z/8a8fTW8qP
>
> This seems incorect because if the call does not
> return there is no UB. I did not observe this with
> GCC or another compiler.
>
> > 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).
>
> It is because it is used for I/O. Sequence points only
> matter for the semantics of the abstract machine, so
> according to "as-if" rule optimizers can do whatever
> they want as long as the observable behavior is the same
> "as-if" it followed the rules of the abstract machine.
>
> This observable behavior that needs to be preserved is
> defined as I/O and volatile accesses. The relevant
> part o the standard is this:
>
> "5.1.2.3 Program execution" paragraph 6
>
> The least requirements on a conforming implementation are:
>
> — Accesses to volatile objects are evaluated strictly
> according to the rules of the abstract machine.
> — At program termination, all data written into files
> shall be identical to the result that execution
> of the program according to the abstract semantics would
> have produced.
> — The input and output dynamics of interactive devices
> shall take place as specified in 7.21.3.
>
> The intent of these requirements is that unbuffered or
> line-buffered output appear as soon as possible, to
> ensure that prompting messages actually appear prior
> to a program waiting for input.
>
> This is the observable behavior of the program."
OK, I think that 'volatile is used for I/O' is a common misconception,
but well. Consider
int a[1024];
void foo (volatile int *p, float *q)
{
for (int i = 0; i < 1024; ++i)
{
*p = 1;
a[i] = *q;
}
}
we happily apply invariant motion to the load from *q, making
it cross the store to the volatile object at *p. Now, q might be
NULL upon entry to the function and thus this transform
would violate the volatile "I/O" constraint (since I/O is observable)
and thus we will crash (which is UB) before doing the first I/O.
That's an example I'd consider important for performance and
also a case that shows that usually the compiler will have a
very hard time proving UB cannot happen (as opposed to the
usual stance where it can assume it doesn't).
The case we run into sth similar is with use of uninitialized
variables where proving some variable is initialized is nearly
impossible (copy initialization from a variable that is not
initialized is not initialization).
We've mainly settled to the stance that only program termination
is observable which means if we do not know that a function
call will always return normally we have to avoid hoisting
observable UB across such function call (and I/O routines
usually fall into this category because they are not annotated
as always returning). Handling all volatile accesses in the
very same way would be possible but quite some work I don't
see much value in.
Richard.
>
>
> Martin
>
> > > > > 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
Re: Help with an ABI peculiarity
On 10/01/2022 08:38, Florian Weimer via Gcc 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). 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 Not having a prototype was deprecated in C89. One would hope that after 33 years we could move on from that. R.
GCC and OpenACC
Dear GCC developers, In the past year we started the offload of our software to GPUs. We decided to go with OpenACC. The program we are trying to offload is Millepede2 (MP2), a tracker alignment software used to align the CMS experiment tracker at the large hadron collider. We are using gcc as our main compiler. However, we found a major inconvenience with OpenACC 2.6, the REDUCTION clause does not accept arrays. Thus, it not possible for us to parallelise our largest loops due to array dependencies. We managed to offload MP2 for small datasets, we worked around the reduction issue. Nonetheless, if our alignment campaign is large the workarounds are not useful anymore. I went thought the new versions of OpenACC and I found that v2.7 accepts arrays for the REDUCTION clause. I was wondering if it is in your plans to include a newer version of OpenACC for the next releases. Sincerely, Mikel Mendizabal
Re: Help with an ABI peculiarity
On Mon, Jan 10, 2022 at 8:28 AM Iain Sandoe wrote: > > 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, Relevant bugs in this area: 82922, add -Wstrict-prototypes to -Wextra: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 91092, Error on implicit function declarations by default: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092 (and the related bugs in the "See Also", "Depends On", "Duplicates", etc. fields for each of them) > > (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 >
[PATCH] Mass rename of C++ .c files to .cc suffix
Hello.
I've got a patch series that does the renaming. It contains of 2 automatic
scripts ([1] and [2]) that were run as:
$ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' &&
rename-gcc.py . -vv && git commit -a -m 'Automatic renaming'
The first scripts does the renaming (with a couple of exceptions that are
really C files) and saves
the renamed files to a file. Then the file is then loaded and replacement of
all the renamed files does happen
for most of the GCC files ([2]). It basically replaces at \b${old_filename}\b
with ${old_filename}c
(with some exceptions). That corresponds to patch #1 and #2 and the patches are
quite huge.
The last piece are manual changes needed for Makefile.in, configure.ac and so
on.
The git branch can be seen here:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming
and pulled with:
$ git fetch refs/users/marxin/heads/cc-renaming
$ git co FETCH_HEAD
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu
and I've built all cross compilers.
Thoughts?
Martin
[1] https://github.com/marxin/script-misc/blob/master/gcc-renaming-candidates.py
[2] https://github.com/marxin/script-misc/blob/master/rename-gcc.pyFrom 65bb0c6b03ed394669471befe54482858d982ee2 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 10 Jan 2022 11:46:58 +0100
Subject: [PATCH 3/3] Manual changes for .cc renaming.
gcc/ChangeLog:
* Makefile.in: Rename .c names to .cc.
* config.gcc: Likewise.
* configure: Regenerate. Likewise.
* configure.ac: Likewise.
* gengtype.cc (set_gc_used): Likewise.
(source_dot_c_frul): Likewise.
(source_dot_cc_frul): Likewise.
(struct file_rule_st): Likewise.
(close_output_files): Likewise.
gcc/ada/ChangeLog:
* Makefile.rtl: Rename .c names to .cc.
* gcc-interface/Make-lang.in: Likewise.
* gcc-interface/Makefile.in: Likewise.
libgcc/ChangeLog:
* libgcov-driver.c: Rename .c names to .cc.
---
gcc/Makefile.in| 46 +++---
gcc/ada/Makefile.rtl | 8 +++---
gcc/ada/gcc-interface/Make-lang.in | 6 ++--
gcc/ada/gcc-interface/Makefile.in | 6
gcc/config.gcc | 2 +-
gcc/configure | 37 ++--
gcc/configure.ac | 6 ++--
gcc/gengtype.cc| 30 ---
libgcc/libgcov-driver.c| 2 +-
9 files changed, 81 insertions(+), 62 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e13bf66b040..31ff95500c9 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1784,7 +1784,7 @@ MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \
gcc-ranlib$(exeext) \
genversion$(build_exeext) gcov$(exeext) gcov-dump$(exeext) \
gcov-tool$(exeect) \
- gengtype$(exeext) *.[0-9][0-9].* *.[si] *-checksum.c libbackend.a \
+ gengtype$(exeext) *.[0-9][0-9].* *.[si] *-checksum.cc libbackend.a \
libcommon-target.a libcommon.a libgcc.mk perf.data
# This symlink makes the full installation name of the driver be available
@@ -2421,10 +2421,10 @@ simple_generated_h = $(simple_rtl_generated_h) insn-constants.h
simple_generated_c = $(simple_rtl_generated_c) insn-enums.cc
$(simple_generated_h:insn-%.h=s-%) \
-$(simple_generated_c:insn-%.c=s-%): s-%: $(MD_DEPS)
+$(simple_generated_c:insn-%.cc=s-%): s-%: $(MD_DEPS)
$(simple_rtl_generated_h:insn-%.h=s-%) \
-$(simple_rtl_generated_c:insn-%.c=s-%): s-%: insn-conditions.md
+$(simple_rtl_generated_c:insn-%.cc=s-%): s-%: insn-conditions.md
$(simple_generated_h): insn-%.h: s-%; @true
@@ -2434,11 +2434,11 @@ $(simple_generated_h:insn-%.h=s-%): s-%: build/gen%$(build_exeext)
$(SHELL) $(srcdir)/../move-if-change tmp-$*.h insn-$*.h
$(STAMP) s-$*
-$(simple_generated_c): insn-%.c: s-%; @true
-$(simple_generated_c:insn-%.c=s-%): s-%: build/gen%$(build_exeext)
+$(simple_generated_c): insn-%.cc: s-%; @true
+$(simple_generated_c:insn-%.cc=s-%): s-%: build/gen%$(build_exeext)
$(RUN_GEN) build/gen$*$(build_exeext) $(md_file) \
- $(filter insn-conditions.md,$^) > tmp-$*.c
- $(SHELL) $(srcdir)/../move-if-change tmp-$*.c insn-$*.c
+ $(filter insn-conditions.md,$^) > tmp-$*.cc
+ $(SHELL) $(srcdir)/../move-if-change tmp-$*.cc insn-$*.cc
$(STAMP) s-$*
# gencheck doesn't read the machine description, and the file produced
@@ -2449,12 +2449,12 @@ s-check : build/gencheck$(build_exeext)
$(SHELL) $(srcdir)/../move-if-change tmp-check.h tree-check.h
$(STAMP) s-check
-# genattrtab produces three files: tmp-{attrtab.c,dfatab.c,latencytab.c}
+# genattrtab produces three files: tmp-{attrtab.cc,dfatab.cc,latencytab.cc}
insn-attrtab.cc insn-dfatab.cc insn-latencytab.cc: s-attrtab ; @true
s-attrtab : $(MD_DEPS) build/genattrtab$(build_exeext) \
insn-conditions.md
$(RUN_GEN) build/genattrtab$(build_exeext) $(md_file) insn-conditions.md \
- -Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-laten
Re: GCC and OpenACC
On Tue, Jan 11, 2022 at 1:52 PM Mikel Mendizabal via Gcc wrote: > > Dear GCC developers, > > In the past year we started the offload of our software to GPUs. We decided > to go with OpenACC. The program we are trying to offload is Millepede2 (MP2), > a tracker alignment software used to align the CMS experiment tracker at the > large hadron collider. > > We are using gcc as our main compiler. However, we found a major > inconvenience with OpenACC 2.6, the REDUCTION clause does not accept arrays. > Thus, it not possible for us to parallelise our largest loops due to array > dependencies. We managed to offload MP2 for small datasets, we worked around > the reduction issue. Nonetheless, if our alignment campaign is large the > workarounds are not useful anymore. > > I went thought the new versions of OpenACC and I found that v2.7 accepts > arrays for the REDUCTION clause. I was wondering if it is in your plans to > include a newer version of OpenACC for the next releases. Can you produce a self-contained example with an array for the REDUCTION clause that should be accepted with OpenACC v2.7? Thanks, Richard. > Sincerely, > Mikel Mendizabal
Re: GSoC: Working on the static analyzer
On Tue, 2022-01-11 at 11:03 +0530, Mir Immad via Gcc wrote: > Hi everyone, Hi, and welcome. > 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 Yes. There are also some high-level notes here: https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer Also, given that the analyzer is part of GCC, the more general introductions to hacking on GCC will be useful. I recommend creating a trivial C source file with a bug in it (e.g. a 3-line function with a use-after-free), and stepping through the analyzer to get a sense of how it works. Hope this is helpful; don't hesitate to ask questions. Dave
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 13:56, Martin Liška wrote: Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu and I've built all cross compilers. Does this also rename .c files in the fortran and libgfortran directories ? I would recommend to send this message to the fort...@gcc.gnu.org list too, then. Not everyone reads the gcc and gcc-patches lists ... Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 16:48, Toon Moene wrote: On 1/11/22 13:56, Martin Liška wrote: Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu and I've built all cross compilers. Does this also rename .c files in the fortran and libgfortran directories ? Hello. Yes, it does the first one. I would recommend to send this message to the fort...@gcc.gnu.org list too, then. Not everyone reads the gcc and gcc-patches lists ... CCing the list now. Thanks, Martin Kind regards,
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote: > On 1/11/22 16:48, Toon Moene wrote: > > On 1/11/22 13:56, Martin Liška wrote: > > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > Plus it survives build of all FEs (--enable-languages=all) on > > > x86_64-linux-gnu > > > and I've built all cross compilers. > > > > Does this also rename .c files in the fortran and libgfortran directories ? > > Hello. > > Yes, it does the first one. And it shouldn't in libgfortran - libgfortran, libgcc, libgomp, libquadmath are all written in C, not C++. While e.g. libcpp or gcc are in C++. Jakub
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 16:56, Jakub Jelinek wrote: While e.g. libcpp or gcc are in C++. Which means I should rename .c files under libcpp, right? Is there any other folder from gcc/ and libcpp/ that would need that as well? Martin
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: > On 1/11/22 16:56, Jakub Jelinek wrote: > > While e.g. libcpp or gcc are in C++. > > Which means I should rename .c files under libcpp, right? > Is there any other folder from gcc/ and libcpp/ that would need that as well? >From the directories that use .c files for C++, I think that is all. c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already use .cc or .cpp. Jakub
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
Am 11.01.22 um 16:50 schrieb Martin Liška: On 1/11/22 16:48, Toon Moene wrote: On 1/11/22 13:56, Martin Liška wrote: Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu and I've built all cross compilers. Does this also rename .c files in the fortran and libgfortran directories ? Hello. Yes, it does the first one. Regarding fortran: can we have a vote on this one? Some developers (including myself) are not really familiar with C++, and in the past preference has been expressed on the fortran ML in favor of not using too much C++. I would also not really be in a position to review real C++ code. Thanks, Harald I would recommend to send this message to the fort...@gcc.gnu.org list too, then. Not everyone reads the gcc and gcc-patches lists ... CCing the list now. Thanks, Martin Kind regards,
Re: reordering of trapping operations and volatile
On 11/01/2022 08:11, Richard Biener via Gcc wrote: > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: >> > > 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). > > Actually, volatile accesses /are/ critical to observable behaviour - observable behaviour is program start and termination (normal termination flushing file buffers, not crashes which are UB), input and output via "interactive devices" (these are not defined by the standard), and volatile accesses. (See 5.1.2.3p6 in the standards if you want the details. Note that in C18, "volatile access" was expanded to include all accesses through volatile-qualified lvalues.) However, undefined behaviour is /not/ observable behaviour. It can also be viewed as not affecting anything else, and so moving it does not affect volatile accesses. So you can't re-order two volatile accesses with respect to each other. But you /can/ re-order UB with respect to anything else, including volatile accesses. (IMHO) "Performing a trap" - such as some systems will do when dividing by 0, for example - is not listed as observable behaviour.
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On Tue, 11 Jan 2022 at 18:02, Harald Anlauf via Gcc wrote: > > Am 11.01.22 um 16:50 schrieb Martin Liška: > > On 1/11/22 16:48, Toon Moene wrote: > >> On 1/11/22 13:56, Martin Liška wrote: > >> > >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >>> Plus it survives build of all FEs (--enable-languages=all) on > >>> x86_64-linux-gnu > >>> and I've built all cross compilers. > >> > >> Does this also rename .c files in the fortran and libgfortran > >> directories ? > > > > Hello. > > > > Yes, it does the first one. > > Regarding fortran: can we have a vote on this one? > > Some developers (including myself) are not really familiar with C++, > and in the past preference has been expressed on the fortran ML in > favor of not using too much C++. > > I would also not really be in a position to review real C++ code. The discussion is purely about renaming files that are *already* C++ source files but have the misleading .c file extension. Nobody is suggesting using C++ where it isn't already being used.
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On Tue, Jan 11, 2022 at 06:23:51PM +, Jonathan Wakely via Gcc-patches wrote: > > Regarding fortran: can we have a vote on this one? > > > > Some developers (including myself) are not really familiar with C++, > > and in the past preference has been expressed on the fortran ML in > > favor of not using too much C++. > > > > I would also not really be in a position to review real C++ code. > > The discussion is purely about renaming files that are *already* C++ > source files but have the misleading .c file extension. > > Nobody is suggesting using C++ where it isn't already being used. And even gcc/fortran/ is written in C++, the gcc/ headers it uses are C++ only, they use templates etc., so gcc/fortran/ that uses those headers has to be C++ too. That doesn't mean you need to use C++ idioms everywhere in your code, those files can stay to be mostly C-like with C++ headers and use C++-only constructs only where it brings sufficient advantages. Many of the gcc/*.c sources that Martin wants to rename are also written like that. The renaming will just match the reality, clang++ will stop warning that support for .c extension for C++ is deprecated when building gcc, sites like openhub.net (if they twice a year manage to build stats for gcc, dunno what they are doing wrong or if it is because of the limiting of anonymous git on sourceware) will not claim most of GCC is written in C etc. Jakub
Re: reordering of trapping operations and volatile
Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener:
> On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote:
> > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
...
> Consider
>
> int a[1024];
> void foo (volatile int *p, float *q)
> {
>for (int i = 0; i < 1024; ++i)
> {
> *p = 1;
> a[i] = *q;
> }
> }
>
> we happily apply invariant motion to the load from *q, making
> it cross the store to the volatile object at *p. Now, q might be
> NULL upon entry to the function and thus this transform
> would violate the volatile "I/O" constraint (since I/O is observable)
> and thus we will crash (which is UB) before doing the first I/O.
>
> That's an example I'd consider important for performance and
> also a case that shows that usually the compiler will have a
> very hard time proving UB cannot happen (as opposed to the
> usual stance where it can assume it doesn't).
I can see that the transformation in general is important,
but why is it important if the "volatile" is there?
I would assume that performance-sensitive code usually
does not volatile.
Or in other words, what is the purpose of volatile in
this example if not either I/O or to prevent such
optimizations?
> The case we run into sth similar is with use of uninitialized
> variables where proving some variable is initialized is nearly
> impossible (copy initialization from a variable that is not
> initialized is not initialization).
These are the C++ rules.
For C, an automatic variables which is not initialized and
(as long as the address is not taken), it is directly UB.
> We've mainly settled to the stance that only program termination
> is observable which means if we do not know that a function
> call will always return normally we have to avoid hoisting
> observable UB across such function call (and I/O routines
> usually fall into this category because they are not annotated
> as always returning).
Yes.
> Handling all volatile accesses in the
> very same way would be possible but quite some work I don't
> see much value in.
I see some value.
But an alternative could be to remove volatile
from the observable behavior in the standard
or make it implementation-defined whether it
is observable or not.
Martin
> Richard.
>
> > Martin
> >
> > > > > > 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-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
> > > > > >
> > > > > >
Azuka Kiki
