Re: [PATCH] Builtin function roundeven folding implementation

On Fri, 28 Jun 2019, Tejas Joshi wrote: > +CASE_CFN_ROUNDEVEN: > +CASE_CFN_ROUNDEVEN_FN: > + if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math) Checking flag_errno_math here does not make sense. roundeven never sets errno (at least, TS 18661-1 makes it implementation-defined whether

Re: Start implementing -frounding-math

On Mon, 24 Jun 2019, Marc Glisse wrote: > > OK, fair enough. I just hoped that global > > > > double x = 1.0/3.0; > > > > do not become runtime initializers with -frounding-math ... > > Ah, I wasn't thinking of globals. Ignoring the new pragma fenv_round, which I > guess could affect this (the

Re: Start implementing -frounding-math

On Thu, 8 Aug 2019, Marc Glisse wrote: > > FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the > > On the glibc side I expect it to be a lot of work, it seems to require a > correctly rounded version of all math functions... No, it doesn't. 18661-4 reserves cr* names for correctly

Re: Start implementing -frounding-math

On Mon, 24 Jun 2019, Richard Biener wrote: > On the patch I'd name _DIV _RDIV (to match the tree code we are dealing > with). You miss _NEGATE and also the _FIX_TRUNC and _FLOAT in > case those might trap with -ftrapping-math. There are also internal Negation (and abs and copysign) can never ra

Re: Start implementing -frounding-math

On Sun, 23 Jun 2019, Marc Glisse wrote: > For constant expressions, I see a difference between > constexpr double third = 1. / 3.; > which really needs to be done at compile time, and > const double third = 1. / 3.; > which will try to evaluate the rhs as constexpr, but where the program is > stil

Re: Start implementing -frounding-math

On Sat, 22 Jun 2019, Marc Glisse wrote: > as discussed in the PR, this seems like a simple enough approach to handle > FENV functionality safely, while keeping it possible to implement > optimizations in the future. Could you give a high-level description of the implementation approach, and how

Re: C++ PATCH for c++/60364 - noreturn after first decl not diagnosed (v2)

On Thu, 20 Jun 2019, Marek Polacek wrote: > Sorry about that. Does this patch work? Yes, that fixes it, thanks. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFC] zstd as a compression algorithm for LTO

Any use of a host library should come with associated configure options to specify header and library paths for that library (and documentation for those options). (See existing --with-gmp*, --with-isl* etc. options.) -- Joseph S. Myers jos...@codesourcery.com

Re: C++ PATCH for c++/60364 - noreturn after first decl not diagnosed (v2)

This (commit r272486) introduces an ICE building libstdc++-v3 for sh4-linux-gnu. libtool: compile: /scratch/jmyers/glibc-bot/build/compilers/sh4-linux-gnu/gcc/./gcc/xgcc -shared-libgcc -B/scratch/jmyers/glibc-bot/build/compilers/sh4-linux-gnu/gcc/./gcc -nostdinc++ -L/scratch/jmyers/glibc-bo

Re: [committed, amdgcn] Add -march=gfx906 for Vega20

On Thu, 6 Jun 2019, Andrew Stubbs wrote: > This patch adds a new -march=gfx906 option, and a new multilib to go with it. This is missing an invoke.texi update. -- Joseph S. Myers jos...@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote: > > For email addresses, I think that using @gcc.gnu.org would be the best > > approach for people that have such accounts, rather than an employer > > address from an arbitrary point in time. > > Or @gnu.org for accounts that pre-date the switc

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Wed, 5 Jun 2019, Jason Merrill wrote: > > I think failing to credit (by name and email address) the person implied > > by the commit metadata, in the absence of positive evidence (such as a > > ChangeLog entry) for the change being authored by someone else, is just > > wrong, in the same way it

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Sun, 2 Jun 2019, Segher Boessenkool wrote: > > > Git has an identity (well, two) _per commit_, and there is no way you can > > > reconstruct people's prefered name and email address (at any point in > > > time, > > > for every commit separately) correctly. IMO it is much better to not even >

