Re: C PATCH for c/68668 (grokdeclarator and wrong type of PARM_DECL)

On Thu, 3 Dec 2015, Marek Polacek wrote: > This ought to fix the fallout from PR c/68162 fix. Here the problem is that > grokdeclarator created a wrong type for PARM_DECL "p". It created this decl > with type "const int[] *" while it should be "const int *". > > I think the problem is that we w

Re: C PATCH for c/68668 (grokdeclarator and wrong type of PARM_DECL)

On Thu, 3 Dec 2015, Marek Polacek wrote: > > I think you also need to decrement orig_qual_indirect, which counts the > > number of levels of array type derivation from orig_qual_type. > > Thus: > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2015-12-03 Marek Polacek > >

Re: [C] Issue an error on scalar va_list with reverse storage order

On Thu, 3 Dec 2015, Eric Botcazou wrote: > Hi, > > further testing revealed an issue with va_arg handling and reverse scalar > storage order on some platforms: when va_list is scalar, passing a field of a > structure with reverse SSO as first argument to va_start/va_arg/va_end > doesn't > wor

Re: Ping [PATCH] c++/42121 - diagnose invalid flexible array members

On Thu, 3 Dec 2015, Martin Sebor wrote: > The only C change in this patch is to include the size of excessively > large types in diagnostics (I found knowing the size helpful when > adding tests and I think it might be helpful to others as well). I don't see what that C change has to do with flex

Re: [PATCH] [C FE] Fold trivial exprs that refer to const vars

