Re: H8 cc0 conversion

On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote: > This is the primary patch for cc0 removal on the H8 port.? It doesn't > have any of the optimization work and many patterns are simply disabled > at this time.? It's working well enough to not regress the testsuite. > > The H8 is similar to the

Re: H8 cc0 conversion

On Mon, 23 Nov 2020, Jeff Law wrote: > On 11/23/20 9:49 PM, Hans-Peter Nilsson wrote: > > On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote: > >> This is the primary patch for cc0 removal on the H8 port.? It doesn't > >> have any of the optimization work and m

Re: H8 cc0 conversion

On Tue, 24 Nov 2020, Eric Botcazou wrote: > > I'm intested in any notes, however vague, on that matter. I was > > a bit surprised to see that myself...that is, after fixing > > *some* related regressions, like the one in combine. (Did I > > actually miss something?) > > My recollection for the V

Re: [Ada] Improve precision of Ada.Directories.Modification_Time

On Wed, 21 Oct 2020, Iain Sandoe wrote: > Arnaud Charlet wrote: > > > > This patch breaks bootstrap on Darwin platforms. > > > > > > Pierre-Marie de Rodat wrote: > > > > > > > The modification file time precision now defined by OS. > > > > > > > > Tested on x86_64-pc-linux-gnu, committed on trun

Re: [Ada] Improve precision of Ada.Directories.Modification_Time