Re: [PATCH] detect references to statics in inline function signatures (PR 88718)

I already reviewed two versions of this patch. As far as I know, no third version has been posted to address my comments on the second version . -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

On Thu, 30 May 2019, Alex Henrie wrote: > In Wine we need a way to (without warnings) put ms_hook_prologue into > a macro that is applied to functions, function pointers, and function > pointer typedefs. It sounds like you're saying that you will not > accept a patch that silences or splits off wa

Re: value_range_base::{non_zero_p, set_zero, set_non_zero}

On Thu, 30 May 2019, Martin Sebor wrote: > This, of course, is in contrast to things like bit-field and > built-in where the convention calls for the hyphen but where For both bit-field and nonzero what we do in documentation is consistent with the C standard, even if code is less consistent. (

Re: CFV: "C++ programming in GNU" interest group (possibly including coding standard development)

On Thu, 30 May 2019, Mike Stump wrote: > On May 30, 2019, at 10:55 AM, James Youngman wrote: > > I'm looking into creating a C++ coding standard for GNU programs. > > So, parts of how we do C++ isn't really relevant to a larger community. > We at times cater to a C legacy and in a pure C++ pro

Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

On Thu, 30 May 2019, Alex Henrie wrote: > At this point I think I'm convinced that any attribute that applies to > a function should also be allowed on a function pointer without any > warnings. We can start by turning off the warnings for the "fndecl" > attributes and then clean up the other attr

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Wed, 29 May 2019, Segher Boessenkool wrote: > On Wed, May 29, 2019 at 12:53:30AM +0000, Joseph Myers wrote: > > On Fri, 24 May 2019, Segher Boessenkool wrote: > > > > > IMO the best we can do is use what we already have: what CVS or SVN used > > > as the co

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Fri, 24 May 2019, Segher Boessenkool wrote: > IMO the best we can do is use what we already have: what CVS or SVN used > as the committer identity. *That* info is *correct* at least. CVS and SVN have a local identity. git has a global identity. I consider it simply *incorrect* to put a loc

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Tue, 21 May 2019, Segher Boessenkool wrote: > > I think having author names and email addresses is a basic requirement of > > any reasonable repository conversion > > Yes, and they should be the same as they were in the original repository. That's what the "changelogs" feature in reposurgeon

Re: *Ping* Re: [PATCH] PR c/43673 - Incorrect warning in dfp printf.

On Tue, 21 May 2019, Jeff Law wrote: > On 5/20/19 6:56 PM, luoxhu wrote: > > Ping for GCC-10. > I thought this was a NAK in its current form. > > See Ryan's c#1 in the BZ. I don't see that as relevant to this bug report. That comment is about the question of how GCC can know whether libc's pri

Re: [PATCH] fix diagnostic quoting/spelling in rs6000

Where you refer to 'homogeneous % aggregates', are such aggregates in the rs6000 case (or in the case where the ABI changed) really restricted to the type float, or do they apply more generally to some other floating-point types so that expanding "float" to a longer description would be the app

Re: State of the reposurgeon conversion

On Mon, 20 May 2019, Jakub Jelinek wrote: > On Mon, May 20, 2019 at 10:16:26AM +0200, Richard Biener wrote: > > There's not many details there but I always thought that the > > "interesting" parts of the GCC history (official branches and trunk) > > do _not_ contain merge commits so the GCC histor

Re: State of the reposurgeon conversion

On Mon, 20 May 2019, Richard Biener wrote: > There's not many details there but I always thought that the > "interesting" parts of the GCC history (official branches and trunk) > do _not_ contain merge commits so the GCC history forms a tree > rather than a DAG. (I'm not sure if there's an easy w

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Fri, 17 May 2019, Jason Merrill wrote: > Thanks for looking into this. My feeling has been that, if we give up > on reposurgeon, there's no need to start a new conversion at all: we > can just switch the current mirror over to being the primary > repository with some minor surgery (e.g. using

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Fri, 17 May 2019, Richard Sandiford wrote: > We're not starting from scratch on that though. The public git > (semi-)mirror has been going for a long time, so IMO we should just > inherit the policies for that. (Like you say, forced pushed are > restricted to the user namespace.) Policies ca

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

Another couple of issues in the change as committed: > + GCC_BAD ("%, ignored"); The word "malformed" should be outside the %<%>. > +Warn about GCC format strings with strings unsuitable for diagnostics.. This help text should end with one '.', not two. -- Joseph S. Myers jos...@codesou

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Thu, 16 May 2019, Maxim Kuvyrkov wrote: > Let's avoid mixing the two discussions: (1) converting svn repo to git > (and getting community consensus to switch to git) and (2) deciding on > which branches to keep in the new repo. > > With git, we can always split away unneeded history by remov

Re: [PATCH] soft-fp: Update soft-fp from glibc

On Wed, 15 May 2019, H.J. Lu wrote: > This patch is updating all soft-fp from glibc, most changes are > copyright years update, and changes other than years update are > > * soft-fp/extenddftf2.c: Use "_FP_W_TYPE_SIZE < 64" to check if > 4_FP_W_TYPEs are used for IEEE quad precision.

Re: [PATCH 5/12] fix diagnostic quoting/spelling in c-family

On Tue, 14 May 2019, Martin Sebor wrote: > The attached patch fixes quoting, spelling, and other formatting > issues in diagnostics issued from files in the c-family/ directory > and pointed out by the -Wformat-diag warning. Some of the changes in this patch are questionable. The diagnostics for

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Tue, 14 May 2019, Maxim Kuvyrkov wrote: > The scripts convert svn history branch by branch. They rely on git-svn > on convert individual branches. Git-svn is a good tool for converting > individual branches. It is, however, either very slow at converting the > entire GCC repo, or goes int

Re: [PATCH] Fix PR 81721: ICE with PCH and Pragma warning and C++ operator

On Mon, 1 Apr 2019, apin...@marvell.com wrote: > From: Andrew Pinski > > Hi, > The problem here is the token->val.node is not saved over > a precompiled header for C++ operator. This can cause an > internal compiler error as we tried to print out the spelling > of the token as we assumed it w

Mention -std=c2x in GCC 9 release notes

This patch adds a mention of -std=c2x and associated options, and the single new C2X feature supported (given the early stage of C2X development when we left development stage 1), to the GCC 9 release notes. Committed. Index: gcc-9/changes.html

Re: [PATCH][stage1] Support profile (BB counts and edge probabilities) in GIMPLE FE.

On Fri, 26 Apr 2019, Richard Biener wrote: > Can you move the GIMPLE/RTL FE specific data in c_declspecs to > a substructure accessed via indirection? I guess enlarging that > isn't really what we should do. You'd move gimple_or_rtl_pass > there and make that pointer one to a struct aux_fe_data

Re: [PATCH, PR d/89823] Update EXCLUDES for updated/removed dmd frontend sources

On Sat, 30 Mar 2019, Iain Buclaw wrote: > Patch updates the EXCLUDES list for message strings that are now > picked up from d/dmd after additions/removals that have happened since > adding sources. Regenerated gcc.pot as per documentation at > https://gcc.gnu.org/translation.html. > > OK for tru

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

This one seems wrong: > - "-fno-strict-aliasing is used"); > + "%<-fno-strict-aliasing is used%>"); (only the option name should be quoted, not "is used"). -- Joseph S. Myers jos...@codesourcery.com

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

