Re: Implement C11 _Atomic

On Thu, 21 Nov 2013, Andrew MacLeod wrote: > > Or is that part also required for > > anything-other-than-ordinary-C-type alignment for the target; > > say, natural 4-byte alignment of 4-byte-types for targets where > > alignment is otherwise "packed"; where only 1-byte alignment of > > the basic ty

Re: Implement C11 _Atomic

On Thu, 21 Nov 2013, Andrew MacLeod wrote: > I can bootstrap and check this on x86 to make sure it doesnt affect anything, > and you can fool with it and see if you can get your desired results with your > port. Success! For the record, tested together with the attached patch for the CRIS ports,

Re: Implement C11 _Atomic

On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote: > with this/these patches > at least I'll be able to tell people that _Atomic for C11 works. Oh right, gcc still doesn't remove target-introduced "manual" alignment checks (when expanding atomic intrinsics), but at least g

Re: Implement C11 _Atomic

On Thu, 21 Nov 2013, Andrew MacLeod wrote: > If we add the hook for atomic_align_for_mode, and change the initalizers in > tree.c, any target which doesnt need/use the hook should be unaffected. So > everything remains as it is today. > > So Putting the hook in shouldn't be an issue. Then you can

Re: Implement C11 _Atomic

On Fri, 22 Nov 2013, Andrew MacLeod wrote: > The target hook patch is checked into mainline, revision 205273. Thanks! The target patch is there too now; tested with the previous version of the hook-patch. I'm confident my autotester will yell at me if I goofed. gcc: * config/cris/cris.c

Re: [PATCH] RTEMS: Update contrib/config-list.mk

On Sat, 20 Sep 2014, Jan-Benedict Glaw wrote: > Please note that nios2 failed in the same way a number of other > targets fail, too: > > cr16-elf > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=351532 > fr30-elf > http://toolchain.lug-owl.de/buildbot/show_build_details.

PATCH: fix breakage from "[PATCH] Fix genmatch linking"

> From: Richard Biener > Date: Thu, 23 Oct 2014 10:47:43 +0200 > This adds a libcpp host module without NLS and ICONV support > and properly links genmatch against the build libcpp instead of > the host one. > > Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc > finished fine). > >

Re: PATCH: fix breakage from "[PATCH] Fix genmatch linking"

> From: Hans-Peter Nilsson > Date: Fri, 24 Oct 2014 06:32:06 +0200 > The libcpp configure checks are actually run with gcc which is > bogus by itself, but apparently working. I guess the C vs. C++ > declaration etc. differences for libcpp are mostly hidden by > using _G

Re: PATCH: fix breakage from "[PATCH] Fix genmatch linking"

> From: Richard Biener > Date: Fri, 24 Oct 2014 09:56:51 +0200 > On Fri, 24 Oct 2014, Hans-Peter Nilsson wrote: > > Still, I don't understand exactly how your patch > > introduces build-subdirectories where there were none before. > > Maybe that "+all-gcc:

Committed: fix MMIX LTO gcc.dg/torture/stackalign/builtin-return-1.c

Apparently LTO improved or at least changed between r21 and r211121, such that memory outside the defined space was wrongly read as "expected" for this test-case, corresponding to the wrongly presumed stacked parameters. For a "normal" target this would correspond to a SEGV. You'd need the me

Re: [Patch] Minor fixes for regtesting gfortran with -flto

On Mon, 5 May 2014, Dominique Dhumieres wrote: > With the following patch, gfortran can be regtested with -flto > with no failure, but pr54852 and pr60061. > > OK for trunk? > > Dominique > > 2014-05-05 Dominique d'Humieres > > * gfortran.dg/gfortran.dg/bind_c_array_params_2.f90: >

Re: [PATCH] GCC/MMIX: Remove orphan mmix_asm_output_source_line prototype

On Tue, 10 Jun 2014, Maciej W. Rozycki wrote: > Hi, > > I've noticed mmix_asm_output_source_line is declared, but nowhere > defined. OK to remove the prototype? Sure; in fact, obvious. brgds, H-P

libstdc++ regressions with "Move DECL_SECTION_NAME into symtab"

