Re: Usage of EBCDIC (IBM 1047)

On Mon, 23 Aug 2021, Jesus Diaz via Gcc wrote: > However i've noticed that on functions with the printf-style formatting > attribute the EBCDIC strings tend to generate spurious errors - to my surprise > the "%" character seems to cause these issues. This may be due to the ASCII > host

Re: gcc_assert() and inhibit_libc

On Mon, 16 Aug 2021, Sebastian Huber wrote: > Ok, good. I will try to figure out what can be done. One problem is that > tsystem.h is included before tm.h. Independent of this Joseph S. Myers said > in the recent patch review with respect to the gcov_type size that removing > tm.h from the

Re: [PATCH v3] Fix for powerpc64 long double complex divide failure

On Fri, 13 Aug 2021, Andreas Schwab wrote: > On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote: > > > diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c > > index a1d29d2..2b229c8 100644 > > --- a/libgcc/config/rs6000/_divkc3.c > > +++

Re: [PATCH v3] Fix for powerpc64 long double complex divide failure

On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > If _divkc3.c is not intended to provide a version of complex divide > that handles IBM-128 format, then where should that option be handled? That should be the function __divtc3. (A single libgcc binary supports multiple long

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

On Mon, 24 May 2021, Uecker, Martin wrote: > - else if (VOID_TYPE_P (TREE_TYPE (type1)) > -&& !TYPE_ATOMIC (TREE_TYPE (type1))) > - { > - if ((TREE_CODE (TREE_TYPE (type2)) == ARRAY_TYPE) > - && (TYPE_QUALS (strip_array_types (TREE_TYPE (type2))) > -

Re: [PATCH v3] Fix for powerpc64 long double complex divide failure

On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > > This file includes quad-float128.h, which does some remapping from TF to > > KF depending on __LONG_DOUBLE_IEEE128__. > > > > I think you probably need to have a similar __LONG_DOUBLE_IEEE128__ > > conditional here.  If

Re: [PATCH v3] Fix for powerpc64 long double complex divide failure

On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > This patch resolves the failure of powerpc64 long double complex divide > in native ibm long double format after the patch "Practical improvement > to libgcc complex divide". This description is not consistent with the patch.

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

On Thu, 12 Aug 2021, Martin Uecker wrote: > Evaluate type arguments of sizeof that are structs of variable size [PR101838] > > Evaluate type arguments of sizeof for all types of variable size > and not just for VLAs. This fixes PR101838 and some issues related > to PR29970 where statement

Re: [PATCH v4] gcov: Add TARGET_GCOV_TYPE_SIZE target hook

On Thu, 12 Aug 2021, Sebastian Huber wrote: > If -fprofile-update=atomic is used, then the target must provide atomic > operations for the counters of the type returned by get_gcov_type(). > This is a 64-bit type for targets which have a 64-bit long long type. > On 32-bit targets this could be an

Re: [PATCH v3] gcov: Add TARGET_GCOV_TYPE_SIZE target macro

On Wed, 11 Aug 2021, Sebastian Huber wrote: > 64-bit atomic operations. Allow targets to override the default type > size with the new TARGET_GCOV_TYPE_SIZE target macro. Hook, not macro. > diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c > index

Re: [PATCH v2] gcov: Add GCOV_TYPE_SIZE target macro

On Tue, 10 Aug 2021, Sebastian Huber wrote: > Ok, I understood how I can add a compiler provided define for libgcov. What is > not clear to me is how I can add a target hook, set a default value, and > customize it for a target/system. Is this described here > >

Re: [PATCH v2] gcov: Add GCOV_TYPE_SIZE target macro

On Tue, 10 Aug 2021, Sebastian Huber wrote: > If -fprofile-update=atomic is used, then the target must provide atomic > operations for the counters of the type returned by get_gcov_type(). > This is a 64-bit type for targets which have a 64-bit long long type. > On 32-bit targets this could be an

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

On Mon, 9 Aug 2021, Uecker, Martin wrote: > I am still trying to figure out what the branch guarded > by c_vla_type_p is for in c_expr_sizeof_type. The comment > talks about [*], but how would you apply sizeof to > such an array? One can form something like The comment describes a requirement

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

On Mon, 9 Aug 2021, Uecker, Martin wrote: > Evaluate arguments of sizeof that are structs of variable size. > > Evaluate arguments of sizeof for all types of variable size > and not just for VLAs. This fixes some issues related to > [PR29970] where statement expressions need to be evaluated > so

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Sat, 7 Aug 2021, Stefan Kanthak wrote: > Joseph Myers wrote: > > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling; > > I'll do so as soon as GCC drops support for all C dialects before C2x! > > Unless you use a time machine and fix the POSIX and ISO

Re: [PATCH] libcpp: For C++23 treat UCNs and UTF-8 chars not valid in identifiers as separate tokens

On Fri, 6 Aug 2021, Jakub Jelinek via Gcc-patches wrote: > On Fri, Aug 06, 2021 at 11:53:56AM +0200, Jakub Jelinek via Gcc-patches wrote: > > Actually, there is another change in P1949R7 that I haven't touched > > in the patch and not sure what the implications are. > > > > To the

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Fri, 6 Aug 2021, Stefan Kanthak wrote: > > I don't know what the standard says about NaNs in this case, I seem to > > remember that arithmetic instructions typically produce QNaN when one of > > the inputs is a NaN, whether signaling or not. > >

Re: Failures building glibc with mainline GCC

On Tue, 3 Aug 2021, Segher Boessenkool wrote: > On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote: > > On 8/3/21 9:54 AM, Joseph Myers wrote: > > >As discussed, this is a bug indicating that the code generating that > >

Re: Sanity check that 'Init' doesn't appear without 'Var' in '*.opt' files

On Tue, 3 Aug 2021, Thomas Schwinge wrote: > Hi! > > Is the attached OK to push? > > No violations found per: > > $ find -type f -name \*.opt | xargs grep -F 'Init(' | grep -v -F 'Var(' > > ..., and manually verified the error condition. OK. -- Joseph S. Myers jos...@codesourcery.com

Re: Hooks fixed to treat trunk the same as master

On Tue, 3 Aug 2021, Martin Liška wrote: > On 8/2/21 7:22 PM, Joseph Myers wrote: > > Hey. > > > Some time ago, someone added a git symbolic-ref for refs/heads/trunk > > pointing to refs/heads/master. > > Great you found out what caused that. We were aware of

Re: Failures building glibc with mainline GCC

On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote: > On 7/30/21 2:52 PM, Joseph Myers wrote: > > On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote: > > > > > There's a new jump threader in GCC which is much more aggressive, and > > > may trigger latent problems with

Re: [PATCH 4/6] Support -fexcess-precision=16 which will enable FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.

On Mon, 2 Aug 2021, liuhongt via Gcc-patches wrote: > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 7979e240426..dc673c89bc8 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -23352,6 +23352,8 @@ ix86_get_excess_precision (enum excess_precision_type

Hooks fixed to treat trunk the same as master

Some time ago, someone added a git symbolic-ref for refs/heads/trunk pointing to refs/heads/master. A side effect of this was to introduce a loophole in the checks run via commit hooks, some of which are configured to apply only to master and release branches and didn't apply if commits were

Re: Failures building glibc with mainline GCC

On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote: > There's a new jump threader in GCC which is much more aggressive, and > may trigger latent problems with other warning passes, especially > -Warray-bounds, -Woverflow, and -Wuninitialized. > > Do your problems go away if you take out commit

Re: Are some builtin functions (for example log() vs. sqrt()) more equal than others?

On Fri, 30 Jul 2021, Stefan Kanthak wrote: > Joseph Myers wrote: > > > None of these are valid constant expressions as defined by the standard > > (constant expressions cannot involve evaluated function calls). > > That's why I ask specifically why GCC bugs on log(log

Re: Failures building glibc with mainline GCC

In addition to failures building glibc, for those configurations for which glibc builds there's a failure building the testsuite: tst-thread_local1.cc:177:5: error: variable 'std::array >, 2> do_thread_X' has initializer but incomplete type 177 | do_thread_X | ^~~ --

Re: Are some builtin functions (for example log() vs. sqrt()) more equal than others?

None of these are valid constant expressions as defined by the standard (constant expressions cannot involve evaluated function calls). Some might be accepted as an extension, but I expect that since the optimization for constant arguments is intended for valid calls that would otherwise be

Failures building glibc with mainline GCC

There are a lot of failures building glibc with mainline GCC right now (previously, there were ICEs building glibc on various architectures, so these might be hard to bisect): * x86_64-linux-gnu: "error: array subscript 0

Re: [PATCH 02/10] [i386] Enable _Float16 type for TARGET_SSE2 and above.

On Thu, 29 Jul 2021, Hongtao Liu via Gcc-patches wrote: > > Rather than using FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 whenever TARGET_SSE2 > > (i.e. whenever the type is available), it might make more sense to follow > > AArch64 and use it only when the hardware instructions are available. In > > any

Re: [PATCH 03/10] [i386] libgcc: Enable hfmode soft-sf/df/xf/tf extensions and truncations.

On Tue, 27 Jul 2021, Hongtao Liu via Gcc-patches wrote: > modified gcc/emit-rtl.c > @@ -928,6 +928,10 @@ validate_subreg (machine_mode omode, machine_mode imode, > fix them all. */ >if (omode == word_mode) > ; > + /* ???Similarly like (subreg:DI (reg:SF), also allow (subreg:SI

Re: Named address spaces on x86 GNU/Linux

On Thu, 29 Jul 2021, Florian Weimer via Gcc wrote: > On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid > dedicating a general-purpose register to it. At address zero with the > SEGFS prefix, the offset itself is stored so that userspace can read it > without having to call

Re: [PATCH] c/101512 - fix missing address-taking in c_common_mark_addressable_vec

On Wed, 21 Jul 2021, Jakub Jelinek via Gcc-patches wrote: > I wonder if instead when trying to wrap > C_MAYBE_CONST_EXPR into a VIEW_CONVERT_EXPR we shouldn't be > removing that C_MAYBE_CONST_EXPR and perhaps adding it around the > VIEW_CONVERT_EXPR. E.g. various routines in c/c-typeck.c like >

Re: [PATCH 02/10] [i386] Enable _Float16 type for TARGET_SSE2 and above.

On Wed, 21 Jul 2021, liuhongt via Gcc-patches wrote: > @@ -23254,13 +23337,15 @@ ix86_get_excess_precision (enum > excess_precision_type type) > provide would be identical were it not for the unpredictable > cases. */ > if (!TARGET_80387) > - return

Re: [PATCH][gcc] Allow functions without C-style ellipsis to use format attribute

On Mon, 19 Jul 2021, Martin Sebor via Gcc-patches wrote: > You've answered my questions about the design (thank you) and I don't > have any objections to the idea, but I'm not in a position to approve > the patch. I would suggest to get Jason's input on extending > attribute format to variadic

Re: [PATCH] driver/101383 - handle -gtoggle in driver

This patch is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [llvm-dev] [PATCH] Add optional _Float16 support

On Tue, 13 Jul 2021, H.J. Lu wrote: > On Mon, Jul 12, 2021 at 8:59 PM Wang, Pengfei wrote: > > > > > Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers. > > > > Can you please explain the behavior here? Is there difference between > > _Float16 and _Complex _Float16 when

Re: [PATCH 0/2] Initial support for AVX512FP16

On Tue, 6 Jul 2021, H.J. Lu via Gcc-patches wrote: > > > So the key point is that the soft-fp and avx512fp16 instructions may > > > do not behave the same on the exception, is this acceptable? > > > > I think that's quite often the case for soft-fp. > > So this is a GCC limitation. Please

Re: [PATCH 0/2] Initial support for AVX512FP16

On Tue, 6 Jul 2021, Richard Biener via Gcc-patches wrote: > > /* Look for a wider mode of the same class for which we think we > > can open-code the operation. Check for a widening multiply at the > > wider mode as well. */ > > > > if (CLASS_HAS_WIDER_MODES_P (mclass) > > &&

Re: [PATCH 0/2] Initial support for AVX512FP16

On Tue, 6 Jul 2021, Hongtao Liu via Gcc-patches wrote: > There may be inconsistent behavior between soft-fp and avx512fp16 > instructions if we emulate _Float16 w/ float . > i.e > 1) for a + b - c where b and c are variables with the same big value > and a + b is NAN at _Float16 and real value

Re: [PATCH] Darwin, configury : Allow for specification and detection of dsymutil.

On Mon, 5 Jul 2021, Iain Sandoe wrote: > Hello Joseph, > > > On 5 Jul 2021, at 21:21, Joseph Myers wrote: > > > > On Sun, 4 Jul 2021, Iain Sandoe wrote: > > > >>* configure.ac: Handle --with-dsymutil in the same way as we > >>do for th

Re: [PATCH] Darwin, configury : Allow for specification and detection of dsymutil.

On Sun, 4 Jul 2021, Iain Sandoe wrote: > * configure.ac: Handle --with-dsymutil in the same way as we > do for the assembler and linker. (DEFAULT_DSYMUTIL): New. > Extract the type and version for the dsymutil configured or > found by the default searches. This is

Re: Atomic operations on floating-point data types

On Mon, 5 Jul 2021, Thomas Schwinge wrote: > But: why, what's the rationale? Are potential floating point exceptions > the problem, maybe? "Simply, because nobody bothered implementing it __atomic_* more or less correspond to some of the atomic_* operations in , which only include

Re: [PATCH] Add optional _Float16 support

On Thu, 1 Jul 2021, H.J. Lu wrote: > BTW, _Float16 software emulation may require more than just SSE > since we need to do _Float16 load and store with XMM registers. > There is no 16bit load/store for XMM registers without AVX512FP16. You should be able to make the move go via general-purpose

Re: [PATCH] Add optional _Float16 support

On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote: > 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers. That restricts use of _Float16 to processors with SSE. Is that what we want in the ABI, or should _Float16 be available with base 32-bit x86 architecture features

Re: [PATCH 56/62] AVX512FP16: Optimize (_Float16) sqrtf ((float) f16) to sqrtf16 (f16).

On Thu, 1 Jul 2021, Richard Biener via Gcc-patches wrote: > > C++ FE doesn't support _FLoat16, and the place float/double are > > handled is in convert.c(which is GENERIC?), that's why I decided to do > > it in the backend. I think there ought to be a preliminary patch series adding whatever

Re: [PATCH 0/2] Initial support for AVX512FP16

On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote: > The main issue is complex _Float16 functions in libgcc. If _Float16 doesn't > require -mavx512fp16, we need to compile complex _Float16 functions in > libgcc without -mavx512fp16. Complex _Float16 performance is very > important for our

Re: [PATCH 58/62] AVX512FP16: Optimize for code like (_Float16) __builtin_ceif ((float) f16).

On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote: > +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16) > + since it's not handled in frontend. */ Much the same comments apply as for sqrt. But in this case, the conversion code is in match.pd - right now, specific to pairs

Re: [PATCH 56/62] AVX512FP16: Optimize (_Float16) sqrtf ((float) f16) to sqrtf16 (f16).

On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote: > +/* Optimize for code like (_Float16) __builtin_sqrtf ((float) f16) > + since it's not handled in frontend. */ If correct, it *should* be handled in front end (well, middle-end). See what convert.c:convert_to_real_1 does, with a long

Re: [PATCH 0/2] Initial support for AVX512FP16

Some general comments, following what I said on libc-alpha: 1. Can you confirm that the ABI being used for 64-bit, for _Float16 and _Complex _Float16 argument passing and return, follows the current x86_64 ABI document? 2. Can you confirm that if you build with this instruction set extension

Re: RFC: --help for Driver options (was: [Patch] gcc.c: Add -foffload= to display_help)

On Wed, 30 Jun 2021, Tobias Burnus wrote: > While looking at that issue, Jakub and I wondered whether there > should be some warning if a Driver option has a help text, > which never appears. Migrating from hardcoded help text in gcc.c to using .opt help text for Driver options to generate

Re: [COMMITTED V10 3/7] CTF/BTF debug formats

On Tue, 29 Jun 2021, David Edelsohn via Gcc-patches wrote: > On Tue, Jun 29, 2021 at 10:33 AM Joseph Myers wrote: > > > > There's now a build failure for sparc64-linux-gnu: > > > > In file included from ./tm_p.h:4:0, > > from /scratch/jmyers/

Re: [COMMITTED V10 3/7] CTF/BTF debug formats

There's now a build failure for sparc64-linux-gnu: In file included from ./tm_p.h:4:0, from /scratch/jmyers/glibc-bot/src/gcc/gcc/ctfout.c:24: /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sparc/sparc-protos.h:46:47: error: use of enum 'memmodel' without previous declaration

Re: [PATCH] Port GCC documentation to Sphinx

Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Port GCC documentation to Sphinx

Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? -- Joseph S. Myers jos...@codesourcery.com

Re: GCC documentation: porting to Sphinx

On Wed, 23 Jun 2021, Martin Liška wrote: > @Joseph: Can you share your thoughts about the used Makefile integration? What > do you suggest for 2) > (note that explicit listing of all .rst file would be crazy)? You can write dependencies on e.g. doc/gcc/*.rst (which might be more files than

Re: GCC documentation: porting to Sphinx

On Wed, 23 Jun 2021, Martin Liška wrote: > @Joseph: Can you share your thoughts about the used Makefile integration? What > do you suggest for 2) > (note that explicit listing of all .rst file would be crazy)? You can write dependencies on e.g. doc/gcc/*.rst (which might be more files than

Re: [PATCH RFA] expand: empty class return optimization [PR88529]

This introduces an ICE building libgomp for ColdFire, as detected by my glibc bot. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170 -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] gcc/configure.ac: fix register issue for global_load assembler functions

On Thu, 17 Jun 2021, Marcel Vollweiler wrote: > Thank you for your proposals. I adapted configure.ac and gcn.c > accordingly (similar to the GATHER_STATISTICS example). Thanks, the configure changes in this version are OK. -- Joseph S. Myers jos...@codesourcery.com

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote: > It seems a bit dangerous to me to rely on just extracting PR numbers from > tests. What if the patch is just adjusting a test to make it compatible with > the remainder of the change? Also, that a test is added for a PR, or a commit is

Re: [PATCH] gcc/configure.ac: fix register issue for global_load assembler functions

On Wed, 16 Jun 2021, Julian Brown wrote: > > +if test x$gcc_cv_as_gcn_global_load_fixed = xyes; then > > + AC_DEFINE(HAVE_GCN_ASM_GLOBAL_LOAD_FIXED, 1, [Define if your > > assembler has fixed global_load functions.]) > > +else > > + AC_DEFINE(HAVE_GCN_ASM_GLOBAL_LOAD_FIXED, 0,

Re: [PATCH 0/3]: C N2653 char8_t implementation

On Fri, 11 Jun 2021, Tom Honermann via Gcc-patches wrote: > The option is needed because it impacts core language backward compatibility > (for both C and C++, the type of u8 string literals; for C++, the type of u8 > character literals and the new char8_t fundamental type). Lots of new features

Re: [PATCH v2] inline-asm: Fix ICE with bitfields in "m" operands [PR100785]

On Fri, 11 Jun 2021, Jakub Jelinek via Gcc-patches wrote: > gcc/c/ > * c-typeck.c (c_mark_addressable): Diagnose trying to make > bit-fields addressable. The C front-end changes are OK. -- Joseph S. Myers jos...@codesourcery.com

Re: GCC documentation: porting to Sphinx

On Fri, 11 Jun 2021, Martin Liška wrote: > > Where languages have their own manuals, I think it's more appropriate for > > those to go under the language-specific directories. > > So it will require the following folder structure: > > $gccroot/gcc/doc/gcc - for GCC documentation >

Re: GCC documentation: porting to Sphinx

On Fri, 11 Jun 2021, Martin Liška wrote: > > Where languages have their own manuals, I think it's more appropriate for > > those to go under the language-specific directories. > > So it will require the following folder structure: > > $gccroot/gcc/doc/gcc - for GCC documentation >

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Fri, 11 Jun 2021, Jonathan Wakely via Gcc wrote: > If you're not already doing a brief "subject" line in your git > commits, you're Doing It Wrong! If you don't have a subject line which is more than one word, and does not look like a ChangeLog header line, and which is followed by a blank

Re: GCC documentation: porting to Sphinx

On Thu, 10 Jun 2021, Martin Liška wrote: > 1) Can we organize the new documentation in $gccroot/doc folder > similarly to what I have in texi2rst-generated repo? Would be beneficial > as we can have a single Makefile and shared content will be in a same > depth to the individual manuals.

Re: GCC documentation: porting to Sphinx

On Thu, 10 Jun 2021, Martin Liška wrote: > 1) Can we organize the new documentation in $gccroot/doc folder > similarly to what I have in texi2rst-generated repo? Would be beneficial > as we can have a single Makefile and shared content will be in a same > depth to the individual manuals.

Re: [PATCH 1/3]: C N2653 char8_t: Language support

Also, it seems odd to add a new field to cpp_options without any code in libcpp that uses the value of that field. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 1/3]: C N2653 char8_t: Language support

On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote: > When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE macro > is predefined. This is the mechanism proposed to glibc to opt-in to > declarations of the char8_t typedef and c8rtomb and mbrtoc8 functions proposed > in

Re: [PATCH 0/3]: C N2653 char8_t implementation

On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote: > These changes do not impact default gcc behavior. The existing -fchar8_t > option is extended to C compilation to enable the N2653 changes, and > -fno-char8_t is extended to explicitly disable them. N2653 has not yet been > accepted by

Re: GCC documentation: porting to Sphinx

On Thu, 3 Jun 2021, Martin Liška wrote: > On 6/2/21 6:44 PM, Joseph Myers wrote: > > On Wed, 2 Jun 2021, Joel Sherrill wrote: > > > > > For RTEMS, we switched from texinfo to Sphinx and the dependency > > > on Python3 for Sphinx has caused a bit of hassle. I

Re: GCC documentation: porting to Sphinx

On Thu, 3 Jun 2021, Martin Liška wrote: > On 6/2/21 6:44 PM, Joseph Myers wrote: > > On Wed, 2 Jun 2021, Joel Sherrill wrote: > > > > > For RTEMS, we switched from texinfo to Sphinx and the dependency > > > on Python3 for Sphinx has caused a bit of hassle. I

Re: GCC documentation: porting to Sphinx

On Mon, 31 May 2021, Martin Liška wrote: > https://splichal.eu/scripts/sphinx/ Looking at some examples there: https://splichal.eu/scripts/sphinx/gcc/_build/html/c-implementation-defined-behavior/preprocessing-directives.html has some conversion problems: * "See Implementation-defined

Re: GCC documentation: porting to Sphinx

On Mon, 31 May 2021, Martin Liška wrote: > https://splichal.eu/scripts/sphinx/ Looking at some examples there: https://splichal.eu/scripts/sphinx/gcc/_build/html/c-implementation-defined-behavior/preprocessing-directives.html has some conversion problems: * "See Implementation-defined

Re: GCC documentation: porting to Sphinx

On Wed, 2 Jun 2021, Joel Sherrill wrote: > For RTEMS, we switched from texinfo to Sphinx and the dependency > on Python3 for Sphinx has caused a bit of hassle. Is this going to be > an issue for GCC? What Sphinx (and, thus, Python) versions does the GCC manual build work with? Can it work with

Re: GCC documentation: porting to Sphinx

On Wed, 2 Jun 2021, Joel Sherrill wrote: > For RTEMS, we switched from texinfo to Sphinx and the dependency > on Python3 for Sphinx has caused a bit of hassle. Is this going to be > an issue for GCC? What Sphinx (and, thus, Python) versions does the GCC manual build work with? Can it work with

Re: Update to GCC copyright assignment policy

On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > The copyright author will be listed as "Free Software Foundation, > Inc." and/or "The GNU Toolchain Authors", as appropriate. And copyright notices naming "The GNU Toolchain Authors" should not include a date - that's following the

Re: [Patch] OpenMP: Add iterator support to Fortran's depend; add affinity clause

On Thu, 27 May 2021, Tobias Burnus wrote: > @Joseph: I CC'ed you in case you have comments regarding > c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update) > and c_parser_check_tight_balanced_raw_token_sequence (new); the latter > is essentially cp_parser_skip_balanced_tokens

Re: RFA: save/restore target options in handle_optimize_attribute

This commit breaks the build of glibc for powerpc64le-linux-gnu. Compile the following code with -O2 -mlong-double-128 -mabi=ibmlongdouble and I get the error opts-bug.c:8:1: error: '-mabi=ibmlongdouble' requires '-mlong-double-128' 8 | { | ^ which is clearly nonsensical, since

Re: [PATCH][DOCS] Remove install-old.texi

On Tue, 25 May 2021, Martin Liška wrote: > +@quotation > +aix@var{version}, amdhsa, aout, cygwin, darwin@var{version} Missing comma at the end of this line. > +eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32, > +elfbare, elfoabi, freebsd@var{version}gnu, hpux, hpux@var{version}, Missing

Re: [PATCH] Pass the number of bytes to push to PUSH_ARGS

On Sat, 22 May 2021, H.J. Lu via Gcc-patches wrote: > 1. Update PUSH_ARGS to accept an argument. When the PUSH instruction > usage is optional, pass the number of bytes to push to PUSH_ARGS so that > the backend can decide if PUSH instructions should be generated. > 2. Change x86 PUSH_ARGS to

Re: [PATCH][DOCS] Remove install-old.texi

On Fri, 21 May 2021, Martin Liška wrote: > CPUs: > aarch64, alpha, alpha64, amdgcn, arc, arceb, arm, avr, bfin, bpf, cr16, cris, > csky, epiphany, fido, fr30, frv, ft32, h8300, hppa, hppa2.0, hppa64, i486, > i686, ia64, iq2000, lm32, m32c, m32r, m32rle, m68k, mcore, microblaze, mips, > mips64,

Re: GCC Rust git branch

On Mon, 24 May 2021, Philip Herron wrote: > remote: error: hook declined to update refs/heads/gccrs refs/heads/gccrs doesn't match the branch naming conventions as documented at https://gcc.gnu.org/git.html (where you'd use refs/heads/devel/* for shared development branches), so if you hadn't

Re: [PATCH] handle VLAs with arbitrary many bounds (PR 100619)

On Wed, 19 May 2021, Martin Sebor via Gcc-patches wrote: > The GCC 11 -Warray-parameter and -Wvla-parameter enhancement uses > a small local buffer to format the description of the VLA bounds > for the internal attribute access. When the number of bounds is > in excess of the size of the buffer

Re: [PATCH] c: Add support for __FILE_NAME__ macro (PR c/42579)

On Wed, 19 May 2021, Christophe Lyon via Gcc-patches wrote: > On Wed, 19 May 2021 at 16:50, Joseph Myers wrote: > > > > This patch is missing documentation (in cpp.texi) and tests for the value > > of the macro. > > > > Indeed. How about this new version?

Re: [PATCH][DOCS] Remove install-old.texi

On Wed, 19 May 2021, Martin Liška wrote: > > I'm not sure where this list comes from > > I split parts in contrib/config-list.mk and printed them. > > > but I'd expect "linux" to be the > > canonical "linux-gnu", along with "linux-uclibc", "linux-android", > > "linux-musl" ("uclibc" etc. aren't

Re: [PATCH] c: Add support for __FILE_NAME__ macro (PR c/42579)

This patch is missing documentation (in cpp.texi) and tests for the value of the macro. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] c: don't drop typedef information in casts

On Tue, 18 May 2021, David Lamparter wrote: > On Fri, May 07, 2021 at 06:09:35PM +0200, David Lamparter wrote: > > The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name, > > resulting in all information about the typedef's involvement getting > > lost. This drops necessary

Re: [PATCH][DOCS] Remove install-old.texi

On Tue, 18 May 2021, Martin Liška wrote: > +@quotation > +aix7.1, aix7.2, amdhsa, androideabi, aout, cygwin, darwin, darwin10, darwin7, > +darwin8, darwin9, eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32, > +elfbare, elfoabi, freebsd4, freebsd6, gnu, hpux, hpux10.1, hpux11.0, > hpux11.3,

Re: [PATCH][v2] c/100547 - reject overly large vector_size attributes

On Mon, 17 May 2021, Richard Biener wrote: > This rejects a number of vector components that does not fit an 'int' > which is an internal limitation of RTVEC. This requires adjusting > gcc.dg/attr-vector_size.c which checks for much larger > supported vectors. Note that the RTVEC limitation is

Re: [PATCH][DOCS] Remove install-old.texi

On Mon, 17 May 2021, Martin Liška wrote: > -@enumerate > -@item > -If you have chosen a configuration for GCC which requires other GNU > -tools (such as GAS or the GNU linker) instead of the standard system > -tools, install the required tools in the build directory under the names > -@file{as},

Re: [PATCH] avoid erroneous VLA bounds (PR 100550)

On Wed, 12 May 2021, Martin Sebor via Gcc-patches wrote: > An erroneous VLA parameter bound in a function redeclaration causes > an ICE as the -Wvla-parameter is trying to format a diagnostic after > an error has already been issued. The attached change prevents > such parameters from being

[committed] preprocessor: Support C2X #elifdef, #elifndef

C2X adds #elifdef and #elifndef preprocessor directives; these have also been proposed for C++. Implement these directives in libcpp accordingly. In this implementation, #elifdef and #elifndef are treated as non-directives for any language version other than c2x and gnu2x (if the feature is

[committed] preprocessor: Fix cpp_avoid_paste for digit separators

The libcpp function cpp_avoid_paste is used to insert whitespace in preprocessed output where needed to avoid two consecutive preprocessing tokens, that logically (e.g. when stringized) do not have whitespace between them, from being incorrectly lexed as one when the preprocessed input is reread

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On Tue, 11 May 2021, David Brown wrote: > It is also worth noting that gcc already has support for saturating > types on some targets: > > > > My testing of these (quite a long time ago) left me with a feeling that > it was not a feature

[committed] preprocessor: Enable digit separators for C2X

C2X adds digit separators, as in C++. Enable them accordingly in libcpp and c-lex.c. Some basic tests are added that digit separators behave as expected for C2X and are properly disabled for C11; further test coverage is included in the existing g++.dg/cpp1y/digit-sep*.C tests. Bootstrapped

Re: State of AutoFDO in GCC

On Mon, 10 May 2021, Andi Kleen via Gcc wrote: > It's difficult to find now because it was a branch in the old SVN that wasn't > converted. Sadly the great git conversion was quite lossy. All branches and tags, including deleted ones, were converted (under not-fetched-by-default refs in some

[committed] preprocessor: Fix pp-number lexing of digit separators [PR83873, PR97604]

When the preprocessor lexes preprocessing numbers in lex_number, it accepts digit separators in more cases than actually permitted in pp-numbers by the standard syntax. One thing this accepts is adjacent digit separators; there is some code to reject those later, but as noted in bug 83873 it

Re: testsuite: gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl

On Tue, 4 May 2021, Christophe Lyon via Gcc-patches wrote: > The new test gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl(), > which may not be available, for instance on aarch64-elf with newlib. > As discussed in the PR, requiring c99_runtime enables to skip the test > in this case. > >

RE: [RFC v2] bpf.2: Use standard types and attributes

On Wed, 5 May 2021, David Laight via Libc-alpha wrote: > > __u64 can't be formatted with %llu on all architectures. That's not > > true for uint64_t, where you have to use %lu on some architectures to > > avoid compiler warnings (and technically undefined behavior). There are > > preprocessor

<    3   4   5   6   7   8   9   10   11   12   >