On Tue, 19 Mar 2019, Jeff Law wrote: > I'll note that our documentation clearly states that attributes can be > applied to functions, variables, labels, enums, statements and types. A key thing here is that they can be applied to fields - that is, they can be properties of a FIELD_DECL. Referri

Re: [PATCH 0/2] Future warnings not treated as errors

On Tue, 19 Mar 2019, Martin Liška wrote: > On 3/19/19 3:46 AM, Alex Henrie wrote: > > Hello, > > > > I have received permission to contribute to GCC, but I do not have > > commit access. Could one of you please merge these patches for me? > > Hi. > > I can do it for you. But if I see correctly,

Re: [C PATCH] Fix handling of cv on function return type (PR c/89734)

On Mon, 18 Mar 2019, Jakub Jelinek wrote: > Hi! > > The following patch (the second hunk in particular) should fix following > testcase. c_build_qualified_type used to be called unconditionally at that > spot, it was just the changes to use quals_used instead of type_quals there > that made it c

Re: [PATCH] Fix up tree-ssa-strlen.c ICEs (PR tree-optimization/89703)

On Wed, 13 Mar 2019, Jakub Jelinek wrote: > Hi! > > The C FE sadly passes through some really bad prototypes of builtin > functions as "harmless": > /* Accept "harmless" mismatches in function types such > as missing qualifiers or pointer vs same size integer >

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

On Wed, 13 Mar 2019, Richard Biener wrote: > And that fortran support patch would need yet another iteration. Fortran never uses the _finite names because it never uses the C header that can declare the functions to use those asm names. -- Joseph S. Myers jos...@codesourcery.com

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

On Wed, 13 Mar 2019, Jakub Jelinek wrote: > If the finite only doesn't buy anything, then another option is to drop the > math-finite.h stuff or portions thereof. Well, finite-only entry points avoid wrappers for the scalar functions - it's just that suitable optimized implementations could avoi

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

On Wed, 13 Mar 2019, Jakub Jelinek wrote: > Yeah, an alias doesn't really cost much, and has the advantage that if in > the vector version you need at some point to differentiate between the > finite only vs. full implementations, you can just by tweaking libmvec > implementation, the callers will

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

On Tue, 12 Mar 2019, Hans-Peter Nilsson wrote: > When is it appropriate to make the user add -latomic to link > their program? Perhaps different answers for fortran and C++. > I'm guessing "always when using any atomic construct" for C. I think we should link with --as-needed -latomic --no-as-ne

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

On Mon, 11 Mar 2019, Jonathan Wakely wrote: > +proc add_options_for_libatomic { flags } { > +if { [istarget hppa*-*-hpux*] } { > + return "$flags -L../../libatomic/.libs -latomic" > +} It's generally inappropriate to hardcode such ../../libatomic/.libs paths without making sure it'

Re: [PATCH] Define midpoint and lerp functions for C++20 (P0811R3)

On Tue, 5 Mar 2019, Jonathan Wakely wrote: > The midpoint and lerp functions for floating point types come straight > from the P0811R3 proposal, with no attempt at optimization. I don't know whether P0811R3 states different requirements from the public P0811R2, but the implementation of midpoint

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

On Tue, 12 Mar 2019, Richard Biener wrote: > It shouldn't be difficult to provide an alias from the glibc side, no? > How does x86 avoid this issue? There are static-only wrappers in libmvec_nonshared.a to work around the GCC limitation (not included in the shared library, so less efficient th

Re: [PATCH] PR c/89524 - Ignore -Wno-error=

On Thu, 28 Feb 2019, Alex Henrie wrote: > * opts.c: Ignore -Wno-error=. I'd expect this to follow the same logic as how -Wno- is ignored (see the comment on postpone_unknown_option_warning). That is, the option would still be diagnosed if there is some error message that might have been turne

Re: [C PATCH] Fix -Wbuiltin-declaration-mismatch (PR c/89525)

On Wed, 27 Feb 2019, Jakub Jelinek wrote: > Hi! > > As the following testcase shows, with -w we don't emit > -Wbuiltin-declaration-mismatch warnings (correct), but emit weird messages: > ~/src/gcc/obj46/gcc/xgcc -B ~/src/gcc/obj46/gcc/ -w pr89525.c -S > pr89525.c: In function ‘foo’: > pr89525.c:

Re: [PATCH] Fix convert.c ICEs on invalid builtin calls (PR c/89520)

On Wed, 27 Feb 2019, Jakub Jelinek wrote: > Hi! > > convert.c doesn't verify the CALL_EXPRs to builtin functions have exactly > one argument (and a scalar float one) and can ICE if that is not the case > due to K&R declarations of the library functions and passing too few > arguments. > > Fixed

Re: [PATCH] Fix UB in c-format.c (maybe_read_dollar_number) (PR c/89495)

On Mon, 25 Feb 2019, Jakub Jelinek wrote: > Hi! > > The testcases Martin has added recently that contain precision or width > that doesn't fit into int cause UB in the following routine, as 10 * argnum > or that + (*fcp - '0') can result in signed integer overflow. > > The following patch just d

Re: [PATCH] avoid -Wabsolute-value in dead subexpressions (PR 89425)

On Thu, 21 Feb 2019, Martin Sebor wrote: > Joseph noticed the -Wabsolute-value warning newly introduced in GCC > 9 and included in -Wextra triggers on some unreachable subexpressions > in Glibc code that the C front end otherwise makes an effort to avoid > diagnosing. The attached trivial patch g

Re: [PATCH] Fix PR88074

On Wed, 20 Feb 2019, Jakub Jelinek wrote: > + /* mpc_norm assumes it can square a number without bothering with > + with range scaling, so until that is fixed, double the minimum > + and maximum exponents, plus add some buffer for arithmetics > + on the squared numbers. */ No

Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)