On Mon, 7 Dec 2015, Patrick Palka wrote: > To fix this inconsistency, this patch calls decl_constant_value in > c_fully fold after folding the given expression. The aim should be to eliminate decl_constant_value use here once all folding optimizations are also done on GIMPLE (and generally reduc

Re: C PATCH for c/68668 (grokdeclarator and wrong type of PARM_DECL)

On Mon, 7 Dec 2015, Marek Polacek wrote: > + if (orig_qual_indirect != 0) > + orig_qual_type = TREE_TYPE (orig_qual_type); > + else > + orig_qual_indirect--; For optimal results for debug info, I think that should be == 0 (i.e. preserve orig_qu

Re: C PATCH for c/68668 (grokdeclarator and wrong type of PARM_DECL)

On Mon, 7 Dec 2015, Marek Polacek wrote: > Anyway, here's the version with == 0. Thanks, > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2015-12-07 Marek Polacek > > PR c/68668 > * c-decl.c (grokdeclarator): If ORIG_QUAL_INDIRECT is indirect, use > TREE_TYPE

Re: [PATCH] gcc: read -fdebug-prefix-map OLD from environment (improved reproducibility)

On Thu, 10 Dec 2015, Daniel Kahn Gillmor wrote: > Specifically, if the first character of the "old" argument is a > literal $, then gcc will treat it as an environment variable name, and > use the value of the env var for prefix mapping. I don't think a literal $ in option arguments is a good ide

Re: [Patch, Fortran] PR68815 - replace '%s' quotes by %< ... %>

On Thu, 10 Dec 2015, Manuel López-Ibáñez wrote: > On 12/09/2015 03:53 PM, Tobias Burnus wrote: > > In principle, %<%c%> and %<%d%> should be convertable to %qc and > > %qd (as the code is more readable), but the current function > > annotation prevent this, telling that the q flag is not valid for

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Fri, 7 Aug 2020, Martin Sebor via Gcc-patches wrote: > > I don't see anything in the tests in this patch to cover this sort of case > > (arrays of pointers, including arrays of pointers to arrays etc.). > > I've added a few test cases and reworked the declarator parsing > (get_parm_array_spec)

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Thu, 13 Aug 2020, Martin Sebor via Gcc-patches wrote: > > * Maybe cdk_pointer is followed by cdk_attrs before cdk_id. In this case > > the code won't return. > > I think I see the problem you're pointing out (I just don't see how > to trigger it or test that it doesn't happen). If the tweak

Re: [PATCH] c: Fix -Wunused-but-set-* warning with _Generic [PR96571]

On Fri, 14 Aug 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcase shows various problems with -Wunused-but-set* > warnings and _Generic construct. I think it is best to treat the selector > and the ignored expressions as (potentially) read, because when they are > parsed

Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

On Sat, 15 Aug 2020, Segher Boessenkool wrote: > Hi! > > On Sat, Aug 15, 2020 at 12:10:42PM +0100, Roger Sayle wrote: > > I'll quote Joseph Myers (many thanks) who describes things clearly as: > > > (a) When both arguments are NaNs, the return value should be a qNaN,

Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

On Mon, 17 Aug 2020, Segher Boessenkool wrote: > Ah, so "When both arguments are NaNs, the return value should be a qNaN" > means the QNaN corresponding to eother x or y. I see, thanks! Yes. (The precise choice of NaN result given a NaN input is the subject of various "should"s, in 6.2.3 NaN p

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote: > > I think you need a while loop there, not just an if, to account for the > > case of multiple consecutive cdk_attrs. At least the GNU attribute syntax > > > > direct-declarator: > > [...] > > ( gnu-attributes[opt] declarator )

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On Thu, 13 Aug 2020, Tobias Burnus wrote: > diff --git a/config/ax_cxx_compile_stdcxx.m4 b/config/ax_cxx_compile_stdcxx.m4 > index 9413da624d2..0cd515fc65b 100644 > --- a/config/ax_cxx_compile_stdcxx.m4 > +++ b/config/ax_cxx_compile_stdcxx.m4 > @@ -25,6 +25,10 @@ > # regardless, after defining

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On Thu, 20 Aug 2020, Tobias Burnus wrote: > Thanks for the first review; new version attached. Thanks, this version is OK for GCC (but the GCC version will need updating if autoconf-archive ends up with a different version of these changes). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] libgccjit: Fix several memory leaks in the driver

On Thu, 9 Jul 2020, Alex Coplan wrote: > 2020-07-09 Alex Coplan > > * gcc.c (set_static_spec): New. > (set_static_spec_owned): New. > (set_static_spec_shared): New. > (driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use > set_static_spec_owned() to take ownership of lt

Re: [PATCH 4/6] Add `+' for Jobserver Integration

On Thu, 20 Aug 2020, Giuliano Belinassi via Gcc-patches wrote: > libbacktrace/Makefile.in | 2 +- > zlib/Makefile.in | 64 ++-- These directories use makefiles generated by automake. Rather than modifying the generated files, you need to modify the sources (whether that's Ma

Re: [PATCH] avoid erroneous argument types when checking built-in signatures (PR c/96596)

On Thu, 27 Aug 2020, Martin Sebor via Gcc-patches wrote: > The attached change has match_builtin_function_types() fail > for erroneous argument types to prevent an ICE due to assuming > they are necessarily valid. OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] separate reading past the end from -Wstringop-overflow

On Tue, 1 Sep 2020, Jeff Law via Gcc-patches wrote: > > With this commit: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553109.html > > the remaining failures should now be gone. Please let me know if > > any persist. > There's a related glibc build failure, but I think Joseph ack'

Re: [PING] floatformat.h: Add bfloat16 support.

On Mon, 7 Sep 2020, Willgerodt, Felix via Gcc-patches wrote: > @@ -133,6 +133,9 @@ extern const struct floatformat > floatformat_ia64_quad_little; > /* IBM long double (double+double). */ extern const struct floatformat > floatformat_ibm_long_double_big; extern const struct floatformat > fl

RE: [PING] floatformat.h: Add bfloat16 support.

On Tue, 8 Sep 2020, Willgerodt, Felix via Gcc-patches wrote: > Thanks for your review. It seems like the format issue was introduced by > my email client when hitting reply. Sorry for that! The original patch > is formatted correctly, as I used git send-email: > https://gcc.gnu.org/pipermail/gc

Re: [PATCH v1] [include] Add codes for DWARF v5 .dwp sections to dwarf2.h

On Wed, 9 Sep 2020, Caroline Tice via Gcc-patches wrote: > For DWARF v5 Dwarf Package Files (.dwp files), the section identifier > encodings have changed. This patch updates dwarf2.h to contain the new > encodings. (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5). > > This patch has alrea

Re: gcc git hook

On Thu, 10 Sep 2020, Nathan Sidwell wrote: > Is it possible for the git hooks to reject pushes with overly-long subject > lines? > > I occasionally see pushes that forgot to add a separate title line, and so the > whole of the commit description gets used. Is that where the whole description is

Re: [PATCH] i18n: Fix translation of --help [PR93759]

On Tue, 18 Feb 2020, Jakub Jelinek wrote: > Hi! > > The first two hunks make sure we actually translate what has been marked > for translation, i.e. the cl_options[...].help strings, rather than those > strings ammended in various ways, like: > _("%s Same as %s."), help, ... > or > "%s %s", hel

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

On Wed, 19 Feb 2020, GT wrote: > 1. In the Vector Function ABI document, under section "Vector Function > Name Mangling", state that all vector variants will be created by > the compiler. And that it will be up to the caller of vectorized > functions to select the preferred version ('b' or 'c'

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

On Thu, 20 Feb 2020, GT wrote: > What more needs to be done other than documenting the GLIBC and GCC > versions for which 'b' and 'c' vector versions are available? It is how > x86_64 explained the differences between Examples 1 and 2 at > https://sourceware.org/glibc/wiki/libmvec This is abou

Re: GLIBC libmvec status

On Tue, 25 Feb 2020, GT wrote: > 2. In GCC making SIMD clones available only for powerpc64le should be > sufficient to guarantee that the Vector Function ABI is applied only for > systems implementing the ELFv2 ABI. Right? Then, which macro is to be > tested for in rs6000_simd_clone_usable? I e

Re: [PATCH] maintainer-scripts: Speed up git clone in gcc_release

On Wed, 26 Feb 2020, Jakub Jelinek wrote: > Hi! > > When doing the 8.4-rc1, I've noticed (probably also because of the dying > disk on sourceware) that git clone is extremely slow, and furthermore when > all of us have some local snapshots, it is a waste of resources to download > everything agai

Re: collect2.exe errors not pruned

On Fri, 28 Feb 2020, Alexandre Oliva wrote: > I'm not sure it's appropriate for the error to not omit the host > platform's executable suffix, just as it omits directory components from > argv[0], so I'm undecided between fixing collect2.c's initialization of > progname or extending the regexp, as

Re: maxval on -inf and nan in Fortran

On Fri, 28 Feb 2020, Tobias Burnus wrote: > Regarding MIN and MAX: I think the IEEE 754 decided at some point > decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I > recall correctly). I think one has to check what exactly the test case > does and what is guaranteed where. I als

Re: [PATCH] Clear --help=language and --help=common interaction.

On Mon, 2 Mar 2020, Martin Liška wrote: > +version of GCC@. If an option is supported by all languages, one needs > +to use @var{common} qualifier instead. "common" is literal text, so it should be @samp{common} not @var{common}, and the existing documentation here describes it as a "class" wit

Re: [PATCH] Clear --help=language and --help=common interaction.

On Tue, 3 Mar 2020, Martin Liška wrote: > On 3/2/20 11:52 PM, Joseph Myers wrote: > > On Mon, 2 Mar 2020, Martin Liška wrote: > > > > > +version of GCC@. If an option is supported by all languages, one needs > > > +to use @var{common} qualifier instead. > &g

Re: [PATCH v2 0/3] Introduce a new GCC option, --record-gcc-command-line

On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote: > Although we discussed after the submission of the first version that > there are several other options performing similar tasks, I believe we > established that there is still a need for this specific functionality. > Therefore, I am skipping in thi

Re: [Committed 4/4] IBM Z: zTPF: Include glibc-stdint.h

On Wed, 4 Mar 2020, Andreas Krebbel wrote: > Building a zTPF cross currently fails when building libstdc++ > complaining about the __UINTPTR_TYPE__ to be missing. > > Fixed by including the glibc-stdint.h header. To confirm: TPF provides a header, which uses the same types as glibc's does? I

c: ignore initializers for elements of variable-size types [PR93577]

type name, and adds tests for a few variations on what such initializers might look like, as well as tests for cases identified from ICEs seen with an earlier version of this patch. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2020-03-05 Joseph Myers

Re: c: ignore initializers for elements of variable-size types [PR93577]

On Mon, 9 Mar 2020, Christophe Lyon wrote: > Hi Joseph, > > I've noticed that your patch introduces regressions on aarch64: > FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c > -march=armv8.2-a+sve (test for errors, line 33) > we now get > /gcc/testsuite/gcc.target/aarch64/sve/acle/gener

Re: c: ignore initializers for elements of variable-size types [PR93577]

On Tue, 10 Mar 2020, Christophe Lyon wrote: > sizeless-1.c and sizeless-2.c have the same code, but the latter is > compiled with -msve-vector-bits=256 and expects different > warnings/errors. > For line 33: > svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr }; > we now have: > size

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On Thu, 5 Mar 2020, Martin Sebor wrote: > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9? OK for GCC 10. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] driver: Fix typos in options descriptions

On Thu, 30 Jan 2020, Lewis Hyatt wrote: > Is this something that would be desirable to change for GCC 10? Attached > patch would do so, and the output would become instead: This patch is OK. (It may mean some translation updates, but we generally do such bug fixes when the issue is found by tra

Re: c: ignore initializers for elements of variable-size types [PR93577]

On Fri, 13 Mar 2020, Christophe Lyon via Gcc-patches wrote: > The attached small patch fixes the problem (tested on arm and aarch64). > OK? > > gcc/c/ChangeLog: > > 2020-03-13 Christophe Lyon > > * c-typeck.c (process_init_element): Handle constructor_type with > type size re

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On Fri, 13 Mar 2020, Martin Sebor via Gcc-patches wrote: > On 3/12/20 7:17 PM, Joseph Myers wrote: > > On Thu, 5 Mar 2020, Martin Sebor wrote: > > > > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9? > > > > OK for GCC 10. > >

Re: [PATCH] c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]

On Tue, 17 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcases ICE, because they contain extern variable > declarations with incomplete enum types that is later completed and after > that those variables are accessed. The ICEs are because the vars then may > have >

Re: [stage1][PATCH] optgen: make more sanity checks for enums.

On Tue, 17 Mar 2020, Martin Liška wrote: > Hi. > > The patch is about better sanity check in option generation script. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed in stage1? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [stage1][PATCH] optgen: make more sanity checks for enums.

On Wed, 18 Mar 2020, Martin Liška wrote: > On 3/17/20 11:41 PM, Martin Sebor wrote: > > The script reports errors by emitting them as #error directives into > > standard output (so they cause the build to fail). Should this new > > routine do the same thing?  (/dev/stderr is also not available on 

Re: [PATCH] c: Fix up cfun->function_end_locus from the C FE [PR94029]

On Thu, 19 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > The second instead propagates the location_t from the parsing of the > outermost compound statement (the function body) to finish_function. > > Both patches successfully bootstrapped/regtested on x86_64-linux and > i686-linux, ok for tru

Re: [PATCH] c-family: Tighten vector handling in type_for_mode [PR94072]

On Thu, 19 Mar 2020, Richard Sandiford wrote: > In this PR we had a 512-bit VECTOR_TYPE whose mode is XImode > (an integer mode used for four 128-bit vectors). When trying > to expand a zero constant for it, we hit code in expand_expr_real_1 > that tries to use the associated integer type instead

Ping Re: c: Add C2X BOOL_MAX and BOOL_WIDTH to limits.h

Ping for this limits.h patch . -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Require CET support only for the final GCC build

On Wed, 15 Jul 2020, Richard Biener wrote: > But note one of the issues is that when not cross-compiling we're > using a single libiberty for target and host objects (likewise There shouldn't be a target libiberty, since commit 8499116aa30a46993deff5acf73985df6b16fb8b (re PR regression/47836 (So

Re: [committed] libstdc++: Add std::from_chars for floating-point types

On Tue, 21 Jul 2020, Jonathan Wakely via Gcc-patches wrote: > I also noticed some strings give an underflow error with glibc's > strtod, but are valid for the Microsoft implementation. For example, > this one: > https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_f

Re: [PATCH PR96053] Add "#pragma GCC no_reduc_chain"

A new pragma needs to be documented in extend.texi. Such documentation should be comprehensible to users who don't know anything about the internals of GCC or other compilers, so that they can understand when it would be appropriate to use the pragma in their source code. -- Joseph S. Myers j

Re: [PATCH 1/2] Add new RTX instruction class FILLER_INSN

New insn types should be documented in rtl.texi (I think in the "Insns" section). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH v3] genemit.c (main): split insn-emit.c for compiling parallelly

On Fri, 24 Jul 2020, Jojo R wrote: > + -csplit insn-$*.c /parallel\ compilation/ -k -s > {$(insn-generated-split-num)} -f insn-$* -b "%d.c" > + -( [ ! -s insn-$*0.c ] && for i in {1..$(insn-generated-split-num)}; do > touch insn-$*$$i.c; done && echo "" > insn-$*.c) Ignoring errors (dis

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Tue, 28 Jul 2020, Martin Sebor via Gcc-patches wrote: > + /* A list of VLA variable bounds or null if not specified. */ > + tree vbchain = NULL_TREE; > + if (parm->declarator->kind == cdk_array) > + if (pd->kind != cdk_array) > + break; > + /* Skip all constant bou

Re: [PATCH] Require CET support only for the final GCC build

On Wed, 29 Jul 2020, Richard Biener wrote: > Note that any workable solution is fine with me, I just > don't feel comfortable approving the solution involving > ../curr_stage and friends. Joseph, would HJs latest > patch be OK technically? Yes, I think that's OK. -- Joseph S. Myers jos...@code

Re: [PATCH] c: Fix bogus vector initialisation error [PR96377]

On Fri, 31 Jul 2020, Richard Sandiford wrote: > Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu. > OK to instal? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] CSKY: Add -mfloat-abi= option.

My glibc bot is showing the build of libgcc for csky-linux-gnuabiv2 (configured --with-float=hard --disable-multilib) has recently broken, likely from this change. https://sourceware.org/pipermail/libc-testresults/2020q3/006566.html The errors are of the form: /tmp/cc7H0Zu7.s: Assembler messag

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

On Mon, 3 Aug 2020, Asher Gordon via Gcc-patches wrote: > Hello, > > Asher Gordon writes: > > > My copyright assignment finally got finished, so you should be able to > > apply my patches now. > > Is there any reason my patches haven't been applied yet? Is there > anything else I need to do?

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Thu, 6 Aug 2020, Maciej W. Rozycki via Gcc-patches wrote: > Given that for the `riscv64-linux-gnu' target and the ilp32d multilib > glibc currently fails to link against libgcc.a built at -O0 I first ran > reference testing with target libraries built at -O2, but comparing that > to change-

Re: [PATCH] c: After issuing errors about array size, for error-recovery don't make the array VLA [PR93573]

On Sat, 28 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > After we report various errors about array size, we set for error-recovery > the size to be 1, but because size_int_const is false, it still means we > pretend the array is a VLA, can emit a second diagnostics in that case etc. >

Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

Thanks, this matches the commit hook (which only rejects From-SVN: at start of line, not elsewhere in a commit message). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] gcc/gcc.c: add outfiles spec

On Sat, 4 Apr 2020, Rasmus Villemoes wrote: > +#ifndef OUTFILES_SPEC > +#define OUTFILES_SPEC "%o" > +#endif A new target macro needs to be documented in tm.texi.in, with tm.texi then being regenerated. -- Joseph S. Myers jos...@codesourcery.com

Re: [committed] cselib: Fix endless cselib loop on (plus:P (reg) (const_int 0))

This introduces an ICE building glibc for m68k (and the same ICE appears for microblaze, though I haven't bisected there). See bug 94526. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] gcc/gcc.c: add outfiles spec

On Tue, 14 Apr 2020, Rasmus Villemoes wrote: > On 06/04/2020 23.18, Joseph Myers wrote: > > On Sat, 4 Apr 2020, Rasmus Villemoes wrote: > > > >> +#ifndef OUTFILES_SPEC > >> +#define OUTFILES_SPEC "%o" > >> +#endif > > > > A new

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, 23 Apr 2020, Richard Biener via Gcc-patches wrote: > I think at least one step would be uncontroversical(?), namely moving > the RTL expansion "magic" > up to a GIMPLE pass. Where the "magic" would be to turn > GIMPLE stmts not directly expandable via an existing optab into > GIMPLE that

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

This is missing documentation for the new configure option in install.texi. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

On Thu, 30 Apr 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > If there are _Atomic side-effects in the parameter declarations > of non-nested function, when they are parsed, current_function_decl is > NULL, the create_artificial_label created labels during build_atomic* are > then adjusted

RE: Should ARMv8-A generic tuning default to -moutline-atomics

I think this change is what introduced a glibc testsuite regression in the localplt test. https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html Contents of elf/check-localplt.out: Extra PLT reference: libc.so: getauxval A reference to getauxval from libgcc is also a namespace vi

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Mon, 4 May 2020, Szabolcs Nagy wrote: > i think __getauxval needs to be declared where it is used. Yes. > and libgcc should do a link test in configure becasuse a > libc may provide sys/auxv.h but not have __getauxval e.g. > musl libc does not export __getauxval, only getauxval. libgcc can't

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Tue, 5 May 2020, Szabolcs Nagy wrote: > > A design principle is that glibc built with libgcc configured without > > glibc headers but with --with-glibc-version should produce an identical > > stripped binary to the glibc resulting from a longer alternating sequence > > of GCC and glibc build

RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Tue, 5 May 2020, Kyrylo Tkachov wrote: > This version of the fix uses __getauxval instead of getauxval. > The whole thing is guarded simply on __GLIBC__ >= 2. > __getauxval was introduced in 2.16 but the aarch64 port was added in 2.17 so > in practice I expect all aarch64 glibcs to support __g

Re: [PATCH, AArch64] PR target/91833

On Fri, 20 Sep 2019, Richard Henderson wrote: > Tested on aarch64-linux (glibc) and aarch64-elf (installed newlib). > > The existing configure claims to be generated by 2.69, but there > are changes wrt the autoconf distributed with Ubuntu 18. Nothing > that seems untoward though. They're meant

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

On Tue, 24 Sep 2019, Florian Weimer wrote: > I think this has to depend on the C standards version. I think each C > standard needs to be read against the edition of ISO 10646 current at > the time of standards approval (the references are sadly not > versioned, so the version is implied). Early

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

On Tue, 24 Sep 2019, Eric Botcazou wrote: > Hi, > > the Universal Character Names accepted by the C family of compilers are > mapped > to those of ISO/IEC 10646, which defines the Universal Character Set > codespace > as the range 0-0x10 inclusive. The upper bound is already enforced for

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

On Tue, 24 Sep 2019, Eric Botcazou wrote: > > I think this has to depend on the C standards version. I think each C > > standard needs to be read against the edition of ISO 10646 current at > > the time of standards approval (the references are sadly not > > versioned, so the version is implied).

Re: [PATCH] The inline keyword is supported in all new C standards

On Tue, 24 Sep 2019, Palmer Dabbelt wrote: > The documentation used to indicate that the inline keyword was only > supported by c99 and c11, whereas in fact it is supported by c99 and all > newer standards. > > gcc/ChangeLog > > 2019-09-24 Palmer Dabbelt > > * doc/extended.texi (Alte

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

On Thu, 26 Sep 2019, Eric Botcazou wrote: > > For C, I think such UCNs violate the Semantics but not the Constraints on > > UCNs, so no diagnostic is actually required in C, although it is permitted > > as a pedwarn / error. > > > > However, while C++ doesn't have that Semantics / Constraints div

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

On Thu, 26 Sep 2019, Lewis Hyatt wrote: > A couple notes: > - In order to avoid any portability problems with wchar_t, the > equivalent of wcwidth() from libc is implemented in-house. I'm uneasy about contrib/gen_wcwidth.cpp doing the generation using host libc's wcwidth. The effect is tha

Re: [WIP PATCH] add object access attributes (PR 83859)

On Sun, 29 Sep 2019, Martin Sebor wrote: > PR 83859 asks to expose the same checking that GCC does natively for > built-in calls via a function attribute that associates a pointer > argument with the size argument, such as: I'll also note that, as mentioned in that bug (but more specifically cov

Re: [C] Improve diagnostics for vector types

On Mon, 30 Sep 2019, Richard Sandiford wrote: > 2019-09-30 Richard Sandiford > > gcc/c-family/ > * c-pretty-print.c (pp_c_specifier_qualifier_list): If a vector type > has a type name, use it in preference to the __vector syntax. > > gcc/testsuite/ > * gcc.dg/diag-aka-3.c: N

Re: [C] Avoid aka types that just add tags

On Mon, 30 Sep 2019, Richard Sandiford wrote: > 2019-09-30 Richard Sandiford > > gcc/c/ > * c-objc-common.c (useful_aka_type_p): New function. > (print_type): Use it to decide whether an aka type is worth printing. > > gcc/testsuite/ > * gcc.dg/diag-aka-1.c (T): Turn into a

Handle :: tokens in C for C2x

hem (e.g. if stringized), already inserts space between : and : unconditionally, rather than only for C++, so no change is needed there (but a C2x test is added that such space is indeed inserted). Bootstrapped with no regressions on x86-64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-10-02 Jose

Re: Ping: question on Multiple level macro expansion

This is not a bug (except in icc, since you said icc accepts the code). gcc-help would have been a better mailing list for this sort of question. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Builtin fadd variants folding implementation

On Wed, 11 Sep 2019, Tejas Joshi wrote: > diff --git a/gcc/builtins.def b/gcc/builtins.def > index 8bb7027aac7..2df616c477e 100644 > --- a/gcc/builtins.def > +++ b/gcc/builtins.def > @@ -355,6 +355,9 @@ DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", > FABS_TYPE, ATTR_CONST_NOT > DEF_GCC_

Define WIDTH macros for C2x

CR_DECIMAL_DIG in float.h does still require __STDC_WANT_IEC_60559_BFP_EXT__ to be defined, and a test for this is added. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc: 2019-10-02 Joseph Myers * ginclude/stdint-gcc.h [__STDC_WANT_IEC_60559_BFP_EXT__

Mark C2x built-in functions as such

th no regressions on x86_64-pc-linux-gnu. OK to commit? Tejas, please note that once this patch is in, future revisions of the fadd patch should use DEF_C2X_BUILTIN for the fadd / faddl / daddl built-in functions added there. gcc: 2019-10-03 Joseph Myers * builtins.def (DEF_C2X_BUILTIN): New

Add strftime format checking support for C2x %OB and %Ob (bug 82752)

formats was added in glibc 2.27.) Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c-family: 2019-10-04 Joseph Myers PR c/82752 * c-format.c (C_STD_VER): Handle C2x. (C_STD_NAME): Likewise. (strftime_flag_specs): Add &#

Re: [PATCH] Fix -Wshadow=local warnings in elfos.h

On Sat, 5 Oct 2019, Bernd Edlinger wrote: > > Like > > > > #define DEFAULT_SOME_MACRO(PARMS) { lots of code } > > > > becomes > > > > #define DEFAULT_SOME_MACRO(PARMS) default_some_macro(PARMS) > > > > static inline int > > default_some_macro (int parm, long another) > > { > > lots of code;

Make C2X imply -fno-fp-int-builtin-inexact

Since TS 18661-1 has been integrated into C2X, this patch makes C2X imply -fno-fp-int-builtin-inexact. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc: 2019-10-08 Joseph Myers * doc/invoke.texi (-ffp-int-builtin-inexact): Document -fno-fp

GCC wwwdocs move to git done

I've done the move of GCC wwwdocs to git (using the previously posted and discussed scripts), including setting up the post-receive hook to do the same things previously covered by the old CVS hooks, and minimal updates to the web pages dealing with the CVS setup for wwwdocs. Note 1: someone wi

Re: GCC wwwdocs move to git done

On Tue, 8 Oct 2019, Frank Ch. Eigler wrote: > Hi - > > Thanks - good job with moving this to git! > > > Note 1: someone with the right access needs to create the symlink > > /sourceware/git/gcc-wwwdocs.git -> > > /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for > > anon

Re: Make C2X imply -fno-fp-int-builtin-inexact

On Wed, 9 Oct 2019, Rainer Orth wrote: > the new test FAILs on Solaris/x86, both 32 and 64-bit: > > FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O0 execution test > FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O1 execution test > FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c

Update DFP macros in float.h for C2x and TS 18661-2

ey do pass in a no-DFP configuration. Applied to mainline. gcc: 2019-10-10 Joseph Myers * ginclude/float.h [!__DEC32_MANT_DIG__]: Do not define DFP macros. [__STDC_WANT_IEC_60559_DFP_EXT__ || __STDC_VERSION__ > 201710L]: Also define DFP macros for these co

Support _Decimal* keywords for C2x

words-ignored-c99.c would make sense again with such spellings.) Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-10-11 Joseph Myers * c-decl.c (declspecs_add_type): Use pedwarn_c11 for DFP types. gcc/c-family: 2019-10-11 Joseph

Support decimal floating-point constants in C2x

requires -Wc11-c2x-compat to be newly passed through to libcpp). Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c-family: 2019-10-11 Joseph Myers * c.opt (Wc11-c2x-compat): Add CPP(cpp_warn_c11_c2x_compat) CppReason(CPP_W_C11_C2X_COMPAT). gcc

Re: [POC v2 PATCH] __builtin_warning

How does this interact with translation? My expectation would be that in user code, the message is taken literally as-is; it is not looked up in the GCC message catalog even if it is identical to some GCC diagnostic. However, when used internally for GCC diagnostics, they should be translated,

Re: [POC v2 PATCH] __builtin_warning

On Mon, 14 Oct 2019, Martin Sebor wrote: > On 10/14/19 4:03 PM, Joseph Myers wrote: > > How does this interact with translation? > > > > My expectation would be that in user code, the message is taken literally > > as-is; it is not looked up in the GCC message catalog

Rename attribute-related functions and productions in C parser

not expect code dealing with semantics of attributes outside of the parser to need to change; as for C++, it will be possible to use existing attributes inside [[]] with the gnu:: form of the attribute name.) Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. 2019-10-

Re: [POC v2 PATCH] __builtin_warning

On Tue, 15 Oct 2019, Richard Sandiford wrote: > > No. I'd expect the code generating the IR from GCC diagnostics should > > arrange for the message to be translated first (while in the case of > > __builtin_warning in user code, it would not be translated), and the code > > subsequently using

<    5   6   7   8   9   10   11   12   13   14   >