On Wed, 11 Jun 2014, Jan Hubicka wrote: > * varasm.c (set_implicit_section): New function. > (resolve_unique_section): Use it to set implicit section > for aliases, too. > (get_named_text_section): Use symtab_get_node (decl)->implicit_section > (default_function_secti

breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

On Sat, 14 Jun 2014, Richard Sandiford wrote: > To make the final representation change easier, this patch introduces > macros for iterating over lists of defs, uses and eq_uses. At the > moment there are three possible keys when accessing df_ref lists: > the insn rtx (DF_INSN_*), the insn uid (D

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

On Sun, 15 Jun 2014, Steven Bosscher wrote: > On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote: > > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void > > merge_in_block(int, basic_block_def*)': > > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote: > On Sun, 15 Jun 2014, Steven Bosscher wrote: > > Can you please try: > > > > [...] > > Thanks. Looks pretty obvious. I was heading for the door with > just enough time to report the issue, so I didn't actual

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote: > On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote: > > On Sun, 15 Jun 2014, Steven Bosscher wrote: > > > Can you please try: > > > > > > [...] > > > > Thanks. Looks pretty obvious. I was heading for

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

On Mon, 16 Jun 2014, Steven Bosscher wrote: > On Mon, Jun 16, 2014 at 12:36 AM, Hans-Peter Nilsson wrote: > > On Sun, 15 Jun 2014, Steven Bosscher wrote: > >> On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote: > >> > /tmp/hpautotest-gcc0/gcc/gcc/aut

Re: [DOC Patch] Explicit Register Variables

On Mon, 30 Jun 2014, David Wohlferd wrote: > I don't have permissions to commit this patch, but I do have a release on file > with the FSF. > > Problem description: > The text for using Explicit Register Variables is confusing, redundant, and > fails to make certain essential information clear. [.

Re: [RFC]: Remove Mem/address type assumption in combiner

On Fri, 1 May 2015, Segher Boessenkool wrote: > On Wed, Apr 29, 2015 at 12:03:35PM -0500, Segher Boessenkool wrote: > > On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote: > > > diff --git a/gcc/combine.c b/gcc/combine.c > > > index 5c763b4..945abdb 100644 > > > --- a/gcc/combine

Re: [RFC]: Remove Mem/address type assumption in combiner

On Sat, 16 May 2015, Segher Boessenkool wrote: > On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote: > > I confess the test-case-"guarded" addi pattern should have been > > expressed with a shift in addition to the multiplication. > > But they wouldn&

Re: [RFC]: Remove Mem/address type assumption in combiner

On Sat, 16 May 2015, Segher Boessenkool wrote: > On Sat, May 16, 2015 at 12:36:38PM -0400, Hans-Peter Nilsson wrote: > > On Sat, 16 May 2015, Segher Boessenkool wrote: > > > On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote: > > > > I confess the te

Re: [RFC]: Remove Mem/address type assumption in combiner

On Sun, 17 May 2015, Segher Boessenkool wrote: > I used ; it has > a README. I see that doc is a little out of date, I'll update. ("git:" not "http:" for cloning) Thanks, looks useful. Hm, maybe we already mention this in the wiki... > > - add

breakage with series "[0/9] Record number of hard registers in a REG"

> From: Richard Sandiford > Date: Mon, 18 May 2015 20:09:19 +0200 > While looking at a profile of gcc, I noticed one thing fairly high > up the list was a loop iterating over all the registers in a REG, > apparently due to the delay in computing the index for hard_regno_nregs > and then loading t

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

> From: "H.J. Lu" > Date: Tue, 19 May 2015 21:20:46 +0200 > This patch affects your target. Can you verify if it is OK on > your target? If you mean philosophically, it's ok when the general bits and direction are ok, but for the practical part of checking e.g. for typos through compilation, pl

Re: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields

On Mon, 16 Mar 2015, Eric Botcazou wrote: > > If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit > > architecture. I doubt that the strict alignment code makes any sense for > > modesize> BIGGEST_ALIGNMENT. > > Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition

Re: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields

On Tue, 17 Mar 2015, Andreas Schwab wrote: > Hans-Peter Nilsson writes: > > > Q: So why not adjust the BIGGEST_ALIGNMENT definition in such > > targets to be at least the natural alignment of supported > > atomic types? > > A: Because it's an ABI change. I i

Re: [libstdc++/65033] Give alignment info to libatomic

On Wed, 25 Mar 2015, Jonathan Wakely wrote: > I've convinced myself that Richard's patch is correct in all cases, > but I think we also want this patch, to fix PR62259 and PR65147. > > For the generic std::atomic (i.e. not the integral or pointer > specializations) we should increase the alignment

Re: [libstdc++/65033] Give alignment info to libatomic

On Thu, 12 Feb 2015, Richard Henderson wrote: > When we fixed PR54005, Hm, there's confusion. When was this fixed? (Not fixed AFAICT.) Maybe you mean PR54004, but there was no note there either. Or maybe there's a typo and you meant some other PR and that PR54005 is supposedly fixed by this pa

Re: [libstdc++/65033] Give alignment info to libatomic

On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote: > Why then use __alignof(_M_i) (the object-alignment) > instead of _S_alignment (the deduced alas insufficiently > increased type-alignment)? (The immediate reason is that _S_alignment wasn't there until a later revision, but the gist o

Re: [libstdc++/65033] Give alignment info to libatomic

On Fri, 3 Apr 2015, Jonathan Wakely wrote: > On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote: > > On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote: > > > Why then use __alignof(_M_i) (the object-alignment) > > > instead of _S_alignment (the deduced alas insufficiently >

Re: [libstdc++/65033] Give alignment info to libatomic

On Thu, 26 Mar 2015, Jonathan Wakely wrote: --- /dev/null +++ b/libstdc++-v3/testsuite/29_atomics/atomic/62259.cc +static_assert(alignof(obj1) == alignof(int64_t), + "std::atomic not suitably aligned" ); + +struct container_struct { + char c[1]; + std::atomic ao; +}; + +container

Re: [libstdc++/65033] Give alignment info to libatomic

On Tue, 7 Apr 2015, Jonathan Wakely wrote: > On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote: > > On Fri, 3 Apr 2015, Jonathan Wakely wrote: > > > > > On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote: > > > > On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote: &

Re: [libstdc++/65033] Give alignment info to libatomic

On Tue, 7 Apr 2015, Jonathan Wakely wrote: > On 07/04/15 06:51 -0400, Hans-Peter Nilsson wrote: > > On Tue, 7 Apr 2015, Jonathan Wakely wrote: > > > On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote: > > > > We did specify that with the alignas. Is the alignof alwa

Re: [libstdc++/65033] Give alignment info to libatomic

On Tue, 7 Apr 2015, Jonathan Wakely wrote: > The docs are clear that alignof(s.x) is not related to its position in > struct SoSo: https://gcc.gnu.org/onlinedocs/gcc/Alignment.html > > I'm not going to worry about that behaviour changing. 'kthen thanks, quite clear; I should have checked that myse

breakage with "[PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)"

On Wed, 8 Apr 2015, Segher Boessenkool wrote: > 2015-04-08 Segher Boessenkool > > * combine.c (is_parallel_of_n_reg_sets): Change first argument > from an rtx_insn * to an rtx. > (try_combine): Adjust both callers. Use it once more. That "once more" is outside of #ifndef HAVE

Re: breakage with "[PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)"

On Thu, 9 Apr 2015, Segher Boessenkool wrote: > I tested a cross to cris-linux and built a Linux kernel with the trivial > patch (attached); doing that for all other cross configs is in progress. Thanks. Using contrib/config-list.mk comes to mind, but might be a bit excessive in this particular c

patch fix issue 1 with "[libstdc++/65033] Give alignment info to libatomic"

>PR libstdc++/62259 >PR libstdc++/65147 >* include/std/atomic (atomic): Increase alignment for types with >the same size as one of the integral types. >* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error line number. >* testsuite/29_atomics/atomi

Issue 2 with "[libstdc++/65033] Give alignment info to libatomic"

(check_cxx_fundamental_alignment_constraints is Dodji's, others CC:ed were already in the thread) Looking into those atomic things and running tests for cris-elf, I get FAIL for libstdc++-v3/testsuite/29_atomics/atomic/65147.cc, specifically struct S16 { char c[16]; }; static_assert( alignof(

Regressions with "[committed] Use target-insns.def for prologue & epilogue insns"

> From: Richard Sandiford > Date: Tue, 30 Jun 2015 22:55:24 +0200 > Bootstrapped & regression-tested on x86_64-linux-gnu and aarch64-linux-gnu. > Also tested via config-list.mk. Committed as preapproved. > > Thanks, > Richard > > > gcc/ > * defaults.h (HAVE_epilogue, gen_epilogue): De

Fixed Regressions with "[committed] Use target-insns.def for prologue & epilogue insns"

> From: Richard Sandiford > Date: Wed, 1 Jul 2015 23:26:59 +0200 > Hans-Peter Nilsson writes: > >> From: Richard Sandiford > >> Date: Tue, 30 Jun 2015 22:55:24 +0200 > > > >> Bootstrapped & regression-tested on x86_64-linux-gnu and aarch64-

Re: Fixed Regressions with "[committed] Use target-insns.def for prologue & epilogue insns"

> From: Richard Sandiford > Date: Thu, 2 Jul 2015 20:58:15 +0200 > Hans-Peter Nilsson writes: > > gcc: > > * config/cris/cris.md ("epilogue"): Remove condition. > > ("prologue"): Ditto. > > Thanks. No, thank *you* for the massiv

Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.

On Fri, 16 Jan 2015, pins...@gmail.com wrote: > > On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote: > > > > This patch has broken bootstrap on AIX > > > > May I mention that this really should have been tested on systems > > other than x86 Linux. > > It also broke all newlib targets too. So you c

Re: Compare-elim pass (was: Re: [PATCH] Fix PR 61225)

(Waking up an old thread with my 2 cents due to being a little behind on reading...) On Sat, 6 Dec 2014, Jakub Jelinek wrote: > On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote: > > > That's already what it does though, did you mean the opposite? Or did you > > > mean to write "combine

Re: Compare-elim pass (was: Re: [PATCH] Fix PR 61225)

On Sat, 17 Jan 2015, Jakub Jelinek wrote: > On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote: > > (Waking up an old thread with my 2 cents due to being a little > > behind on reading...) > > > > On Sat, 6 Dec 2014, Jakub Jelinek wrote: > > >

Re: [PATCH 01/10] rs6000: Clobber XER[CA] in all user asm statements

On Mon, 8 Dec 2014, Segher Boessenkool wrote: > A lot of old user code clobbers the carry bit without telling the compiler > about it. This used to just work, because the compiler never used the bit > outside of a single RTL instruction. But that will change. Let's clobber > the carry bit in ev

Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.

On Mon, 9 Feb 2015, Matthew Wahab wrote: > On 07/02/15 00:11, Jonathan Wakely wrote: > > Any idea why HP still sees the tests fail? See comment 8 at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8 > > It looks like he's found the problem: that _NEWLIB_ is a recent addition that > isn't in

Fix PR65093, timeouts with 26_numerics/random/binomial_distribution/operators/values.cc

Lately, 26_numerics/random/binomial_distribution/operators/values.cc has started to FAIL on trunk with a timeout for my autotester for cris-elf, a soft-float simulator target running a cgen-generated simulator on a six-year-old x86_64-linux-gnu host. The reason it's started to fail in the last few

Re: RFA: fix PR90553, IRA assigning a call-clobbered reg to call with post-increment

> From: Vladimir Makarov > Date: Tue, 21 May 2019 17:05:50 -0400 > Yes, the patch is ok to commit.  Thank you for working on the problem. > > It is hard to reproduce the same problem in LRA as LRA mostly follows > IRA decisions. > > I'll probably do the analogous patch for LRA on this week. T

Re: [PATCH] Support again multiple --help options (PR other/90315).

Ping, on behalf of Martin, CC:ing diagnostics maintainers. On Fri, 3 May 2019, Martin Li?ka wrote: > Hi. > > The patch prints all values requested in multiple --help options. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin >

Fixed: "required ftruncate or chsize support not present" in gfortran testsuite

There was a regression for gfortran.dg/fmt_en.f90 for cris-elf that on inspection was due to it having acquired a truncation call through the runtime. I updated that and the new tests that had "Fortran runtime error: required ftruncate or chsize support not present" messages in gfortran.log, ran p

Fix simulator timeout for testsuite/26_numerics/random/poisson_distribution/operators/values.cc

This test regressed for cris-elf (testing in a simulator) with the fixing of libstdc++/83237, as the part suggested to be wrapped in #ifndef was *added* to the existing test and causes a timeout. Tsk tsk. Please don't pile-on existing tests, instead add a *separate* test-file. >From what I under

Re: Fixed: "required ftruncate or chsize support not present" in gfortran testsuite

> From: Janne Blomqvist > Date: Thu, 23 May 2019 23:43:23 +0300 > On Thu, May 23, 2019 at 5:21 AM Hans-Peter Nilsson > wrote: > > > > There was a regression for gfortran.dg/fmt_en.f90 for cris-elf > > that on inspection was due to it having acquired a truncation &g

Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

TL;DR: instead of capping TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE, search for the largest fitting size from scalar_int_mode modes supported by the target using targetm.scalar_mode_supported_p. - In initialize_sizetypes, MAX_FIXED_MODE_SIZE is used as an upper limit to the *pre

Re: Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

> From: Richard Biener > Date: Wed, 29 May 2019 15:04:42 +0200 > On Tue, May 28, 2019 at 5:43 PM Hans-Peter Nilsson > wrote: > > > > TL;DR: instead of capping TYPE_PRECISION of bitsizetype at > > MAX_FIXED_MODE_SIZE, search for the largest fitting size from >

Re: Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

> From: Eric Botcazou > Date: Wed, 05 Jun 2019 22:03:04 +0200 > > This issue exists, not just for targets that can have their > > MAX_FIXED_MODE_SIZE more-or-less easily tweaked higher, but also > > for the 'bit-container' targets where it *can't* be set higher. > > > > Let's please DTRT and cor

Re: Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

> Date: Thu, 6 Jun 2019 16:04:47 +0200 > From: Hans-Peter Nilsson > When bitsizetype objects end > up on the target, they use the actual Pmode and not the larger > precision mode. Oops, a half-way-done email slipped away, this part still needs to be investigated. I don't r

Re: Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

Thu, 06 Jun 2019 00:59:40 -0700 (PDT) > References: <201906051938.x55jcssw016...@ignucius.se.axis.com> > <18571728.MIQ1nkMWVm@polaris> > From: Richard Biener > Date: Thu, 6 Jun 2019 09:59:29 +0200 > Cc: Hans-Peter Nilsson , > GCC Patches > Old-Content-Type

Re: [ping] Change static chain to r11 on aarch64

On Wed, 12 Dec 2018, Wilco Dijkstra wrote: > I've not seen such an alternative implementation (-fno-trampolines is > ignored on all targets I tried), but it wouldn't affect the ABI since you can > only take the address of a nested function when you're the parent function. Regarding the trampoline-

Re: [ping] Change static chain to r11 on aarch64

On Mon, 17 Dec 2018, Wilco Dijkstra wrote: > H-P: > > So, changing from R18 to R11 for aarch64 seems right, as the > > latter is call-clobbered and the former is call-saved IIUC. > > The AArch64 ABI defines x18 as platform specific: > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI005

Re: [ping] Change static chain to r11 on aarch64

On Mon, 17 Dec 2018, Hans-Peter Nilsson wrote: > On Mon, 17 Dec 2018, Wilco Dijkstra wrote: > > H-P: > > > So, changing from R18 to R11 for aarch64 seems right, as the > > > latter is call-clobbered and the former is call-saved IIUC. > > > > The AArch

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

On Tue, 18 Dec 2018, Uecker, Martin wrote: > Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker: > > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek: > > > On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote: > > > > Right.  This is the classic example and highlights

Re: [PATCH AutoFDO]Restoring indirect call value profile transformation

On Tue, 18 Dec 2018, Andi Kleen wrote: > > Yes, take g++.dg/tree-prof/morefunc.C as an example: > > - int i; > > - for (i = 0; i < 1000; i++) > > + int i, j; > > + for (i = 0; i < 100; i++) > > +for (j = 0; j < 50; j++) > > g += tc->foo(); > > if (g<100) g++; > > } > > @@ -2

Re: Using gcc/ChangeLog instead of gcc/testsuite/ChangeLog?

> From: Jakub Jelinek > Date: Sat, 10 Aug 2019 12:12:46 +0200 > I ran the gcc/ subdirectory ChangeLogs through following script that doesn't > seem to have false positives ATM except one... > # Date not separated from name by two spaces, but just one. [...] > # Email not wrapped in <>s. > grep

Re: [PATCH][testsuite] Fix PR91419

> From: Richard Biener > Date: Tue, 13 Aug 2019 09:50:34 +0200 > 2019-08-13 Richard Biener > > PR testsuite/91419 > * lib/target-supports.exp (natural_alignment_32): Amend target > list based on BIGGEST_ALIGNMENT. > (natural_alignment_64): Targets not natural_alignment

Re: [PATCH 2/8] bpf: new GCC port

On Tue, 20 Aug 2019, Jose E. Marchesi wrote: > > On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote: > > > --- a/configure > > > +++ b/configure > Yeah by mistake I used a Debian patched autoconf 2.96. Will regenerate > using vanilla autoconf for subsequent versions of th

Re: [PATCH 2/8] bpf: new GCC port

I didn't expect this to be contested and not by a frequent reviewer, but since you took the time to express yourself, I'll do the same. On Wed, 21 Aug 2019, Segher Boessenkool wrote: > On Tue, Aug 20, 2019 at 04:05:40PM -0400, Hans-Peter Nilsson wrote: > > On Tue, 20 Aug 201

libstdc++ PR54005M is_lock_free; consistently avoid referring to object

This patch should have no visible effect. It was approved in the BZ and is what remains of PR54005. _M_i is declared "alignas(_S_alignment) _Tp _M_i;" and is_lock_free is supposed to refer to the *type* not the specific *object*. (Note how the actual address of the object is not used in the __at

Re: [PATCH] MIPS: Add `-mfix-r5900' option for the R5900 short loop erratum

On Tue, 13 Nov 2018, Maciej W. Rozycki wrote: > On Sun, 11 Nov 2018, Fredrik Noring wrote: > > > ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:71:1: > > note: in expansion of macro ?COMPILER_CHECK? > >71 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct st

Re: [PATCH] target/58397: add host_hooks for NetBSD to make precompiled headers work

Hej! On Sun, 25 Nov 2018, Krister Walfridsson wrote: > On Sun, 25 Nov 2018, Maya Rashish wrote: > > > gcc/config.host | 4 ++ > > gcc/config/host-netbsd.c | 85 > > gcc/config/x-netbsd | 4 ++ > > 3 files changed, 93 insertions(+) > > create mo

Re: [PATCH] PR libstdc++/67843 set shared_ptr lock policy at build-time

> Date: Tue, 27 Nov 2018 23:25:55 + > From: Jonathan Wakely > This resolves a longstanding issue where the lock policy for shared_ptr > reference counting depends on compilation options when the header is > included, so that different -march options can cause ABI > changes. > [...] Thank you

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

Regarding this sometimes-add--latomic(-in-testsuite) that is revisited: 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 had a grep-look in gcc/doc before aski

Re: Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

> Date: Tue, 30 Apr 2019 11:37:17 -0600 > From: Jeff Law > On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote: > > Here's the follow-up, getting rid of the observed > > alignment-padding in execute/930126-1.c: the x parameter in f > > spuriously being runtime-aligne

Re: New .md construct: define_insn_and_rewrite

On Tue, 14 May 2019, Richard Sandiford wrote: > Several SVE patterns need define_insn_and_splits that generate the > same insn_code, but with different operands. That's probably a > niche requirement, but it's cropping up often enough on the ACLE > branch that I think it would be good to have a sy

RFA: fix PR90553, IRA assigning a call-clobbered reg to call with post-increment

I was looking into why I couldn't trivially move cris-elf to "use init_array". It appeared that it wasn't the hooks into that machinery that went wrong, but that a compiler bug is plaguing __libc_init_array. It's been there since at least 4.7-era, hiding under the covers of the __init_array being

Follow-up-fix to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

> Date: Thu, 10 Jan 2019 00:06:01 +0100 > From: Jakub Jelinek > 2019-01-09 Jakub Jelinek > > PR middle-end/84877 > PR bootstrap/88450 > * function.c (assign_stack_local_1): Revert the 2018-11-21 changes. > (assign_parm_setup_block): Do the argument slot realignment her

Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

Here's the follow-up, getting rid of the observed alignment-padding in execute/930126-1.c: the x parameter in f spuriously being runtime-aligned to BITS_PER_WORD. I separated this change because this is an older issue, a change introduced in r94104 where BITS_PER_WORD was chosen perhaps because we

Re: Follow-up-fix to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

> Date: Mon, 11 Feb 2019 02:05:11 +0100 > From: Hans-Peter Nilsson > Regtested on cris-elf, where it "introduces" gcc.dg/pr84877.c Correction: "no regressions" (not introduced by this proposed patch, I misread). brgds, H-P

Committed, config/cris/cris.c: spell "minimum" correctly.

Spotted while in a recent gdb session. JFTR, not mine... Committed. Index: ChangeLog === --- ChangeLog (revision 268759) +++ ChangeLog (revision 268760) @@ -1,3 +1,8 @@ +2019-02-11 Hans-Peter Nilsson + + * config/cris

Re: Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

> Date: Mon, 11 Feb 2019 07:38:14 +0100 > From: Richard Biener > >+ HOST_WIDE_INT min_parm_align > >+= STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY; > > Shouldn't it be MIN (...) of BOTH? That *does* seem logical... Take 2 as follows, in testing as before. Ok to commi

Re: Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

> Date: Mon, 11 Feb 2019 10:22:12 +0100 > From: Jakub Jelinek > Is PREFERRED_STACK_BOUNDARY what we want here? Shouldn't that be > STACK_BOUNDARY, or PARM_BOUNDARY? Though, PARM_BOUNDARY on cris is 32... Hm. I wish there was a better distinction both in the code and in peoples minds between b

Re: [PATCH][PR sanitizer/71480] Make ASan align string constants to shadow granularity.

On Fri, 10 Jun 2016, Jakub Jelinek wrote: > On Fri, Jun 10, 2016 at 03:13:32PM +0300, Maxim Ostapenko wrote: > > gcc/ChangeLog: > > > > 2016-06-10 Maxim Ostapenko > > > > PR sanitizer/71480 > > * varasm.c (place_block_symbol): Adjust alignment for asan protected > > STRING_CSTs even

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

On Sat, 18 Jun 2016, Bernhard Reutner-Fischer wrote: > A branch with a name matching scan-assembler pattern triggers > inappropriate FAIL. > > E.g. branch fixups-testsuite and > - gcc.target/i386/pr65871-?.c (scan-assembler-not "test") > - gcc.target/i386/pr41442.c (scan-assembler-times "test|cmp"

Committed, CRIS: fix target/71571, delay-slot nop in PIC MI thunk

Committed to trunk. Apparently the -fno-inline is key to keeping the test-case small. Thanks go to the reporter, David B. Robins. gcc: PR target/71571 * config/cris/cris.c (cris_asm_output_mi_thunk): Add missing "ba" delay-slot "nop" for PIC with CRIS v32. Also add missin

Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.

On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote: > * unwind.inc (_Unwind_RaiseException_Phase2): Use FRAMES_P_DECL, > FRAMES_VAR_DECL_1, FRAMES_VAR_INC and FRAMES_P_UPDATE. > (_Unwind_RaiseException): Use FRAMES_VAR_DECL, FRAMES_VAR_P and > FRAMES_VAR. > (_Unwind_ForcedU

Re: [libstdc++, patch] Fix build on APFS file system

On Wed, 18 Oct 2017, FX wrote: > Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on > macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about > 60% from my own builds and results reported by others): > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass

On Wed, 10 May 2017, Jakub Jelinek wrote: > On Wed, May 10, 2017 at 09:57:56PM +0200, Uros Bizjak wrote: > > BTW: This patch now catches 417 cases (instead of 200+) in linux > > build, including e.g.: > > > > (parallel [ > > (set (reg:CCZ 17 flags) > > (compare:CCZ (lshiftrt:SI

Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass

(To-list pruned, my correction doesn't need attention.) On Thu, 11 May 2017, Hans-Peter Nilsson wrote: > On Wed, 10 May 2017, Jakub Jelinek wrote: > > > On Wed, May 10, 2017 at 09:57:56PM +0200, Uros Bizjak wrote: > > > BTW: This patch now catches 417 cases (instead of

Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass

On Fri, 12 May 2017, Jeff Law wrote: > On 05/11/2017 03:29 PM, Hans-Peter Nilsson wrote: > > The canonical order of insns affecting condition-codes has been > > discussed in the past too. > > > > I was then arguing that the compare should go last, i.e. >

Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass

On Wed, 17 May 2017, Uros Bizjak wrote: > On Wed, May 17, 2017 at 4:45 AM, Hans-Peter Nilsson wrote: > >> But yes, we definitely should document the final canonical ordering. > > > > Is that about to also happen? > The proposed doc patch is wiating for review at [1].

Build failure cris-elf, gcc-5 backport of PR rtl-optimization/78255 fix, gcc/postreload.c:reload_cse_simplify

For cris-elf on the gcc-5-branch at r244321: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-m

Re: [wwwdocs] remove developer.axis.com links

> Date: Sun, 29 Jan 2017 23:06:56 +0100 (CET) > From: Gerald Pfeifer > There is one reference left in gcc.gnu.org/readings.html; Hans-Peter, > do you have a recommendation on how to best handle that? (Remove it, > or is there a good and stable replacement?) Sorry, I don't know. I'll open an in

Re: [PATCH 2/6] cris: Fix for RTL checking

> From: Segher Boessenkool > Date: Tue, 21 Feb 2017 14:48:14 + > 2017-02-21 Segher Boessenkool > > * config/cris/cris.md: Use correct operand in a define_peephole2. Obviously ok, thanks (INTVAL on "const_int_operand" vs. "nonimmediate_operand"). brgds, H-P

Re: Target maintainers: doc/install.texi love and care

> Date: Sun, 12 Mar 2017 12:34:25 +0100 (CET) > From: Gerald Pfeifer > On Sun, 12 Mar 2017, Gerald Pfeifer wrote: > > References to dependencies on really, really old versions of > > binutils (talking 10+ years here) which I think we can remove. > > Let me follow-up with some of you with concrete

Re: Target maintainers: doc/install.texi love and care

> Date: Sun, 12 Mar 2017 14:47:42 +0100 > From: Gerald Pfeifer > (May there be further changes to consider for cris-*?) Nothing actively pursued and no news on related issues. brgds, H-P

Re: RFD: annotate iterator patterns with expanded forms

On Mon, 25 Apr 2016, Bernd Schmidt wrote: > Now that we're in stage1, I thought I'd bring this up again. For reference, > the patch was here: > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00165.html > > So, would you like this for cris and mmix? I could enable it for these, then > we'd need som

Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran"

There exists targets that support fortran but error on -fPIC, for example cris-elf, which broke with the libbacktrace thingy. (Emitting an error for -fPIC is a conscious choice; a compilation error is better than e.g. to silently ignoring it.) This fix causes build to pass the point of error for cr

Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran"

(Goofed on the CC line, sorry for the dup.) There exists targets that support fortran but error on -fPIC, for example cris-elf, which broke with the libbacktrace thingy. (Emitting an error for -fPIC is a conscious choice; a compilation error is better than e.g. to silently ignoring it.) This fix c

Re: Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran"

> From: FX > Date: Mon, 24 Aug 2015 18:07:52 +0200 > > PIC_FLAG= > > if test -n "${with_target_subdir}"; then > > - PIC_FLAG=-fPIC > > + AC_TRY_COMPILE([void foo(void){}], [PIC_FLAG=-fPIC]) > > fi > > There's something I don't understand about this > test. Shouldn't AC_TRY_COMPILE take a firs

Re: Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran"

TL;DR: See last... > From: Ulrich Weigand > Date: Tue, 25 Aug 2015 14:59:05 +0200 > However, the compiler actually does accept -fPIC. If the flag is > present, we attempt to generate relocatable code, but only to the > extent the compiler can do that without support for run-time > relocations.

<    1   2   3   4   5   6   7   8   9   10   >