On Tue, 19 Feb 2019, Martin Sebor wrote: > Sure, the text is in a section named Program startup, but that doesn't > imply that the constraints apply only at program startup. If they did, I think it's clear from the context that the section is describing the interface between the program and its

Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)

On Sat, 16 Feb 2019, Jakub Jelinek wrote: > Hi! > > Both the C and C++ standard guarantee that the argc argument to main is > non-negative, the following patch sets (or adjusts) the corresponding > SSA_NAME_RANGE_INFO. While main is just one, with IPA VRP it can also > propagate etc. I had to c

Re: [C PATCH] Reject weak nested functions (PR c/89340)

On Fri, 15 Feb 2019, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase, because C nested functions are turned into > !TREE_PUBLIC ones very soon, and the IPA code asserts that DECL_WEAK > functions > are either TREE_PUBLIC or DECL_EXTERNAL. > As we reject static __attribute__((wea

Re: [PATCH] Fix ICE with optimize("Ofast") due to option handling (PR other/89342)

On Thu, 14 Feb 2019, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase, because while we save optimize, > and optimize_{size,debug} vars during option saving/restoring, we don't save > optimize_fast, and because of that end up with optimize 0 optimize_fast 1 > which the option handl

Re: Fortran vector math header

On Tue, 5 Feb 2019, Martin Liška wrote: > #ifdef NATIVE_SYSTEM_HEADER_DIR >/* Then search: /usr/include/finclude/ */ >add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR > "/finclude/", > - NULL, 0, 0, false); > + NULL, 0, 0, 0

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Wed, 13 Feb 2019, H.J. Lu wrote: > Like this? This patch is missing any updates to options.texi to discuss the interation of Negative and RejectNegative with Joined. > diff --git a/gcc/testsuite/gcc.dg/pr69471-1.c > b/gcc/testsuite/gcc.dg/pr69471-1.c > new file mode 100644 > index 0

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Wed, 13 Feb 2019, Jakub Jelinek wrote: > On Tue, Feb 12, 2019 at 11:21:04PM +0000, Joseph Myers wrote: > > I think this is changing architecture-independent code in a way that is > > not clearly safe based on the architecture-independent options design, in > >

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Tue, 12 Feb 2019, H.J. Lu wrote: > > > Prune joined switches with negation to allow -march=skylake-avx512 to > > > override previous -march=native on command-line. > > > > > > PR driver/69471 > > > * opts-common.c (prune_options): Also prune joined switches > > > with ne

Fix type of extern array declared in inner scope with outer initialization shadowed (PR c/88584)

Applied to mainline. gcc/c: 2019-02-06 Joseph Myers PR c/88584 * c-decl.c (finish_decl): Do not complete array types for arrays with external linkage not at file scope. gcc/testsuite: 2019-02-06 Joseph Myers PR c/88584 * gcc.dg/redecl-18.c: New te

Re: [C PATCH] Fix C ICE with K&R definitions (PR c/89211)

On Tue, 5 Feb 2019, Jakub Jelinek wrote: > Hi! > > The r253411 change to improve diagnostics added code to set DECL_ARGUMENTS > to the declarator->u.arg_info->parms. My understanding is that this was > meant for function prototypes, so that we can emit better diagnostics for > those. Unfortunat

Re: Make clear, when contributions will be ignored

On Tue, 5 Feb 2019, Дилян Палаузов wrote: > Will it help, if bugzilla is tweaked to send reminders every two weeks > for ready-patches? This also has the advantage, that people will not > have to once update a patch in BZ and then send it over gcc-patches. For any proposed changes to patch sub

Re: Fortran vector math header

On Mon, 4 Feb 2019, Jakub Jelinek wrote: > > +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64') > > +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386') > > That is all from me, but I think you need a buy-in from the Fortran > maintainers (if they are ok with such an extens

Re: [PATCH/doc] correct cast to a union description (PR 89106)

On Wed, 30 Jan 2019, Martin Sebor wrote: > A change I made a couple of years ago to the Cast To a Union section > of the manual incorrectly stated that the cast yields an lvalue when > it, in fact, yields an rvalue. The attached patch corrects this > mistake and expands the description to further

Re: [C PATCH] Ignore compound literals in -W*misses-init warning (PR c/89061)

On Tue, 29 Jan 2019, Jakub Jelinek wrote: > Hi! > > While gotos across automatic compound literal initialization do > cross their initialization, I can't think of any way how could code after > the label to which the goto bypasses it get access to the uninitialized > compound literal. Even if th

Re: [C PATCH] Fix another compound literal ICE (PR c/89045)

On Mon, 28 Jan 2019, Jakub Jelinek wrote: > Hi! > > In this case, when a compound literal is in the parameter scope of a nested > function, current_function_decl is non-NULL, but we still don't want to > pushdecl it, as the code doesn't expect any VAR_DECLs etc. in parameter > scope. > > Fixed t

Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos

On Mon, 28 Jan 2019, Richard Biener wrote: > On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw wrote: > > > > Hi, > > > > Following on from the last, this adds target-zlib to target_libraries > > and updates libphobos build scripts to link to libz_convenience.a. > > The D front-end already has target-z

Re: [C PATCH] Fix PR86125 fallout

On Sat, 26 Jan 2019, Jakub Jelinek wrote: > Hi! > > Here is an untested patch that should fix all of that, ok for trunk > if it passes bootstrap/regtest on {x86_64,i686}-linux? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)

On Mon, 28 Jan 2019, Martin Sebor wrote: > On 1/25/19 6:25 PM, Joseph Myers wrote: > > It's also broken the build of the glibc testsuite, e.g.: > > > > ../time/time.h:88:15: error: mismatch in argument 1 type of built-in > > function 'strftime'; expected

Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)

