Re: [PATCH] Better distinguish OpenACC and OpenMP sections in libgomp.texi

On Fri, Jan 11, 2019 at 01:03:48AM +, Julian Brown wrote: > 2019-xx-xx Thomas Schwinge > James Norris > > * libgomp.texi: Better distinguish OpenACC and OpenMP "Runtime > Library Routines", and "Environment Variables". Ok, thanks. Jakub

[PATCH] PR fortran/35031 -- Check F2018:C1246

An entry-name obtains the elemental attribute from its containing procedure. F2018:C1546 prohibits an procedure from having a BIND(C) attribute. BIND(C) can appear on the entry-stmt line, so gfortran needs to check for a conflict. The attached patch does this check. Tested on x86_64-*-freebsd.

[PATCH] Better distinguish OpenACC and OpenMP sections in libgomp.texi

Hi, This patch looks like it should have been attached to the following email: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01173.html but it looks like the wrong patch (and ChangeLog!) were attached instead. For convenience, I'll copy Cesar's blurb (mildly corrected) from the previous message:

Re: [Patch, fortran] Fix PR59345, repacking of a packed temporary array

On Thu, Jan 10, 2019 at 09:17:37PM +0100, Thomas Koenig wrote: > > the attached patch fixes a rather bad missed optimization, where > the generated temporary array for > > SUBROUTINE S1(A) > REAL :: A(3) > CALL S2(-A) > END SUBROUTINE > > was packed and unpacked(!). > > Regression-tested. O

[PATCH 10/10] libiberty: Correct an invalid assumption

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 07/10] libiberty: Correctly handle error result in dlang_parse_structlit()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 09/10] libiberty: Correctly handle error result in dlang_parse_assocarray()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 08/10] libiberty: Correctly handle error result in dlang_parse_tuple()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 05/10] libiberty: Fix stack underflow in dlang_parse_integer()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 06/10] libiberty: Correctly handle error result in dlang_parse_arrayliteral()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 04/10] libiberty: Fix crash in ada_demangle()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 03/10] libiberty: Fix a crash in d_print_comp_inner()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 01/10] libiberty: Fix an out of bounds read in d_expression_1()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

[PATCH 02/10] libiberty: Fix a crash in d_encoding()

Hi all, First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if there's obvious errors repeated in my patches. AFAICT I should be sending each change individually rather than as one bulk patch, so I'm sorry about the spam too. All of these changes were found by fuzzing libi

Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI

OK, I fixed the issues in your last email. I initially found one regression while testing. In lra_create_live_ranges_1 I had removed the 'call_p = false' statement but did not replaced it with anything. This resulted in no regressions on aarch64 but caused a single regression on x86 (gcc.target/i

Re: [v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr

On 10/01/19 22:27 +0100, Rainer Orth wrote: Hi Jonathan, On 04/12/17 23:04 +, Jonathan Wakely wrote: On 03/12/17 23:08 +0200, Ville Voutilainen wrote: Tested on Linux-x64. 2017-11-14 Ville Voutilainen Implement LWG 2221 * include/std/ostream (operator<<(nullptr_t)): New. * test

Re: [PATCH] Don't use align > MAX_SUPPORTED_STACK_ALIGNMENT in assign_stack_temp_for_type (PR bootstrap/88450)

On Thu, Jan 10, 2019 at 03:11:18PM -0800, H.J. Lu wrote: > > Bootstrapped/regtested on x86_64-linux and i686-linux, but that doesn't mean > > much, because MAX_SUPPORTED_STACK_ALIGNMENT there is 1 << 28. Guess more > > useful would be to test it on mingw where BIGGEST_ALIGNMENT is often higher > >

Re: [PATCH] Fix float*v2div2sf2* patterns (PR target/88785)

On Thu, Jan 10, 2019 at 11:20 PM Jakub Jelinek wrote: > > Hi! > > The following testcase ICEs in dwarf2out.c, because a few sse.md patterns > contain invalid RTL, in particular > (const_vector:V2SF [(const_int 0) (const_int 0)]) > Elements of a V2SF const_vector should be (const_double:SF 0), not

Re: [PATCH v2] x86-64: {,V}CVTSI2Sx are ambiguous without suffix

On Thu, Jan 10, 2019 at 3:56 PM Jan Beulich wrote: > > For 64-bit these should not be emitted without suffix in AT&T mode (as > being ambiguous that way); the suffixes are benign for 32-bit. For > consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ. > > The omission has originally (pr

Re: [PATCH] Don't use align > MAX_SUPPORTED_STACK_ALIGNMENT in assign_stack_temp_for_type (PR bootstrap/88450)

On Thu, Jan 10, 2019 at 2:32 PM Jakub Jelinek wrote: > > Hi! > > On Thu, Jan 10, 2019 at 04:36:35PM +0100, Eric Botcazou wrote: > > > If there are other spots that need this, wondering about: > > > else > > > copy = assign_temp (type, 1, 0); > > > in calls.c, either i

[PATCH] Improve RTL DSE with -fstack-protector* (PR rtl-optimization/88796)

Hi! As mentioned in the PR, RTL DSE doesn't do much with -fstack-protector*, because the stack canary test in the epilogue of instrumented functions is a MEM_VOLATILE_P read out of the crtl->stack_protect_guard ssp canary slot in the stack frame and either a MEM_VOLATILE_P read of __stack_chk_guar

[PATCH] Don't use align > MAX_SUPPORTED_STACK_ALIGNMENT in assign_stack_temp_for_type (PR bootstrap/88450)

Hi! On Thu, Jan 10, 2019 at 04:36:35PM +0100, Eric Botcazou wrote: > > If there are other spots that need this, wondering about: > > else > > copy = assign_temp (type, 1, 0); > > in calls.c, either it can be done by using the variable-sized object > > case in the then

Re: [PATCH] [RFC] PR target/52813 and target/11807

On 1/10/19 10:23 PM, Richard Sandiford wrote: > Segher Boessenkool writes: >> On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote: >>> Bernd Edlinger writes: Meanwhile I found out, that the stack clobber has only been ignored up to gcc-5 (at least with lra targets, not rea

[COMMITTED][PATCH][GCC][AArch64] Initialize the new SIMD buildins in right place.

Hi All, This fixes an issue where the +nosimd option causes the builtins for fcmla_laneq not to be defined at all. This fixes the regression by initializing the built-ins together with the rest of the SIMD ones. Thanks, Tamar gcc/ChangeLog: 2019-01-10 Tamar Christina * config/aarch

[PATCH] Fix misplaced combine totals dumping (PR bootstrap/88714)

Hi! r191883 seems to have introduced a pasto: --- trunk/gcc/passes.c 2012/10/01 00:17:52 191882 +++ trunk/gcc/passes.c 2012/10/01 05:43:06 191883 @@ -231,27 +231,23 @@ timevar_push (TV_DUMP); if (profile_arc_flag || flag_test_coverage || flag_branch_probabilities) { - dum

[PATCH] Fix float*v2div2sf2* patterns (PR target/88785)

Hi! The following testcase ICEs in dwarf2out.c, because a few sse.md patterns contain invalid RTL, in particular (const_vector:V2SF [(const_int 0) (const_int 0)]) Elements of a V2SF const_vector should be (const_double:SF 0), not (const_int 0). Unfortunately, we can't add explicitly const_double

Re: [PATCH] [RFC] PR target/52813 and target/11807

Jakub Jelinek writes: > On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote: >> > "noreturn"... What would that mean, *exactly*? It cannot execute any >> > code the compiler can see, so such asm is better off as real asm anyway >> > (not inline asm). >> >> "Exactly" is a strong wo

Re: [C++ Patch] Fix three locations

On 1/9/19 10:46 AM, Paolo Carlini wrote: Hi, three additional fixes along the usual lines. In the grokdeclarator changes I'm not touching the actual printing of the name, but another option would be using %qD and decl here too, thus, for cases like parse/crash43.C, where everything lives insi

Re: [v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr

Hi Jonathan, > On 04/12/17 23:04 +, Jonathan Wakely wrote: >>On 03/12/17 23:08 +0200, Ville Voutilainen wrote: >>>Tested on Linux-x64. >>> >>>2017-11-14 Ville Voutilainen >>> >>> Implement LWG 2221 >>> * include/std/ostream (operator<<(nullptr_t)): New. >>> * testsuite/27_io/basic_ost

Re: [PATCH] [RFC] PR target/52813 and target/11807

On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote: > > "noreturn"... What would that mean, *exactly*? It cannot execute any > > code the compiler can see, so such asm is better off as real asm anyway > > (not inline asm). > > "Exactly" is a strong word, and this wasn't my proposa

Re: [PATCH] [RFC] PR target/52813 and target/11807

Segher Boessenkool writes: > On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote: >> Bernd Edlinger writes: >> > Meanwhile I found out, that the stack clobber has only been ignored up to >> > gcc-5 (at least with lra targets, not really sure about reload targets). >> > From gcc-6 on

patch to fix PR87305

The following patch fixes   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305 The patch was bootstrapped and tested on x86-64 and ppc64 (be). Committed as rev. 267823. Index: ChangeLog === --- ChangeLog (revision 267822) +++ Chan

[PATCH] Update sinhatanh test

Previously, the tests 'sinhatanh-2.c' and 'sinhatanh-3.c' did not count the number of functions found in the tree-dump. This patch address this issue. 2019-01-10 Giuliano Belinassi * gcc.dg/sinhatanh-2.c: Count the number of functions. * gcc.dg/sinhatanh-3.c: Likewise. Index:

[Patch, fortran] Fix PR59345, repacking of a packed temporary array

Hello world, the attached patch fixes a rather bad missed optimization, where the generated temporary array for SUBROUTINE S1(A) REAL :: A(3) CALL S2(-A) END SUBROUTINE was packed and unpacked(!). Regression-tested. OK for trunk? Regards Thomas 2019-01-10 Thomas Koenig

[PATCH 2/2][GCC][ARM] Implement hint intrinsics for ARM

Hi All, This patch implements the ACLE hint intrinsics (nop,yield,wfe,wfi,sev and sevl), for all ARM targets. The intrinsics specification will be published on the Arm website [1]. [1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf Bootstrapped on arm-none-lin

[PATCH 1/2][GCC][AArch64] Implement hint intrinsics for AArch64

Hi All, This patch implements the ACLE hint intrinsics (nop, yield, wfe, wfi, sev and sevl), for AArch64. The instructions are documented in the ArmARM[1] and the intrinsics specification will be published on the Arm website [2]. [1] https://developer.arm.com/docs/ddi0487/latest/arm-architect

Re: [Committed][AArch64] Fix PR62178 testcase failures

I've backported this to GCC8 too since it had the same failures: The testcase for PR62178 has been failing for a while due to the pass conditions being too tight, resulting in failures with -mcmodel=tiny: ldr q2, [x0], 124 ld1r{v1.4s}, [x1], 4 cmp x0, x2

Re: [PATCH] PR fortran/86322 -- Enforce F2018:C877

Hi Steve! The attached patche fixes the PR. gfortran was not enforcing F2018:C877 and would ICE. Tested on x86_64-*-freebsd. Ok to commit? OK. Thanks for the patch! Regards Thomas

[Committed, GCC, AArch64] Disable tests for ilp32.

Hi Currently Return Address Signing is only supported in lp64. Thus the tests that I added recently (that enables return address signing by the mbranch-protection=standard option), should also be exempted from testing in ilp32. This patch adds the needed dg-require-effective-target directive in t

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: [PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)

On January 10, 2019 4:36:35 PM GMT+01:00, Eric Botcazou wrote: >> Another problem is that in way too many cases we decide to choose >> BIGGEST_ALIGNMENT for stack slots, even when not strictly needed. >E.g. any >> BLKmode stack slot requests that BIGGEST_ALIGNMENT, even if >TYPE_ALIGN is >> much

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][GCC][AArch64] Fix command line options canonicalization. (PR target/88530)

Hi Tamar, On 17/12/18 19:18, Tamar Christina wrote: Hi All, The options don't seem to get canonicalized into the smallest possible set before output to the assembler. This means that overlapping feature sets are emitted with superfluous parts. Normally this isn't an issue, but in the case of c

Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection

Hi Tamar, On 18/12/18 13:36, Tamar Christina wrote: Hi All, This patch makes the feature detection code for AArch64 GCC not add features automatically when the feature had no hwcaps string to match against. This means that -mcpu=native no longer adds feature flags such as +profile. The behavio

Re: [PATCH, GCC, AARCH64, 5/6] Enable BTI : Add new pass for BTI.

Hi Christophe On 10/01/19 15:46, Christophe Lyon wrote: > On Wed, 9 Jan 2019 at 15:42, Sudakshina Das wrote: >> >> Hi >> >> On 20/12/18 16:40, Sudakshina Das wrote: >>> Hi James >>> >>> On 19/12/18 3:40 PM, James Greenhalgh wrote: On Fri, Dec 14, 2018 at 10:09:03AM -0600, Sudakshina Das wrot

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On 03/12/2018 16:39, Ard Biesheuvel wrote: > On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan > wrote: >> >> For quite sometime the kernel guys, (more specifically Ard) have been >> talking about using a system register (sp_el0) and an offset from that >> for a canary based access. This patchset

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On 10/01/2019 15:49, James Greenhalgh wrote: > On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote: >> For quite sometime the kernel guys, (more specifically Ard) have been >> talking about using a system register (sp_el0) and an offset from that >> for a canary based access. This

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On Thu, Jan 10, 2019 at 03:49:27PM +, James Greenhalgh wrote: > On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote: > > For quite sometime the kernel guys, (more specifically Ard) have been > > talking about using a system register (sp_el0) and an offset from that > > for a

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote: > For quite sometime the kernel guys, (more specifically Ard) have been > talking about using a system register (sp_el0) and an offset from that > for a canary based access. This patchset adds support for a new set of > command

Re: [PATCH, GCC, AARCH64, 5/6] Enable BTI : Add new pass for BTI.

On Wed, 9 Jan 2019 at 15:42, Sudakshina Das wrote: > > Hi > > On 20/12/18 16:40, Sudakshina Das wrote: > > Hi James > > > > On 19/12/18 3:40 PM, James Greenhalgh wrote: > >> On Fri, Dec 14, 2018 at 10:09:03AM -0600, Sudakshina Das wrote: > >> > >> > >> > >>> I have updated the patch according to

Re: [PATCH 9/9][GCC][Arm] Add ACLE intrinsics for complex mutliplication and addition

Hi Christoph, It was introduced in a small refactoring after which I only retested the testcases I added,which don't trigger the issue. In any case it's a trivial fix and I'll submit a patch in a bit. Tamar From: Christophe Lyon Sent: Thursday, January

Re: [PATCH] Define new filesystem::__file_clock type

On 06/01/19 21:45 +, Jonathan Wakely wrote: On 05/01/19 20:03 +, Jonathan Wakely wrote: In C++17 the clock used for filesystem::file_time_type is unspecified, allowing it to be chrono::system_clock. The C++2a draft requires it to be a distinct type, with additional member functions to co

Re: [PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)

> Another problem is that in way too many cases we decide to choose > BIGGEST_ALIGNMENT for stack slots, even when not strictly needed. E.g. any > BLKmode stack slot requests that BIGGEST_ALIGNMENT, even if TYPE_ALIGN is > much smaller and assign_stack_local_1 even asserts that for BLKmode the > a

Re: [PATCH 9/9][GCC][Arm] Add ACLE intrinsics for complex mutliplication and addition

Hi Tamar, On Thu, 10 Jan 2019 at 04:44, Tamar Christina wrote: > > Hi Kyrill, > > Committed with a the addition of a few trivial defines and iterators that > were missing due to > The patch being split. > > Thanks, > Tamar > > -Original Message- > From: Kyrill Tkachov > Sent: Friday, D

Re: [PATCH] x86: Update VFIXUPIMM* Intrinsics to align with the latest Intel SDM

On Donnerstag, 10. Januar 2019 14:27:40 CET Matthias Kretz wrote: > On Donnerstag, 10. Januar 2019 11:39:56 CET Jakub Jelinek wrote: > > On Thu, Jan 10, 2019 at 10:46:14AM +0100, Dr. Matthias Kretz wrote: > > > _mm_fixupimm_ps(_mm_getexp_ps(x), x, _mm_set1_epi32(0x00550433), 0x00); > > > > I guess

[PATCH v2] x86-64: {,V}CVTSI2Sx are ambiguous without suffix

For 64-bit these should not be emitted without suffix in AT&T mode (as being ambiguous that way); the suffixes are benign for 32-bit. For consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ. The omission has originally (prior to rev 260691) lead to wrong code being generated for the 6

[SVE ACLE] Two infrastructure tweaks

Hi, The first patch replaces the autogenerated function enum with an explicit one, so that we can have more than one .def entry with the same function base name (e.g. predicated AND vs. integer AND). The second patch makes us get the expected modes from the insn data, rather than force callers to

[C++ Patch] Fix three additional locations

Hi again, this one is also matter of consistency with, say, the precise location that we use for the error message at the beginning of check_methods. Indeed, the sequence of error messages of g++.dg/inherit/pure1.C reflect that. Tested x86_64-linux. Thanks, Paolo. PS: minor issues anyway, b

[PATCH] Define __cpp_lib_erase_if feature test macro

The C++2a draft specifies the value 201811L for this, but as an extension we return the number of elements erased. This is expected to be standardised, so the macro has the value 201900L until a proper value is specified in the draft. * include/bits/erase_if.h: Define __cpp_lib_erase_if.

[PATCH] Fix PR88792

The following avoids a value-number as leader during PRE PHI translation since that exposes us to bogus flow-sensitive info. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. >From d4849ecb2e82e49df4490d92f33c24a851f6e195 Mon Sep 17 00:00:00 2001 From: Richard Guenther D

[PATCH] Fix PR88775

I am testing the following patch teaching VRP predicate analysis about __x.5_4 = (long unsigned int) "hello"; __y.6_5 = (long unsigned int) _3; if (__x.5_4 != __y.6_5) so that we know sth about the relation of the converted entities. This appearantly (didn't back out other stuff) helps PR

[PATCH] Fix part of PR87314, folding of &decl != "foo"

This fixes $subject and also "foo" != "bar" folding which was somehow missing. It fixes only parts of the PR since the PR is about PTA tracking string constants. It might help PR88775 but unless I can confirm that this is just queued for GCC10. You might notice I'm treating string merging poss

[RFC] [Patch] [Debug] Add new NOTE to be used for debugging.

At the moment NOTE_INSN_FUNCTION_BEG is used for three different purposes. The first is as a marker just before the first insn coming from a "source code statement" of the function. Bug 88432 is due to the fact that the note does not accurately point to this logical position in a function -- in tha

Re: [PATCH] x86: Update VFIXUPIMM* Intrinsics to align with the latest Intel SDM

On Donnerstag, 10. Januar 2019 11:39:56 CET Jakub Jelinek wrote: > On Thu, Jan 10, 2019 at 10:46:14AM +0100, Dr. Matthias Kretz wrote: > > _mm_fixupimm_ps(_mm_getexp_ps(x), x, _mm_set1_epi32(0x00550433), 0x00); > > I guess you could use > _mm_mask_fixupimm_ps(_mm_getexp_ps(x), -1, x, _mm_set1_epi3

[PATCH] Check AI_NUMERICSERV is defined before using it

The AI_NUMERICSERV constant is missing from old Darwin systems, so only use it if it's supported. * include/experimental/internet [AI_NUMERICSERV] (resolver_base::numeric_service): Define conditionally. * testsuite/experimental/net/internet/resolver/base.cc: Test it

Re: [PATCH] [RFC] PR target/52813 and target/11807

Hi! On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote: > Bernd Edlinger writes: > > Meanwhile I found out, that the stack clobber has only been ignored up to > > gcc-5 (at least with lra targets, not really sure about reload targets). > > From gcc-6 on, with the exception of PR ar

Re: [v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr

On 04/12/17 23:04 +, Jonathan Wakely wrote: On 03/12/17 23:08 +0200, Ville Voutilainen wrote: Tested on Linux-x64. 2017-11-14 Ville Voutilainen Implement LWG 2221 * include/std/ostream (operator<<(nullptr_t)): New. * testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc: N

Re: [PATCH v2] Fix PR64242

Hi Jakub, Any other comments? I'd like to finish this rather than leaving it in its current half-done state. Wilco   Hi, Jakub Jelinek wrote: On Fri, Dec 07, 2018 at 04:19:22PM +, Wilco Dijkstra wrote: >> The test case doesn't need an aligned object to fail, so why did you add it? > > It

Re: [PATCH] Fix PR84521

ping From: Wilco Dijkstra Sent: 14 December 2018 13:16 To: GCC Patches Cc: nd Subject: [PATCH] Fix PR84521   This fixes and simplifies the setjmp and non-local goto implementation. Currently the virtual frame pointer is saved when using __builtin_setjmp or a non-local goto.  Depending on whet

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On Thu, Jan 10, 2019 at 11:05 AM Jakub Jelinek wrote: > > On Thu, Jan 10, 2019 at 10:53:32AM +, Ramana Radhakrishnan wrote: > > > 2018-11-23 Ramana Radhakrishnan > > > > > > * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New > > > * config/aarch64/aarch64.c

[Patch]Bug 84762 - GCC for PowerPC32 violates the SysV ABI spec for small struct returns

Hi Segher, Find the attached patch for the subjected issue. Please let me know your thoughts and comments on the same. >Do you have a copyright assignment with the FSF? We don't have a copyright assignment with FSF. >- if (!global_options_set.x_aix_struct_return) >+ if (!global_options

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

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? -- Iain --- gcc/d/ChangeLog: 2019-01-10 Iain Buclaw * README.gcc: New file. libphobos/ChangeLog: 2019

Re: [RS6000] Implement -mno-pltseq

On Thu, Jan 10, 2019 at 05:09:06AM -0600, Segher Boessenkool wrote: > On Mon, Jan 07, 2019 at 12:54:02PM +1030, Alan Modra wrote: > > Since the last patch untangled inline PLT and TLS marker support there > > now isn't a way of requesting the older long call sequences on a > > compiler built with i

Re: [PATCH] ARM: fix -masm-syntax-unified (PR88648)

Hi Stefan, On 08/01/19 09:33, Kyrill Tkachov wrote: Hi Stefan, On 01/01/19 23:34, Stefan Agner wrote: > This allows to use unified asm syntax when compiling for the > ARM instruction. This matches documentation and seems what the > initial patch was intended doing when the flag got added. > ---

Re: [RS6000] Implement -mno-pltseq

On Mon, Jan 07, 2019 at 12:54:02PM +1030, Alan Modra wrote: > Since the last patch untangled inline PLT and TLS marker support there > now isn't a way of requesting the older long call sequences on a > compiler built with inline PLT support. This patch adds support for > a new -mno-pltseq option.

Re: [RS6000] Emit inline PLT when -mno-tls-markers

Hi Alan, This patch is okay (for trunk, and backports if needed), thanks! I'll review your other patches next week. Segher On Mon, Jan 07, 2019 at 12:28:44PM +1030, Alan Modra wrote: > I restricted output of inline PLT sequences to when TLS marker relocs > were also available, which is obviou

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On Thu, Jan 10, 2019 at 10:53:32AM +, Ramana Radhakrishnan wrote: > > 2018-11-23 Ramana Radhakrishnan > > > > * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New > > * config/aarch64/aarch64.c (aarch64_override_options_internal): > > Handle > > and pu

[PATCH] Include name of test in filesystem-test.XXXXXX filenames

Also fix some tests that were not cleaning up after themselves, as identified by the change to nonexistent_path. * testsuite/util/testsuite_fs.h (nonexistent_path): Include name of the source file containing the caller. * testsuite/27_io/filesystem/iterators/directory_iter

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On Mon, Dec 3, 2018 at 9:55 AM Ramana Radhakrishnan wrote: > > For quite sometime the kernel guys, (more specifically Ard) have been > talking about using a system register (sp_el0) and an offset from that > for a canary based access. This patchset adds support for a new set of > command line opti

Re: [PATCH] Use __builtin_is_constant_evaluated in std::less etc. (PR tree-optimization/88775)

On 10/01/19 10:02 +0100, Jakub Jelinek wrote: Hi! In Marc's testcase, we generate terrible code for std::string assignment, because the __builtin_constant_p is kept in the IL for way too long and the optimizers (jump threading?) create way too many copies of the memcpy/memmove calls that it is t

Re: [PATCH] Fix dllimport attribute handling (PR c/88568)

On Thu, 10 Jan 2019, Jakub Jelinek wrote: > Hi! > > handle_dll_attribute sets DECL_EXTERNAL on node for "dllimport" on > VAR_DECLs, it wants to handle those as if those vars are actually declared > extern. The problem is that it doesn't clear TREE_STATIC on them, which > is what is normally the

Re: [PATCH] x86: Update VFIXUPIMM* Intrinsics to align with the latest Intel SDM

On Thu, Jan 10, 2019 at 10:46:14AM +0100, Dr. Matthias Kretz wrote: > I strongly believe this API change needs to be reverted (unless I completely > misunderstand how vfixupimm works): > > 1. This change breaks API with previous GCC releases. I.e. source code that > compiled with GCC 8 will not

Re: [PATCH][GCC][DOC] Remove obsolete arm and aarch64 CPU names from invoke.texi

On 12/27/18 12:54 AM, Gerald Pfeifer wrote: > On Fri, 23 Nov 2018, Sam Tebbs wrote: >> The mtune= documentation in doc/invoke.texi contains some obsolete CPU names >> that have been removed from the Arm and AArch64 backends. This patch removes >> them. > I believe this should also be covered in th

Re: [PATCH][AArch64] Use Q-reg loads/stores in movmem expansion

Hi James, On 09/01/19 17:50, James Greenhalgh wrote: On Fri, Dec 21, 2018 at 06:30:49AM -0600, Kyrill Tkachov wrote: Hi all, Our movmem expansion currently emits TImode loads and stores when copying 128-bit chunks. This generates X-register LDP/STP sequences as these are the most preferred r

[PATCH] Fix dllimport attribute handling (PR c/88568)

Hi! handle_dll_attribute sets DECL_EXTERNAL on node for "dllimport" on VAR_DECLs, it wants to handle those as if those vars are actually declared extern. The problem is that it doesn't clear TREE_STATIC on them, which is what is normally the case on VAR_DECLs that are DECL_EXTERNAL and so the C F

[PATCH] Remove bare 'throw' expression that breaks -fno-exceptions build

This is debugging code that wasn't meant to be left in, and prevents building the filesystem TS library with -fno-exceptions. It was already removed from trunk months aog, this removes it from the branch too. * src/filesystem/std-path.cc (path::remove_filename()): Remove debug che

Re: [PATCH] x86: Update VFIXUPIMM* Intrinsics to align with the latest Intel SDM

I strongly believe this API change needs to be reverted (unless I completely misunderstand how vfixupimm works): 1. This change breaks API with previous GCC releases. I.e. source code that compiled with GCC 8 will not compile with GCC 9 anymore. If you really want a "simplified" fixup intrinsic

Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI

Steve Ellcey writes: > On Wed, 2019-01-09 at 10:00 +, Richard Sandiford wrote: > > Thanks for the quick turnaround on the comments Richard. Here is a new > version where I tried to address all the issues you raised. One thing > I noticed is that I think your calls_have_same_clobbers_p functi

[PATCH] Use __builtin_is_constant_evaluated in std::less etc. (PR tree-optimization/88775)

Hi! In Marc's testcase, we generate terrible code for std::string assignment, because the __builtin_constant_p is kept in the IL for way too long and the optimizers (jump threading?) create way too many copies of the memcpy/memmove calls that it is then hard to bring it back in sanitity. On the te