Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64
Hi!
CCing Segher and David on this.
rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for
any mode and thus leaves it to the generic code.
On Tue, Feb 14, 2023 at 04:48:42AM +0100, Simon Richter wrote:
> I'm looking at the generated code for these builtins on POWER:
>
> add 4,3,4
> subfc 3,3,4
> subfe 3,3,3
> std 4,0(5)
> rldicl 3,3,0,63
> blr
>
> and
>
> mulld 10,3,4
> mulhdu 3,3,4
> addic 9,3,-1
> std 10,0(5)
> subfe 3,9,3
> blr
>
> The POWER architecture has variants of these instructions with builtin
> overflow checks (addo/mulldo), but these aren't listed in the .md files, and
> the builtins don't generate them either.
>
> Is this intentional (I've found a few comments that mulldo is microcoded on
> CellBE and should be avoided there)?
Jakub
Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64
> rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for
> any mode and thus leaves it to the generic code.
https://gcc.gnu.org/pipermail/gcc-patches/2016-October/460209.html
--
Eric Botcazou
[wish] -Wmissing-array-initializers
Hi!
I was wondering if we can have a warning similar to
-Wmissing-field-initializers but for arrays.
Here's some example of what kind of code would benefit from this warning:
// foo.c
char *foo[5] = {
"foo",
"bar",
"baz"
// oops, accidentally the size doesn't match the actual number of fields
};
// foo.h
extern char *foo[5];
Users should be able to trust that each field will be a valid string,
but we have no way to make sure that the array is initialized with strings.
If the initialization is done through designated initializers [...]=..., or
{0}, it wouldn't warn, as with structs.
I couldn't find an open ticket in bugzilla regarding this. If you want, I
could open one.
Does it make sense to you?
Cheers,
Alex
--
Re: __builtin_(add|mul)_overflow methods generate duplicate operations if both operands are const
On Sun, 12 Feb 2023 at 20:46, David Shane Holden via Gcc wrote: > > I requested a bugzilla account a few days ago and haven't heard > back so I'm just going to report this here. I've created your account now, so please post this to bugzilla, thanks!
Re: [PATCH v5 3/5] p1689r5: initial support
On 1/25/23 13:06, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Thanks again. Support is communicated through the following three new flags: - `-fdeps-format=` specifies the format for the output. Currently named `p1689r5`. - `-fdeps-file=` specifies the path to the file to write the format to. - `-fdep-output=` specifies the `.o` that will be written for the TU that is scanned. This is required so that the build system can correlate the dependency output with the actual compilation that will occur. I notice that the actual flags are all -fdep-*, though some of them are -fdeps-* here, and the internal variables all seem to be fdeps_*. I lean toward harmonizing on "deps", I think. I don't love the three separate options, but I suppose it's fine. I'd prefer "target" instead of "output". It should be possible to omit both -file and -target and get reasonable defaults, like the ones for -MD/-MQ in gcc.cc:cpp_unique_options. CMake supports this format as of 17 Jun 2022 (to be part of 3.25.0) using an experimental feature selection (to allow for future usage evolution without committing to how it works today). While it remains experimental, docs may be found in CMake's documentation for experimental features. Future work may include using this format for Fortran module dependencies as well, however this is still pending work. [P1689R5]: https://isocpp.org/files/papers/P1689R5.html [cmake-experimental]: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst TODO: - header-unit information fields Header units (including the standard library headers) are 100% unsupported right now because the `-E` mechanism wants to import their BMIs. A new mode (i.e., something more workable than existing `-E` behavior) that mocks up header units as if they were imported purely from their path and content would be required. I notice that the cpp dependency generation tries (in open_file_failed) to continue after encountering a missing file, is that not sufficient for header units? Or adjustable to be sufficient? - non-utf8 paths The current standard says that paths that are not unambiguously represented using UTF-8 are not supported (because these cases are rare and the extra complication is not worth it at this time). Future versions of the format might have ways of encoding non-UTF-8 paths. For now, this patch just doesn't support non-UTF-8 paths (ignoring the "unambiguously represetable in UTF-8" case). typo "representable" - figure out why junk gets placed at the end of the file Sometimes it seems like the file gets a lot of `NUL` bytes appended to it. It happens rarely and seems to be the result of some `ftruncate`-style call which results in extra padding in the contents. Noting it here as an observation at least. libcpp/ * include/cpplib.h: Add cpp_deps_format enum. (cpp_options): Add format field (cpp_finish): Add dependency stream parameter. * include/mkdeps.h (deps_add_module_target): Add new preprocessor parameter used for C++ module tracking. * init.cc (cpp_finish): Add new preprocessor parameter used for C++ module tracking. * mkdeps.cc (mkdeps): Implement P1689R5 output. gcc/ * doc/invoke.texi: Document -fdeps-format=, -fdep-file=, and -fdep-output= flags. gcc/c-family/ * c-opts.cc (c_common_handle_option): Add fdeps_file variable and -fdeps-format=, -fdep-file=, and -fdep-output= parsing. * c.opt: Add -fdeps-format=, -fdep-file=, and -fdep-output= flags. gcc/cp/ * module.cc (preprocessed_module): Pass whether the module is exported to dependency tracking. gcc/testsuite/ * g++.dg/modules/depflags-f-MD.C: New test. * g++.dg/modules/depflags-f.C: New test. * g++.dg/modules/depflags-fi.C: New test. * g++.dg/modules/depflags-fj-MD.C: New test. * g++.dg/modules/depflags-fj.C: New test. * g++.dg/modules/depflags-fjo-MD.C: New test. * g++.dg/modules/depflags-fjo.C: New test. * g++.dg/modules/depflags-fo-MD.C: New test. * g++.dg/modules/depflags-fo.C: New test. * g++.dg/modules/depflags-j-MD.C: New test. * g++.dg/modules/depflags-j.C: New test. * g++.dg/modules/depflags-jo-MD.C: New test. * g++.dg/modules/depflags-jo.C: New test. * g++.dg/modules/depflags-o-MD.C: New test. * g++.dg/modules/depflags-o.C: New test. * g++.dg/modules/p1689-1.C: New test. * g++.dg/modules/p1689-1.exp.json: New test expectation. * g++.dg/modules/p1689-2.C: New test. * g++.dg/modules/p1689-2.exp.json: New test expectation. * g++.dg/modules/p1689-3.C: New test. * g++.dg/modules/p1689-3.exp.json: New test expectation.
Anyone using FTensor to test GCC (or otherwise)?
>From previous times we have FTensor https://gcc.gnu.org/testing/testing-ftensor.html documented as one of the ways to test GCC. Alas http://www.wlandry.net/Projects/FTensor has been down for a while, and there does not appear to be a new location? Is anyone actually still using FTensor to test GCC (or otherwise)? I'm wondering whether to simply delete that page... Gerald
Re: Anyone using FTensor to test GCC (or otherwise)?
On Tue, Feb 14, 2023 at 6:20 PM Gerald Pfeifer wrote: > Alas http://www.wlandry.net/Projects/FTensor has been down for a while, > and there does not appear to be a new location? https://wlandry.net/Projects/FTensor/ works