It's also broken the build of the glibc testsuite, e.g.: ../time/time.h:88:15: error: mismatch in argument 1 type of built-in function 'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch] 88 | extern size_t strftime (char *__restrict __s, size_t __maxsize, (presence or absence

Re: [PATCH] libgcc2.c: Correct DI/TI -> SF/DF conversions

On Thu, 24 Jan 2019, Christophe Lyon wrote: > On Thu, 24 Jan 2019 at 15:31, Joseph Myers wrote: > > > > On Thu, 24 Jan 2019, Christophe Lyon wrote: > > > > > The attached small patch adds > > > /* { dg-require-effective-target fenv_exceptions } */ >

Re: [PATCH] libgcc2.c: Correct DI/TI -> SF/DF conversions

On Thu, 24 Jan 2019, Christophe Lyon wrote: > The attached small patch adds > /* { dg-require-effective-target fenv_exceptions } */ > to them. It should be a *new* effective-target, because these tests are nothing to do with exceptions; they're about rounding modes (but actually you only need a

Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)

On Wed, 23 Jan 2019, Martin Sebor wrote: > Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html This patch is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] libgcc2.c: Correct DI/TI -> SF/DF conversions

On Wed, 23 Jan 2019, H.J. Lu wrote: > + fesetround (FE_DOWNWARD); > + float fs = s128; > + if (fs != -0x1p+127) > +abort (); > + double ds = s128; > + if (ds != -0x1p+127) > +abort (); This definitely needs #ifdef FE_DOWNWARD; even just limited to glibc configurations, there are sof