On Fri, 23 Oct 2020, Arnaud Charlet wrote: > > > For future reference, TRT for this kind of problem is to > > > autoconf for the right struct field name, using AC_CHECK_MEMBER > > > or AC_CHECK_MEMBERS (then use e.g. #if HAVE_STAT_ST_MTIM / #if > > > HAVE_STAT_ST_MTIMESPEC, definitely not #if _

Re: [PATCH 2/8] [RS6000] rs6000_rtx_costs for AND

On Thu, 22 Oct 2020, Alan Modra via Gcc-patches wrote: Hi! > On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote: > > Anyway: > > > > + || (outer_code == AND > > + && rs6000_is_valid_2insn_and (x, mode))) > > { > > *total = COSTS_N_IN

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

On Thu, 29 Oct 2020, Richard Sandiford via Gcc-patches wrote: > Hongtao Liu via Gcc-patches writes: > > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford > > wrote: > >> > >> Hongtao Liu via Gcc-patches writes: > >> > Hi: > >> > For inline asm, there could be an operand like (not (mem:)), it's

Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

On Mon, 17 Apr 2023, Richard Biener wrote: > On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote: > > If after all, a change to the size of the code and mode > > bit-fields in rtx_def is necessary, like to still fit 64 bytes (Sorry: 64 bits, not counting the union u.) > > such

Re: [PATCH v4 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces.

On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote: > Hello All: > > This new version of patch 4 use improve ree pass for rs6000 target using > defined ABI interfaces. > Bootstrapped and regtested on power64-linux-gnu. > > Thanks & Regards > Ajit > > > ree: Improve ree pass for rs6

Re: [PATCH v4 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces.

On Fri, 28 Apr 2023, Jeff Law wrote: > On 4/28/23 16:42, Hans-Peter Nilsson wrote: > > On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote: > > I don't see anything in those functions that checks if > > ZERO_EXTEND is actually a feature of the ABI, e.g. as oppo

Re: [PATCH] libstdc++: testsuite: Add char8_t to codecvt_unicode

Casual observation from a random reader that's sometimes hit by testresults acting up: On Thu, 9 Feb 2023, Dimitrij Mijoski via Gcc-patches wrote: > libstdc++-v3/ChangeLog: > > * testsuite/22_locale/codecvt/codecvt_unicode.cc: Rename > functions. > * testsuite/22_locale/code

Re: [PATCH] Support multilib-aware target lib flags self-specs overriding

On Fri, 20 May 2022, Alexandre Oliva via Gcc-patches wrote: > > This patch introduces -multiflags, short for multilib TFLAGS, as an > option that does nothing by default, but that can be added to TFLAGS > and mapped to useful options by driver self-specs. > > I realize -m is reserved for machine-sp

Re: enable sqrt insns for cdce3.c

On Wed, 10 Mar 2021, Alexandre Oliva wrote: > > The test expects shrink-wrapping of the fsqrt call, but that will only > occur when there is a usable sqrt insn. > > Arrange for dejagnu to add the options that enable the sqrt insn, if > one is available, and to skip the test otherwise. > > > H-P, t

Re: [wwwdocs] readings.html - "Porting GCC for Dunces" is gone

Ping. I personally would prefer it being on gcc.gnu.org but will arrange for an alternative, if that for some reason would be inappropriate. FWIW, the PDF weighs in at a whopping 474174 bytes. > From: Hans-Peter Nilsson > Date: Mon, 11 Nov 2019 13:10:41 +0100 > > > From:

Re: [PATCH] Add a new conversion for conditional ternary set into ifcvt [PR106536]

On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote: > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi > index 92bda1a7e14..9823eccbe68 100644 > --- a/gcc/doc/tm.texi > +++ b/gcc/doc/tm.texi > @@ -7094,6 +7094,15 @@ the @code{POLY_VALUE_MIN}, @code{POLY_VALUE_MAX} and > implementation returns

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote: > On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote: > >>>> Is there a reason why REE cannot see that our (reg:QI 4) is a param > >>>> register > >>>> and thus due to our ABI, already c

Re: [PATCH v2] RISC-V: Add Z*inx imcompatible check in gcc.

On Tue, 28 Mar 2023, Jiawei wrote: > + // Zfinx is conflict with float extensions. > + if (TARGET_ZFINX && TARGET_HARD_FLOAT) > +error ("z*inx is conflict with float extensions"); > + While I'm not a native English speaker, "is conflict with" doesn't sound grammatically correct. Perhaps "

Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote: > On Thu, 13 Apr 2023, Richard Sandiford wrote: > > > ??? writes: > > > Yeah, like kito said. > > > Turns out the tuple type model in ARM SVE is the optimal solution for RVV. > > > And we like ARM SVE style implmentation. > > > > > > And

Re: [PATCH] PowerPC PR target/84154, fix floating point to small integer conversion regression

On Wed, 7 Feb 2018, Segher Boessenkool wrote: > Hi Mike, > > On Tue, Feb 06, 2018 at 04:34:08PM -0500, Michael Meissner wrote: > > Here is the patch reworked. It bootstraps on both little/big endian power8, > > and all of the tests run. Can I install this into trunk now, and into GCC 7 > > after

[PATCH 0/4] ASAN for MIPS (o32)

All patches are together run through the gcc and g++ test-suites to check ASAN results for mipsisa32r2el-linux-gnu. As of r258635 those results are on par with those for arm-linux-gnueabihf, so without delay I present the current state. Maybe it's non-intrusive enough to be ok for gcc-8? MIPS mai

[PATCH 1/4] ASAN for MIPS: Add __sanitizer.lock.pad initializer, shutting up a warning

This appears to be present in compiler-rt upstream, but as part of more intrusive changes. For gcc, the lack of this results in a fatal warning (-Werror) at build-time. libsanitizer: * sanitizer_common/sanitizer_atomic_clang_other.h [_MIPS_SIM && _MIPS_SIM == _ABIO32] (lock): Add

[PATCH 2/4] ASAN for MIPS: Correct struct_kernel_stat_sz for MIPS and don't use .

As mentioned in the bogus adjustment to 160 from 144 (which is reverted here), is a single-token commit in upstream r301307, an attempt to correct a failed build due to an upstream change to compile the runtime with D_FILE_OFFSET_BITS=64. The corre

[PATCH 3/4] Enable libsanitizer for 32-bit mips*-*-linux*

If someone has access to a 64-bit mips-linux system to test this (with the obvious edit), that'd be really nice. Until then, best to not introduce possible build failures. libsanitizer: * configure.tgt : Enable build, excluding mips*64*-*-linux*. diff --git a/libsanitizer/config

[PATCH 4/4] ASAN for MIPS: Add gcc port bits for MIPS to support -fsanitize=address.

Attribution to Jean Lee for spotting the right shadow-offset for MIPS and for cheering on. :) See xtensa and rs6000 back-ends for the FRAME_GROWS_DOWNWARD construct. gcc: 2018-03-22 Hans-Peter Nilsson Jean Lee * config/mips/mips.c (mips_asan_shadow_offset): New

Release-manager approval for gcc-8? (was: Re: [PATCH 0/4] ASAN for MIPS (o32))

rg/ml/gcc-patches/2018-03/msg01264.html> Add gcc port bits for MIPS to support -fsanitize=address: <https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01265.html> > From: Matthew Fortune > Date: Fri, 23 Mar 2018 16:19:17 + > Hans-Peter Nilsson writes: > > All patches are

Committed: io/async.h: Use __gthread_mutex_t, not pthread_mutex_t.

These pthread_mutex_t were obviously meant to be __gthread_mutex_t. See other declarations. Not being that, broke cris-elf build at r264070, restored with this patch. Also regtested on native x86_64-pc-linux-gnu. I'm not sure know why no other bare-iron target saw this, but perhaps it's because

Committed: fix target/86779, speculative error for cris-*

Nothing ever speculated here, move along... Regtested for cris-elf, observing the maintenance-provoking test-cases now passing. PR target/86779 * config/cris/cris.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Redefine to speculation_safe_value_not_needed. Index: gcc/config/cris

Committed, PR target/85666 1/2, MMIX: Don't call leaf_function_p

It's IMO never a good idea to call leaf_function_p in port-specific code. Sooner or later, you'll need that information in a context where calling leaf_function_p is either a bad idea (it does a linear walk over all emitted insns in a function) or invalid (called when global context is within a se

Committed, PR target/85666 2/2, MMIX: Handle emitting data bytes as non-literals

Until location views (in gcc-8), there apparently was no need to emit single bytes of data as anything but bare CONST_INTs, neither actual data nor dwarf2 debug. With location views, there's a field within dwarf2 records for inlined subroutines that as assembly code looks as follows in context (cu

Committed, PR target/86794, MMIX TARGET_HAVE_SPECULATION_SAFE_VALUE: Not needed.

The mythical MMIX hardware engineers have wisely understood the need to automatically disable speculation when a speculated execution path transitions to kernel mode. There might be mythical talk about using a bit in a configuration register to enable even that, but that's just speculation and som

Committed, PR target/85666

I've back-ported these two patches to the gcc-8-branch to restore buildability. Tested at r264184, committed r264351. PR target/85666 * config/mmix/mmix.c (mmix_assemble_integer): Handle byte-size non-CONST_INT rtx:es using assemble_integer_with_op ".byte". (MMIX_C

Committed, MMIX: don't expand __builtin_ffs to ffs

I tried to update newlib (from an old copy from couple of years ago), but got curious regressions localized to tests related to ffs handling: --- regress.prev2018-09-13 18:49:04.130070398 +0200 +++ regress 2018-09-13 22:59:25.551637529 +0200 @@ -0,0 +1,5 @@ +gcc.sum gcc.c-torture/execu

Re: [PATCH] PR libstdc++/78179 run long double tests separately

> Date: Thu, 20 Sep 2018 15:22:23 +0100 > From: Jonathan Wakely > On 20/09/18 15:36 +0200, Christophe Lyon wrote: > >On Wed, 19 Sep 2018 at 23:13, Rainer Orth > >wrote: > >> > >> Hi Christophe, > >> > >> > I have noticed failures on hypot-long-double.cc on arm, so I suggest we > >> > add: > >>

Re: [PATCH] PR libstdc++/78179 run long double tests separately

> Date: Fri, 21 Sep 2018 12:21:31 +0100 > From: Jonathan Wakely > Here's the corrected patch, any objections to this? Quite the contrary; LGTM. brgds, H-P

Re: [PATCH 0/4] ASAN for MIPS (o32)

> Date: Fri, 23 Mar 2018 03:49:01 +0100 > From: Hans-Peter Nilsson The patches enabling ASAN for MIPS (32-bit) have now been committed, on trunk for gcc-9. I didn't persist pinging release maintainers for gcc-8, but I'd certainly like to backport them, if so allowed. brgds, H-P

Re: ATTRIBUTE_NONSTRING

On Fri, 27 Apr 2018, Alan Modra wrote: > This patch adds ATTRIBUTE_NONSTRING, which will be used to curb > -Wstringop-truncation warnings in binutils. OK to apply? > > * ansidecl.h (ATTRIBUTE_NONSTRING): Define. > > diff --git a/include/ansidecl.h b/include/ansidecl.h > index c11daff..ec5f3

Fix PR85726 (div-div suboptimization) and a rant on match.pd :s-flag

Replacing a division feeding a division helps only when the second division is the only user, and "fusing" the divisions is downright bad if another user of the result of first division is a modulus of the same value as the second division, forming a divmod pair. See the test-case, where for the t

Re: Fix PR85726 (div-div suboptimization) and a rant on match.pd :s-flag

> Date: Thu, 10 May 2018 10:33:39 +0200 (CEST) > From: Marc Glisse > On Thu, 10 May 2018, Hans-Peter Nilsson wrote: > > > Replacing a division feeding a division helps only when the > > second division is the only user, and "fusing" the divisions is > >

Re: Fix PR85726 (div-div suboptimization) and a rant on match.pd :s-flag

> Date: Thu, 10 May 2018 14:03:10 +0200 > From: Jakub Jelinek > On Thu, May 10, 2018 at 01:51:29PM +0200, Marc Glisse wrote: > > > > There are probably more > > > > complicated transformations this disables. > > > > > > I'm providing an example from *real* code where the > > > transformation is

Re: Fix PR85726 (div-div suboptimization) and a rant on match.pd :s-flag

> Date: Thu, 10 May 2018 07:23:05 -0500 > From: Segher Boessenkool > On Thu, May 10, 2018 at 10:33:39AM +0200, Marc Glisse wrote: > > int x, y; > > void f(int n){ > > int c = 3 << 20; > > x = n / c; > > y = x / c; > > } > Without the replacement we have two dependent divisions; with the >

Re: [PATCH, C/C++] Add -fno-float to forbid floating point data types

On Tue, 12 Aug 2014, Thomas Preud'homme wrote: > As mentioned in PR60070, there is many cases when a programmer want to ensure > that a program does not use any floating point data type. Other cases to > consider > is when a target has several floating point ABI and user want to ensure > his/her

Re: [wwwdocs] Re: gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(

On Fri, 15 Aug 2014, Oleg Endo wrote: > > How about the attached .html as a replacement for the current one? > > I removed the requirement of setting up a combined tree, as I believe > > it makes things much more easy. At least it's been working for me > > that way. Is this helpful / OK to commit

Re: [wwwdocs] Re: gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(

On Mon, 18 Aug 2014, Oleg Endo wrote: > On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote: > > On Fri, 15 Aug 2014, Oleg Endo wrote: > > > > How about the attached .html as a replacement for the current one? > > > > I removed the requirement of setting

Re: [wwwdocs] Re: gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(

On Mon, 18 Aug 2014, Oleg Endo wrote: > On Mon, 2014-08-18 at 16:57 -0400, Hans-Peter Nilsson wrote: > > On Mon, 18 Aug 2014, Oleg Endo wrote: > > > On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote: > > > > On Fri, 15 Aug 2014, Oleg Endo wrote: > >

Re: [patch, nios2] testsuite cleanup

On Thu, 21 Aug 2014, Mike Stump wrote: > On Aug 21, 2014, at 10:59 AM, Sandra Loosemore > wrote: > > On 08/21/2014 11:36 AM, Mike Stump wrote: > >> On Aug 21, 2014, at 8:00 AM, Sandra Loosemore > >> wrote: > >>> tests that assume some non-default branch costs in the back end > >> > >> Thanks. >

Re: Enable EBX for x86 in 32bits PIC code

(Dropping gcc@ and people known to subscribe to gcc-patches from the CC.) Sorry for the drive-by review, but... On Fri, 22 Aug 2014, Ilya Enkovich wrote: > Hi, > > On Cauldron 2014 we had a couple of talks about relaxation of > ebx usage in 32bit PIC mode. It was decided that the best > approach

Re: [patch, nios2] testsuite cleanup

On Sat, 23 Aug 2014, Sandra Loosemore wrote: > On 08/23/2014 10:26 AM, Mike Stump wrote: > > On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson wrote: > > > > > > > +/* non default branch cost */ > > > > +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-

Re: Enable EBX for x86 in 32bits PIC code

On Mon, 25 Aug 2014, Ilya Enkovich wrote: > 2014-08-23 5:47 GMT+04:00 Hans-Peter Nilsson : > > ...did you send the right version of the patch? > > This one uses the RTX-returning hook only in boolean tests, > > unless I misread. (I did, but not by much.) > NULL returned

(Still) ICE for cris-elf at r214710

Sorry for the context-less mail but I didn't find a proper obvious gcc-patches-message to reply to. (Also, I can't log into bugzilla because to enter a PR as there appears to have been some SSL changes such that my old firefox and gcc.gnu.org can no longer agree on a cipher or something.) But, si

Re: (Still) ICE for cris-elf at r214710

> From: David Malcolm > Date: Fri, 29 Aug 2014 13:40:49 +0200 > > Patch attached, which fixes the above testcase; bootstrap in progress: > > > > gcc/ > > * resource.h (mark_target_live_regs): Undo erroneous conversion > > of second param of r214693, converting it back from rtx_insn * to

Re: (Still) ICE for cris-elf at r214710

> From: David Malcolm > Date: Fri, 29 Aug 2014 13:26:59 +0200 > On Fri, 2014-08-29 at 06:13 +0200, Hans-Peter Nilsson wrote: > > /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc > > -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc > > -B/tmp/hpautotest-gcc1/cris

Re: PR62304 (was Re: (Still) ICE for cris-elf at r214710)

> From: David Malcolm > Date: Fri, 29 Aug 2014 17:33:54 +0200 > On Fri, 2014-08-29 at 16:48 +0200, Hans-Peter Nilsson wrote: > > Sorry, but that didn't help. I still get the exact same error. > > (Yep, I double-checked that I didn't goof testing...) Famous last

Re: [PATCH v2] Re: PR62304 (was Re: (Still) ICE for cris-elf at r214710)

> From: David Malcolm > Date: Fri, 29 Aug 2014 20:07:04 +0200 > BTW, in another email in the thread you said: > > > Thanks for the heads-up. BTW, the ChangeLog entries should say > > "what" not "why"; that goes into a comment in the source. > > OK. Where possible I've added comments in the n

[RFA:] testsuite: robustify g++.old-deja/g++.eh/badalloc1.C for 64-bit systems

In a native x86_64-linux toolchain in which eh-table-registration is done explicitly (i.e. dl_iterate_phdr and PT_GNU_EH_FRAME is *not* assumed, as that eliminates the issue), the memory overhead for exception-initialization goes beyond the 32768 bytes assumed in badalloc1.C and the test fails for

[RFA 0/2]: inhibit_libc and eh-registry vs. eh-phdrs incompatibility

The conditions for inhibit_libc to activate (i.e. for library headers to be absent) are IMO a bit too automatic and the effect is too subtle and serious in some situations. For example, if you pre-install target headers in $target_header_dir, gcc will find them and use them, but still inhibit_libc

[RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

The directory at $target_header_dir is already inspected in gcc/configure, for e.g. glibc version and stack protector support, but not for setting inhibit_libc. This is just inconsistent and the obvious resolution to me is to inhibit inhibit_libc when a target *does* "have its own set of headers",

[RFA 2/2]: --enable-explicit-exception-frame-registration compatibility option

This adds an option to allow programs and libraries built *without* inhibit_libc to stay compatible with system libraries (really: libgcc_s.so.1) built *with* inhibit_libc, at the cost of the registration. As mentioned, that's a one-way compatibility barrier. While it's nice to avoid the overhead

Re: Remove no-longer-needed fp-bit target macros

> From: "Joseph S. Myers" > Date: Fri, 5 Sep 2014 19:21:04 +0200 > This patch removes some fp-bit target macros that are no longer > needed: > > * __make_dp was not really designed as a target macro, but CRIS > defined it in cris.h anyway for optimization purposes Minor correction here: it wa

Re: [PATCH] Use libbacktrace as libsanitizer's symbolizer

> From: Ian Lance Taylor > Date: Tue, 19 Nov 2013 02:11:29 +0100 > 2013-11-18 Ian Lance Taylor > > * configure.ac: Check for support of __atomic extensions. > * internal.h: Declare or #define atomic functions for use in > backtrace code. > * atomic.c: New file. Build-

Re: [SH] PR 30807 - Add test case

On Tue, 5 Nov 2013, Mike Stump wrote: > On Nov 5, 2013, at 1:45 PM, Oleg Endo wrote: > > You're right, it's redundant. It should be just > > /* { dg-do compile } */ > > > > shouldn't it? > > Yup, that's my take. Or nothing at all, as compile seems to be the default here. (grep for dg-do-what-de

Re: Implement C11 _Atomic

On Tue, 5 Nov 2013, Joseph S. Myers wrote: Thanks for doing this! However, without examples I have trouble reading out the bits I need as a target maintainer, and I can't read out the answers from the patch, so pardon a few questions. > This patch, relative to trunk and based on work done on the

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: [PATCH v2 6/6] i386: Implement asm flag outputs

Well, these kinds of asm are inherently target specific, but I did already ask for a cpp symbol to indicate this faculty us available. On May 20, 2015 9:21:07 AM PDT, Jeff Law wrote: >On 05/15/2015 09:37 AM, Richard Henderson wrote: >> Version 2 includes proper test cases and documentation. >> H

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: [RFC 0/6] Flags outputs for asms

On 05/07/2015 02:38 PM, Richard Henderson wrote: > Here's a prototype for i386 only, which stands up to light testing. > I'd rather post this tonight rather than wait until tomorrow when I > can write more proper dejagnu tests. > > I've tested the intermedate patches via config-list.mk, so despite

Re: [RFC 0/6] Flags outputs for asms

This is a separate issue which really shouldn't have anything to do with this, but is there a specific reason why: void good1(int x, int y) { _Bool pf; asm("cmpl %2,%1" : "=@ccp" (pf) : "r" (x), "g" (y)); if (pf) beta(); } ... ends up generating a jump to a jump?

Re: [RFC 0/6] Flags outputs for asms

On 05/08/2015 08:54 AM, Richard Henderson wrote: > > Anyway, I'll look into whether the branch around alpha can be optimized, but > I'd be shocked if I'd be able to do anything about the branch around beta. > True, there's nothing in between that will clobber the flags so it would be an > excellen

Re: [PATCH 6/6] i386: Implement asm flag outputs

On 05/07/2015 02:39 PM, Richard Henderson wrote: > All j mnemonics implemented as =@cc > to make it easy for someone reading the manual > to figure out what condition is desired. One request: would it be possible to get a cpp symbol for this (e.g. __GCC_X86_INLINE_ASM_CC__) so we don't have to do

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

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