Re: [PATCH] avoid assuming arrays have nonzero size (PR 88956)

On Tue, 22 Jan 2019, Martin Sebor wrote: > PS In GCC 10, unless there is an important use case that escapes > me, I think GCC should warn for zero-length non-member array > objects, or perhaps even for internal struct members (those followed > by another member). Not to avoid these sorts of bugs

Re: Fortran vector math header

On Tue, 22 Jan 2019, Richard Biener wrote: > > Or instead just come up with target specific strings to determine the ABI, > > say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000 > > etc. > > Yeah, I would even suggest to use a target hook multilib_ABI_active_p > (const cha

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

On Mon, 21 Jan 2019, H.J. Lu wrote: > The testcase at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931 > > with -frounding-math. __floattisf and __floattidf from libgcc2.c give > the wrong results for FE_UPWARD and FE_TOWARDZERO. I suggest writing a test that looks something like gcc.dg

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

On Tue, 22 Jan 2019, Terry Guo wrote: > Hi Joseph, > > I believe HJ is proposing patch to fix bug > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case > of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are Which isn't supported by GCC. Any test involving roundin

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

On Mon, 21 Jan 2019, H.J. Lu wrote: > TI->SF and TI->DF conversions in libgcc2.c: > > FSTYPE > FUNC (DWtype u) > { > ... > } > > have no rounding mode support. We should replace __floattisf, __floattidf, > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp. Please explain w

Re: Fortran vector math header

On Mon, 21 Jan 2019, Martin Liška wrote: > I like the if('lp64'), if('ilp32') approach and I'm sending patch > candidate for that. Would it be accepted by glibc folks? Since glibc supports libmvec for x86_64, both 64-bit and x32, but not for 32-bit x86, those particular conditionals are insuffi

Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

On Thu, 17 Jan 2019, Jason Merrill wrote: > This updated patch removes {short ,}unsigned int from the expected > diagnostics. And also improves error_init to accept additional arguments, > like pedwarn_init already does. This version is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] detect references to statics in inline function signatures (PR 88718)

On Wed, 16 Jan 2019, Martin Sebor wrote: > + /* Iterate over tentative records (all those at the head of the list > + with a null FUNCTION) and either associate them with DECL when ADD > + is set or remove them from it otherwise. */ > + for (c_inline_static *csi = c_inline_statics, *las

Re: Fortran vector math header

On Wed, 16 Jan 2019, Jakub Jelinek wrote: > Perhaps easier would be to add optional if clause to the !GCC$ builtin > with constant expression argument which if present and evaluates to .false. > would tell us to ignore the attribute. Or, add !GCC$ if/else/end if which > would act like preprocessi

Re: Fortran vector math header

On Wed, 16 Jan 2019, Joseph Myers wrote: > On Wed, 16 Jan 2019, Jakub Jelinek wrote: > > > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or > > defined(__ILP64__) and similar, but in these headers we can't, as no > > preprocessing

Re: Fortran vector math header

On Wed, 16 Jan 2019, Jakub Jelinek wrote: > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or > defined(__ILP64__) and similar, but in these headers we can't, as no > preprocessing is happening. (With such preprocessing, the mechanism glibc uses for gnu/stubs.h and gnu/

Re: Fortran vector math header

On Wed, 16 Jan 2019, Martin Liška wrote: > Now we should add the header file into glibc, I kicked a discussion here: > https://sourceware.org/ml/libc-help/2018-11/msg00015.html libc-help is for user questions. It's not suitable for glibc development discussions. -- Joseph S. Myers jos...@code

Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

On Tue, 15 Jan 2019, Jason Merrill wrote: > I actually incorporated the C++ part of these changes into yesterday's commit, > using Martin's first suggestion. Here's the adjusted C patch, which I'd like > a C maintainer to approve. The front-end changes are OK. However, in the testcase changes,

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

On Mon, 14 Jan 2019, Martin Liška wrote: > Thanks for review, fixed that in updated version of the patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? This patch is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] detect references to statics in inline function signatures (PR 88718)

On Fri, 11 Jan 2019, Martin Sebor wrote: > gcc/testsuite/ChangeLog: > > PR c/88718 > * gcc.dg/inline-40.c: New test. > * gcc.dg/inline-41.c: New test. We already have tests inline-40.c and inline-41.c; these need to be renumbered accordingly. > + if (add) > + { > +

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

On Fri, 11 Jan 2019, Martin Liška wrote: > +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. > */ Actually, it should be prepending target_system_root, but followed by target_sysroot_hdrs_suffix rather than target_sysroot_suffix. That is, this function should be fo

Re: [PATCH, d] Add README for process contributing to dmd and phobos

On Thu, 10 Jan 2019, Iain Buclaw wrote: > Hi, > > Joseph made mention that there isn't a readme documenting where > changes to d/dmd, libphobos/libdruntime, and libphobos/src should go. > > I hope this clears things up. OK for trunk? This sort of patch is clearly covered by D maintainership.

Re: Substitute all "the the" with "the"

On Thu, 10 Jan 2019, Дилян Палаузов wrote: > sed -i "s/the the/the/" `git grep -l "the the"` That looks wrong; there are plenty of instances of "the theory", "the then branch" and similar that should not have such a substitution applied. See Sandra's patch submissions for "can not", and the dis

Re: [patch, rfa] Fix PR other/16615, change "can not" to "cannot" throughout docs and code

On Tue, 8 Jan 2019, Sandra Loosemore wrote: > Here are the ChangeLogs for the new patch series. Parts 1, 2, and 3 are > mechanically generated via sed (etc). Part 4 is the hand-edited changes, > identical to part 2 of the previous series except for excluding a couple > files. Part 5 is the rege

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

On Wed, 9 Jan 2019, Joseph Myers wrote: > Also, could you clarify what, in the patch > <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02089.html> (if that's > still the current version), > > > + add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0,

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

On Wed, 9 Jan 2019, Martin Liška wrote: > Hi. > > May I please ping that Joseph. The provided patch should be applicable and > I would need help with the proper locations. I'm not clear if there is a specific question here, or a patch needing review. In

Re: [RFC] Update Stage 4 description

On Wed, 9 Jan 2019, Paul Koning wrote: > Is there, or should there be, a distinction between primary and > non-primary platforms? While platform bugs typically require fixes in > platform-specific code, I would think we would want to stay away from > bugfixes in minor platforms during stage 4.

Re: [PATCH] Don't pushdecl compound literals inside C parameter scope (PR c/88701)

On Mon, 7 Jan 2019, Jakub Jelinek wrote: > Hi! > > As reported recently, my commit to push block scope using pushdecl into > their corresponding scope broke compound literals appearing in parameter > scope. For those, we can keep the previous behavior, where they stayed at > the function scope i

<    7   8   9   10   11   12   13   14   15   16   >