Re: [RFC][PATCH] Postpone print of --help=* option.

On 01/04/2019 13:11, Martin Liška wrote: > Hi. > > Last week I was curious which warnings are disabled by default on top > of -Wall and -Wextra. Thus I used --help=warning and noticed some discrepancy > in between documentation and output of the --help option. > > I created PR89885 where I

Re: [PATCH] PR libstdc++/61761 fix std::proj for targets without C99 cproj

On 03/05/2019 12:16, Jonathan Wakely wrote: > On 03/05/19 09:23 +0000, Szabolcs Nagy wrote: >> On 01/05/2019 01:09, Jonathan Wakely wrote: >>> The current generic implementation of __complex_proj used when cproj is >>> not available calculates the wrong projection

Re: [PATCH] PR libstdc++/61761 fix std::proj for targets without C99 cproj

On 01/05/2019 01:09, Jonathan Wakely wrote: > The current generic implementation of __complex_proj used when cproj is > not available calculates the wrong projection, giving a different result > than given by C99's cproj. > > When C99 cproj is not available but isinf and copysign are, use those

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

On 08/11/2018 17:52, Steve Ellcey wrote: > This is a resubmission of patch 1 to support the Aarch64 SIMD ABI [1] in > GCC, it does not have any functional changes from the last submit. > > The significant difference between the standard ARM ABI and the SIMD ABI > is that in the normal ABI a

Re: autovectorization in gcc

On 10/01/2019 08:19, Richard Biener wrote: > On Wed, 9 Jan 2019, Jakub Jelinek wrote: > >> On Wed, Jan 09, 2019 at 11:10:25AM -0500, David Malcolm wrote: >>> extern void vf1() >>> { >>>#pragma vectorize enable >>>for ( int i = 0 ; i < 32768 ; i++ ) >>> data [ i ] = std::sqrt ( data [

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

On 17/12/2018 18:22, Uecker, Martin wrote: > Am Montag, den 17.12.2018, 15:25 + schrieb Szabolcs Nagy: >> On 16/12/2018 22:45, Uecker, Martin wrote: >>> Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law: >>>> Ultimately using function descriptors is

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

On 16/12/2018 22:45, Uecker, Martin wrote: > Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law: >> Ultimately using function descriptors is an ABI breaking choice and we >> might declare that function descriptors imply higher function >> alignments.   > > Increasing the alignment is not an

Re: Parallelize the compilation using Threads

On 15/11/18 10:29, Richard Biener wrote: > In my view (I proposed the thing) the most interesting parts are > getting GCCs global state documented and reduced. The parallelization > itself is an interesting experiment but whether there will be any > substantial improvement for builds that can

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 04/11/18 09:05, Stafford Horne wrote: > On Mon, Oct 29, 2018 at 02:28:11PM +0000, Szabolcs Nagy wrote: >> On 27/10/18 05:37, Stafford Horne wrote: ... >>> +#undef LINK_SPEC >>> +#define LINK_SPEC "%{h*}

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 27/10/18 05:37, Stafford Horne wrote: > +++ b/gcc/config/or1k/linux.h > @@ -0,0 +1,44 @@ > +/* Linux Definitions for OpenRISC. > + Copyright (C) 2018 Free Software Foundation, Inc. > + Contributed by Stafford Horne. > + > + This file is part of GCC. > + > + GCC is free software; you can

Re: TLSDESC clobber ABI stability/futureproofness?

On 11/10/18 04:53, Alexandre Oliva wrote: > On Oct 10, 2018, Rich Felker wrote: >> For aarch64 at least, according to discussions I had with Szabolcs >> Nagy, there is an intent that any new extensions to the aarch64 >> register file be treated as clobbered by tlsdesc func

Re: [PATCH v3] Change default to -fno-math-errno

On 04/10/18 14:25, Jeff Law wrote: > On 10/4/18 6:37 AM, Richard Biener wrote: >> On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote: >>> >>> On Thu, 4 Oct 2018, Richard Biener wrote: >>> The other issue is that we're treating -fno-math-errno as disabling errno handling in general (not

Re: RFC: [PATCH] x86: Add -mzero-caller-saved-regs=[skip|used|all]

On 26/09/18 19:10, H.J. Lu wrote: Add -mzero-caller-saved-regs=[skip|used|all] command-line option and zero_caller_saved_regs("skip|used|all") function attribue: 1. -mzero-caller-saved-regs=skip and zero_caller_saved_regs("skip") Don't zero caller-saved integer registers upon function return.

Re: RFC: Creating a more efficient sincos interface

On 13/09/18 14:52, Florian Weimer wrote: > On 09/13/2018 03:27 PM, Wilco Dijkstra wrote: >> Hi, >> >> The existing sincos functions use 2 pointers to return the sine and cosine >> result. In >> most cases 4 memory accesses are necessary per call. This is inefficient and >> often >> significantly

[PATCH] Change AArch64 specific FMAX/FMIN tests into generic MAX_EXPR/MIN_EXPR tests

gfortran now always uses MAX_EXPR/MIN_EXPR for MAX/MIN intrinsics, so the AArch64 specific FMAX/FMIN tests are no longer valid. 2018-08-22 Szabolcs Nagy * gfortran.dg/max_fmax_aarch64.f90: Rename to... * gfortran.dg/max_expr.f90: ...this. * gfortran.dg

Re: [PATCH][C++] Fix PR86763, wrong-code with TYPE_TYPELESS_STORAGE

On 20/08/18 10:33, Richard Biener wrote: On Mon, 20 Aug 2018, Szabolcs Nagy wrote: On 02/08/18 09:30, Richard Biener wrote: ... + clock_gettime(CLOCK_REALTIME, ); this fails on targets without clock_gettime (baremetal) or targets that need -lrt at link time. can we use something else here

Re: [PATCH][C++] Fix PR86763, wrong-code with TYPE_TYPELESS_STORAGE

On 02/08/18 09:30, Richard Biener wrote: --- gcc/testsuite/g++.dg/torture/pr86763.C (nonexistent) +++ gcc/testsuite/g++.dg/torture/pr86763.C (working copy) @@ -0,0 +1,36 @@ +// { dg-do run } +// { dg-additional-options "-fschedule-insns2 -fstrict-aliasing" } + +#include +#include

[PATCH] Fix poly types after PR tree-optimization/71625 strlen optimization

caused by poly initializers getting treated as string literals. Tested on arm-none-linux-gnueabihf. gcc/ChangeLog: 2018-08-17 Szabolcs Nagy * config/arm/arm-builtins.c (arm_init_simd_builtin_types): Clear polyNxK_t element's TYPE_STRING_FLAG. diff --git a/gcc/config/arm/arm

Re: [PATCH] PR libstdc++/86846 Alternative to pointer-width atomics

On 14/08/18 14:13, Jonathan Wakely wrote: Define a class using std::mutex for when std::atomic cannot be used to implement the default memory resource. When std::mutex constructor is not constexpr the constant_init trick won't work, so just define a global and use init_priority for it. The

Re: [PATCH] libstdc++-v3: Have aligned_alloc() on Newlib

On 13/08/18 19:57, Jonathan Wakely wrote: On 13/08/18 13:04 +0100, Jonathan Wakely wrote: On 13/08/18 12:55 +0100, Szabolcs Nagy wrote: On 09/08/18 10:08, Jonathan Wakely wrote: Yes please, on trunk and 7 and 8. It's better to use the standard aligned_alloc if available. but the newlib

Re: [PATCH] libstdc++-v3: Have aligned_alloc() on Newlib

On 09/08/18 10:08, Jonathan Wakely wrote: On 09/08/18 06:56 +0200, Sebastian Huber wrote: On 08/08/18 16:33, Jonathan Wakely wrote: On 08/08/18 16:22 +0200, Ulrich Weigand wrote: Jonathan Wakely wrote: Aha, so newlib was using memalign previously: @@ -53,20 +54,24 @@ aligned_alloc

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

On 18/07/18 13:31, Umesh Kalappa wrote: Hi Nagy/Ramana, Please help us to review the attached patch and do let me know your comments . No regress in the gcc.target suite for arm target. have you submitted a copyright assignment form yet? https://gcc.gnu.org/contribute.html Index:

Re: Subnormal float support in armv7(with -msoft-float) for intrinsics

On 12/07/18 16:20, Umesh Kalappa wrote: Hi everyone, we have our source base ,that was compiled for armv7 on gcc8.1 with soft-float and for following input a=0x0010 b=0x0001 result = a - b ; we are getting the result as "0x000e" and with -mhard-float

Re: How to get GCC on par with ICC?

On 11/06/18 11:05, Martin Jambor wrote: The int rate numbers (running 1 copy only) were not too bad, GCC was only about 2% slower and only 525.x264_r seemed way slower with GCC. The fp rate numbers (again only 1 copy) showed a larger difference, around 20%.  521.wrf_r was more than twice as slow

Re: libmvec in gcc to have vector math in fortran

On 15/06/18 08:59, Florian Weimer wrote: * Richard Biener: 'pure' makes it pure but there doesn't seem to be a way to make it const? Does Fortran support setting the rounding mode? yes, but vec math is only enabled with -ffast-math (so it can assume -fno-rounding-math) In C, sin is not

Re: libmvec in gcc to have vector math in fortran

On 10/04/18 14:27, Richard Biener wrote: On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek wrote: On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote: I wonder if it is possible for glibc to ship a "module" for fortran instead containing the appropriate

Re: libmvec in gcc to have vector math in fortran

On 10/04/18 11:14, Janne Blomqvist wrote: As I mentioned previously in that thread you linked to, the fortran frontend never generates a direct call to libm sin(), or for that matter ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And similarly for other libm functions that have

libmvec in gcc to have vector math in fortran

i had a query earlier about libmvec vector functions in fortran: https://gcc.gnu.org/ml/gcc/2017-11/msg7.html but there were no simple solutions to make math functions vectorizable in fortran, because it's hard to make libc headers with simd attributes visible to the fortran front end. i

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On 27/02/18 12:56, Ruslan Nikolaev wrote: Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. no, 1) your proposal would make gcc non-conforming to iso c unless it changes how static const objects are emitted. 2) the two

Re: GCC interpretation of C11 atomics (DR 459)

On 26/02/18 13:56, Alexander Monakov wrote: On Mon, 26 Feb 2018, Szabolcs Nagy wrote: rmw load is only valid if the implementation can guarantee that atomic objects are never read-only. OK, but that sounds like a matter of not emitting atomic objects into .rodata, which shouldn't be a big

Re: GCC interpretation of C11 atomics (DR 459)

On 26/02/18 04:00, Ruslan Nikolaev via gcc wrote: 1. Not consistent with clang/llvm which completely supports double-width atomics for arm32, arm64, x86 and x86-64 making it possible to write portable code (w/o specific extensions or assembly code) across all these architectures (which is

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 21/02/18 10:11, Alexandre Oliva wrote: On Feb 15, 2018, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: i see assembler slow downs with these location view patches i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 [LVU] reset view at function entry, omit views at lin

Re: [PATCH] Fix PR84399

On 16/02/18 08:15, Richard Biener wrote: Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2018-02-16 Richard Biener PR tree-optimization/84399 * graphite-scop-detection.c (scop_detection::stmt_simple_for_scop_p): For

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 13/02/18 13:43, Alexandre Oliva wrote: On Feb 12, 2018, Alexandre Oliva wrote: This patch supersedes the previous one. Testing underway... Ok if it succeeds? I failed to update the patch I posted after making a correct to symbol poisoning, that had caused builds to

Re: [PATCH] Handle PowerPC64 ELFv1 function descriptors in libbacktrace (PR other/82368)

On 14/02/18 11:41, Jakub Jelinek wrote: Hi! As mentioned in detail in the PR, PowerPC64 ELFv1 function symbols point to function descriptors in .opd section rather than actual code, and one needs to read the code address from the .opd section in order to associate symbols with .text addresses.

Re: [PATCH v6] aarch64: Add split-stack support

On 07/02/18 18:07, Adhemerval Zanella wrote: 5. The TCB support on GLIBC is meant to be included in version 2.28. ... +/* -fsplit-stack uses a TCB field available on glibc-2.27. GLIBC also + exports symbol, __tcb_private_ss, to signal it has the field available + on TCB bloc. This aims

Re: -static-pie and -static -pie

On 31/01/18 15:44, Cory Fields wrote: After looking at this for quite a while, I'm afraid I'm unsure how to proceed. As of now, static and static-pie are mutually exclusive. So given the GNU_USER_TARGET_STARTFILE_SPEC you pasted earlier, "static" matches before "static-pie", causing the wrong

Re: [PATCH] Fix gcc.target/aarch64/sve/peel_ind_1.c for -mcmodel=tiny

On 24/01/18 20:10, Richard Sandiford wrote: Szabolcs Nagy <szabolcs.n...@arm.com> writes: Fix test failures with -mcmodel=tiny when adr is generated instead of adrp. FAIL: gcc.target/aarch64/sve/peel_ind_1.c -march=armv8.2-a+sve scan-assembler \\tadrp\\tx[0-9]+, x\\n FAIL: gcc.target/a

[PATCH] Fix gcc.target/aarch64/sve/peel_ind_1.c for -mcmodel=tiny

: gcc.target/aarch64/sve/peel_ind_3.c -march=armv8.2-a+sve scan-assembler \\tadrp\\tx[0-9]+, x\\n gcc/testsuite/ChangeLog: 2018-01-24 Szabolcs Nagy <szabolcs.n...@arm.com> * gcc.target/aarch64/sve/peel_ind_1.c: Match (adrp|adr) in scan-assembler. * gcc.target/aarch64/sve/peel_ind_2.c: Li

Re: [PATCH] Fix PR83435

On 11/01/18 13:41, Richard Biener wrote: > 2018-01-11 Richard Biener > > PR tree-optimization/83435 > * graphite.c (canonicalize_loop_form): Ignore fake loop exit edges. > * graphite-scop-detection.c (scop_detection::get_sese): Likewise. > *

Re: [PATCH, rs6000] generate loop code for memcmp inline expansion

On 08/01/18 19:37, Aaron Sawdey wrote: > On Tue, 2017-12-12 at 10:13 -0600, Segher Boessenkool wrote: >> > Please fix those trivialities, and it's okay for trunk (after the >> > rtlanal patch is approved too). Thanks! > Here's the final version of this, which is committed as 256351. > > >

Re: [RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)

On 28/10/17 05:08, Jeff Law wrote: > On 10/13/2017 02:26 PM, Wilco Dijkstra wrote: >> For larger frames the first oddity is that there are now 2 separate params >> controlling how probes are generated: >> >> stack-clash-protection-guard-size (default 12, but set to 16 on AArch64) >>

Re: [PATCH 7/7]: Enable clobber high for tls descs on Aarch64

On 17/11/17 08:42, Andrew Pinski wrote: > On Fri, Nov 17, 2017 at 12:21 AM, Alan Hayward wrote: >> >>> On 16 Nov 2017, at 19:32, Andrew Pinski wrote: >>> >>> On Thu, Nov 16, 2017 at 4:35 AM, Alan Hayward wrote: This final patch

Re: libmvec simd math functions in fortran

On 01/11/17 16:47, Szabolcs Nagy wrote: > On 01/11/17 16:26, Jakub Jelinek wrote: >> On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrote: >>> is there a way to get vectorized math functions in fortran? >>> >>> in c code there is attribute simd dec

Re: libmvec simd math functions in fortran

On 01/11/17 16:26, Jakub Jelinek wrote: > On Wed, Nov 01, 2017 at 04:23:11PM +0000, Szabolcs Nagy wrote: >> is there a way to get vectorized math functions in fortran? >> >> in c code there is attribute simd declarations or openmp >> declare simd pragma to tell the compi

libmvec simd math functions in fortran

is there a way to get vectorized math functions in fortran? in c code there is attribute simd declarations or openmp declare simd pragma to tell the compiler which functions have simd variant, but i see no such thing in fortran. some targets have -mveclibabi=type which allows vectorizing a set

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

On 29/09/17 21:29, Steve Ellcey wrote: > On Thu, 2017-09-28 at 12:31 +0100, Szabolcs Nagy wrote: >> >> i think this should be improved, see below. > > Those were all good suggestions, here is a new patch that incorporates > the changes. I fixed the IFUNC_OPT

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

On 31/08/17 18:24, Steve Ellcey wrote: > On Tue, 2017-08-29 at 12:25 +0100, Szabolcs Nagy wrote: >> > >> > in glibc the hwcap is not used, because it has accesses to >> > cached dispatch info, but in libatomic using the hwcap >> > argument is the

Re: [PATCH][aarch64] Enable ifunc resolver attribute by default

On 05/09/17 18:09, Steve Ellcey wrote: > On Mon, 2017-09-04 at 15:40 +0100, Szabolcs Nagy wrote: > >> this is not the right default for bionic, uclibc and musl >> >> (gcc does not distinguish between supporting ifunc in the >> compiler vs runtime, so when ifunc is

Re: [PATCH][aarch64] Enable ifunc resolver attribute by default

On 12/06/17 16:02, Steve Ellcey wrote: > I recently noticed that the GCC 'resolver' attribute used for ifunc's is not > on by default for aarch64 even though all the infrastructure to support it is > in place. I made memcpy an ifunc on aarch64 in glibc and am looking at > possibly using it for

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

On 28/08/17 19:25, Steve Ellcey wrote: > On Fri, 2017-08-25 at 15:37 +0100, Szabolcs Nagy wrote: > >> the use of ifunc in gcc target libraries was a mistake >> in my opinion, there are several known bugs in the ifunc >> design and uclibc/musl/bionic don't plan to support

Re: [pr 81982] wide-int.h change broke native arm-* gcc

On 25/08/17 14:27, Szabolcs Nagy wrote: > i don't see corresponding email thread in gcc-patches, but > since this commit: > https://gcc.gnu.org/viewcvs/gcc?view=revision=251260 > > i see arm-* native compiler miscompile libstdc++, > note that the cross compiler compiles it corre

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

On 07/08/17 21:44, Steve Ellcey wrote: > This patch uses the libatomic IFUNC infrastructure so that aarch64 > machines that support the LSE instructions can use them. Note that > aarch64 still isn't enabling IFUNC support by default though I have > submitted a patch to do that. You can enable

[pr 81982] wide-int.h change broke native arm-* gcc

i don't see corresponding email thread in gcc-patches, but since this commit: https://gcc.gnu.org/viewcvs/gcc?view=revision=251260 i see arm-* native compiler miscompile libstdc++, note that the cross compiler compiles it correctly. i guess it can be some latent bug that got uncovered, but it is

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On 16/08/17 18:38, Joseph Myers wrote: > On Wed, 16 Aug 2017, Eric Gallager wrote: >> I see Richi redid all his 7.2 release changes; does that imply that >> the server restore is now complete? > > No, there's still a search process ongoing to identify corrupted or > missing files by comparison

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On 16/08/17 18:38, Joseph Myers wrote: > On Wed, 16 Aug 2017, Eric Gallager wrote: >> I see Richi redid all his 7.2 release changes; does that imply that >> the server restore is now complete? > > No, there's still a search process ongoing to identify corrupted or > missing files by comparison

Re: [PATCH][2/2] early LTO debug, main part

On 22/08/17 11:17, Richard Biener wrote: > On Tue, 22 Aug 2017, Szabolcs Nagy wrote: >> on aarch64_be-none-elf i see >> >> PASS->FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors) >> PASS->FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for exc

Re: [PATCH][2/2] early LTO debug, main part

On 04/08/17 13:21, Richard Biener wrote: > On Thu, 3 Aug 2017, Jason Merrill wrote: >> OK if testing passes. > > Thanks. Meanwhile testing passed. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, LTO bootstrapped > on x86_64-unknown-linux-gnu (both all languages). I've successfully >

Re: RFC: [PATCH] Add warn_if_not_aligned attribute

On 17/08/17 15:56, H.J. Lu wrote: > On Thu, Aug 17, 2017 at 6:52 AM, Joseph Myers wrote: >> On Sat, 8 Jul 2017, H.J. Lu wrote: >> >>> +@item -Wpacked-not-aligned @r{(C, C++, Objective-C and Objective-C++ only)} >>> +@opindex Wpacked-not-aligned >>> +@opindex

Re: Behaviour of __forced_unwind with noexcept

On 15/08/17 16:47, Richard Biener wrote: > On Tue, Aug 15, 2017 at 5:21 PM, Ron wrote: >> Is changing the cancellation state really an expensive operation? >> Moreso than the checking which I assume already needs to be done for >> noexcept to trap errant exceptions? > > The

Re: Behaviour of __forced_unwind with noexcept

On 15/08/17 16:21, Ron wrote: > On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote: >> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely >> wrote: >>> On 15 August 2017 at 11:24, Richard Biener >>> wrote: On Tue, Aug 15, 2017

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On 15/08/17 04:10, Martin Sebor wrote: > On 08/14/2017 04:22 PM, Eric Gallager wrote: >> I'm emailing this manually to the list because Bugzilla is down and I >> can't file a bug on Bugzilla about Bugzilla being down. The error >> message looks like this: > > Bugzilla and the rest of gcc.gnu.org

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On 15/08/17 04:10, Martin Sebor wrote: > On 08/14/2017 04:22 PM, Eric Gallager wrote: >> I'm emailing this manually to the list because Bugzilla is down and I >> can't file a bug on Bugzilla about Bugzilla being down. The error >> message looks like this: > > Bugzilla and the rest of gcc.gnu.org

[PATCH committed][AArch64] Fix dbl_mov_immediate_1.c test

Make sure adrp is used for literal loads. committed as obvious. gcc/testsuite/ChangeLog: 2017-08-14 Szabolcs Nagy <szabolcs.n...@arm.com> * gcc.target/aarch64/dbl_mov_immediate_1.c: Add -mno-pc-relative-literal-loads. diff --git a/gcc/testsuite/gcc.target/a

Re: [PATCH][GCC][AArch64] Inline calls to lrint when possible

On 07/06/17 12:38, Tamar Christina wrote: > Hi All, > > This patch allows the inlining of lrint when -fno-math-errno > assuming that errno does not need to be set when the rounded value > is not representable as a long. > turns out emitting frintx+fcvtzs is wrong for ilp32 because spurious

Re: [PATCH][2/2] PR60510, reduction chain vectorization w/o SLP

On 03/07/17 14:42, Richard Biener wrote: > > The following is the patch enabling non-SLP vectorization of failed SLP > reduction chains. It simply dissolves the group composing the SLP > reduction chain when vect_analyze_slp fails to detect the SLP and then > fixes up the remaining pieces in

Re: RFC: Add ___tls_get_addr

On 05/07/17 17:18, H.J. Lu wrote: > On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: >> On 05/07/17 16:38, H.J. Lu wrote: >>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by >>> GCCs older than GCC 4.9.4: >

Re: RFC: Add ___tls_get_addr

On 05/07/17 16:38, H.J. Lu wrote: > On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by > GCCs older than GCC 4.9.4: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 > > continue to work even if vector instructions are used by functions called > from

Re: [PATCH] multiarch support for non-glibc linux systems

On 07/06/17 18:22, Szabolcs Nagy wrote: > Current multiarch directory name is always *-linux-gnu* on linux, > this patch configures different names for uclibc and musl targets. > (tested by the debian rebootstrap scripts for various *-linux-musl > and *-linux-uclibc targets see debian

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 22/06/17 16:30, Jeff Law wrote: > It just happens to be the case that x86 hits *sp when it stores the > return pointer and that ppc always stores the backchain into *sp when it > allocates additional stack space. As a result on those targets we know > the offset between the stack pointer and

[PATCH] multiarch support for non-glibc linux systems

Current multiarch directory name is always *-linux-gnu* on linux, this patch configures different names for uclibc and musl targets. (tested by the debian rebootstrap scripts for various *-linux-musl and *-linux-uclibc targets see debian bug #861588) gcc/ 2017-06-07 Szabolcs Nagy <szabolc

Re: [contribution] C11 threads implementation for Unix and Windows environments

On 20/02/17 07:49, Sebastian Huber wrote: > Hello Gokan, > > you may have a look at: > > https://svnweb.freebsd.org/base/head/lib/libstdthreads/ note that despite the looks this is non-portable and non-conforming implementation, it is way better than the posted github code, but it can still

Re: [PATCH][ARM][PR target/78945] Fix libatomic on armv7-m

On 25/01/17 12:35, Szabolcs Nagy wrote: > ARM libatomic inline asm uses sel, uadd8, uadd16 instructions > which are only available if __ARM_FEATURE_SIMD32 is defined. > > libatomic/ > 2017-01-25 Szabolcs Nagy <szabolcs.n...@arm.com> > > PR target/78945 &g

Re: Successful bootstrap and install of gcc (GCC) 6.3.0 on aarch64-unknown-linux-gnu

On 25/01/17 19:02, Aaro Koskinen wrote: > Configured with: ../gcc-6.3.0/configure --with-arch=armv8-a+crc > --with-cpu=cortex-a53 --disable-multilib --disable-nls > --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ > --host=aarch64-unknown-linux-gnu

[PATCH][ARM][PR target/78945] Fix libatomic on armv7-m

ARM libatomic inline asm uses sel, uadd8, uadd16 instructions which are only available if __ARM_FEATURE_SIMD32 is defined. libatomic/ 2017-01-25 Szabolcs Nagy <szabolcs.n...@arm.com> PR target/78945 * config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32. diff

Re: .../lib/gcc//7.1.1/ vs. .../lib/gcc//7/

On 06/01/17 13:11, Jakub Jelinek wrote: > On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote: >> On 06/01/17 12:48, Jakub Jelinek wrote: >>> SUSE and some other distros use a hack that omits the minor and patchlevel >>> versions from the directory layout,

Re: .../lib/gcc//7.1.1/ vs. .../lib/gcc//7/

On 06/01/17 12:48, Jakub Jelinek wrote: > SUSE and some other distros use a hack that omits the minor and patchlevel > versions from the directory layout, just uses the major number, it is very what is the benefit?

Re: GCC libatomic ABI specification draft

On 22/12/16 17:37, Segher Boessenkool wrote: > We do not always have all atomic instructions. Not all processors have > all, and it depends on the compiler flags used which are used. How would > libatomic know what compiler flags are used to compile the program it is > linked to? > > Sounds

Re: GCC libatomic ABI specification draft

On 20/12/16 13:26, Ulrich Weigand wrote: > Torvald Riegel wrote: >> On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote: >>> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote: Thanks for the comment. Yes, the ABI requires libatomic must query the hardware. This is

Re: GCC libatomic ABI specification draft

On 17/11/16 20:12, Bin Fan wrote: > > Although this ABI specification specifies that 16-byte properly aligned > atomics are inlineable on platforms > supporting cmpxchg16b, we document the caveats here for further discussion. > If we decide to change the > inlineable attribute for those

Re: [PATCH v2][PR libgfortran/78314] Fix ieee_support_halting

On 21/11/16 14:16, FX wrote: > Can you XFAIL the test on your platform, open a PR and assign it to me? OK. Committed. ARM and AArch64 may not support trapping so runtime and compile time check can differ. gcc/testsuite/ 2016-11-22 Szabolcs Nagy <szabolcs.n...@arm.com> PR li

Re: [PATCH v2][PR libgfortran/78314] Fix ieee_support_halting

On 21/11/16 14:16, FX wrote: >> it seems this broke ieee_8.f90 which tests compile time vs runtime value of >> ieee_support_halting >> if fortran needs this, then support_halting should be always false on arm >> and aarch64. >> but i'm not familiar enough with fortran to tell if there is some

Re: [PATCH v2][PR libgfortran/78314] Fix ieee_support_halting

On 16/11/16 16:53, Szabolcs Nagy wrote: > ieee_support_halting only checked the availability of status > flags, not trapping support. On some targets the later can > only be checked at runtime: feenableexcept reports if > enabling traps failed. > > So check trapping support by

[PATCH v2][PR libgfortran/78314] Fix ieee_support_halting

to check if it is supported. Tested on aarch64-linux-gnu and x86_64-linux-gnu. gcc/testsuite/ 2016-11-16 Szabolcs Nagy <szabolcs.n...@arm.com> PR libgfortran/78314 * gfortran.dg/ieee/ieee_6.f90: Use ieee_support_halting. libgfortran/ 2016-11-16 Szabolcs Nagy <szabolcs.n..

Re: [PATCH][PR libgfortran/78314] Fix ieee_support_halting

On 15/11/16 16:22, FX wrote: >> There seems to be a separate api for checking trapping support: >> ieee_support_halting, but it only checked if the exception status >> flags are available, so check trapping support too by enabling >> and disabling traps. > > Thanks for the patch. > > I am

[PATCH][PR libgfortran/78314] Fix ieee_support_halting

just fine.) Tested on aarch64-linux-gnu and x86_64-linux-gnu. gcc/testsuite/ 2016-11-15 Szabolcs Nagy <szabolcs.n...@arm.com> PR libgfortran/78314 * gfortran.dg/ieee/ieee_6.f90: Use ieee_support_halting. libgfortran/ 2016-11-15 Szabolcs Nagy <szabolcs.n..

[PATCH][i386][musl] Add cpuinfo to static libgcc only on *-musl*

this to gcc-6 because musl dynamic linker cannot load the libgcc_s.so.1 with the versioned symbols (not an abi break: those symbols were never used on musl and the current code does not work). libgcc/ChangeLog: 2016-11-11 Szabolcs Nagy <szabolcs.n...@arm.com> * config.host (i[3456]86-

Re: [PATCH, GCC] Fix conflicting posix_memalign declaration error

On 28/10/16 11:38, Bernd Schmidt wrote: > On 10/27/2016 10:47 PM, Caroline Tice wrote: >> >> * config/i386/pmm_malloc.h (posix_memalign): Add ifdefs to only >> decorate the declaration with 'throw()' if __GLIBC__ is defined. > > I seem to recall a similar patch being submitted by

Re: [PATCH][AARCH64]Skip gcc.target/aarch64/pr66912.c in tiny or large memory model.

On 27/10/16 11:25, Renlin Li wrote: > Hi all, > > This a simple patch to fix gcc.target/aarch64/pr66912.c. > It's a test case only applicable to small memory model which is the default > one. > /* { dg-final { scan-assembler ":got(page_lo15)?:n_common" } } */ i think this is supposed to work

Re: [PATCH] Define 3-argument overloads of std::hypot for C++17 (P0030R1)

On 30/09/16 10:35, Szabolcs Nagy wrote: > On 29/09/16 14:37, Andre Vieira (lists) wrote: >> >> On arm-none-eabi I'm seeing a failure for the long double type and inputs: >> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l } >> >> The abs(frac) is higher tha

Re: [PATCH] Define 3-argument overloads of std::hypot for C++17 (P0030R1)

On 29/09/16 14:37, Andre Vieira (lists) wrote: > > On arm-none-eabi I'm seeing a failure for the long double type and inputs: > { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l } > > The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that a > reasonable difference? Should we raise

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 21/09/16 15:37, Alexander Monakov wrote: > On Wed, 21 Sep 2016, Martin Sebor wrote: >> On 09/21/2016 01:11 AM, Markus Trippelsdorf wrote: >>> The patch uses "nul" instead of "null" throughout. >> >> Yes, that's intentional. NUL and null are alternate spellings for >> the same character. I went

Re: [PATCH, PR71602, 4/4] Make canonical_va_list_type more strict

On 29/08/16 17:12, Tom de Vries wrote: > On 29/08/16 17:51, Joseph Myers wrote: >> On Wed, 24 Aug 2016, Tom de Vries wrote: >> >>> This patch fixes PR71602 by making canonical_va_list_type more strict. > 2016-08-22 Tom de Vries > > PR C/71602 > * builtins.c

Re: [PATCH] Optimize strchr (s, 0) to strlen

On 15/09/16 14:49, Jakub Jelinek wrote: > On Thu, Sep 15, 2016 at 01:38:45PM +, Wilco Dijkstra wrote: >> __rawmemchr is not the fastest on any target I tried, including x86, so >> GLIBC's >> current default behaviour of always using __rawmemchr is inefficient. GCC >> doesn't >> support

Re: [PATCH] Optimize strchr (s, 0) to strlen

On 14/09/16 14:45, Jakub Jelinek wrote: > I think for the middle-end, using strchr (a, 0) as canonical instead of a + > strlen (a) > is better, and at expansion time we can decide what to use (a + strlen (a) > if you'd expand strlen inline, rather than as a function call, or > __rawmemchr (which

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On 10/09/16 07:59, Christophe Lyon wrote: > On 9 September 2016 at 23:20, Jason Merrill wrote: >> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote: >>> On 08/09/16 09:10 +0200, Marc Glisse wrote: Do we want a generic fallback implementation

Re: [PATCH 3/4][PR 71931] Fix libitm tests

On 06/09/16 18:34, Mike Stump wrote: > On Sep 6, 2016, at 2:11 AM, Torvald Riegel <trie...@redhat.com> wrote: >> >> On Wed, 2016-08-24 at 20:08 +0100, Szabolcs Nagy wrote: >>> Pass build time CC make var down to dejagnu so the sysroot >>> is set correc

Re: Implement C _FloatN, _FloatNx types [version 6]

On 31/08/16 18:26, Joseph Myers wrote: > On Wed, 31 Aug 2016, James Greenhalgh wrote: > >> My concern with this is that the use of comparisons of FLT_EVAL_METHOD >> against 0 that Szabolcs is referring to is common and can have performance >> implications. In glibc for example, >> >> static

Re: [PATCH 1/4][PR 71931] Fix libatomic tests

On 24/08/16 23:08, Joseph Myers wrote: > On Wed, 24 Aug 2016, Szabolcs Nagy wrote: > >> diff --git a/libatomic/testsuite/lib/libatomic.exp >> b/libatomic/testsuite/lib/libatomic.exp >> index cafab54..e374c64 100644 >> --- a/libatomic/testsuite/lib/libatomic.exp &g

[PATCH][mips] Add support for mips*r6-*-musl

to fix that. If the toolchain is configured with mipsisa32r6-linux-musl the dynlinker name is wrong unless one explicitly passes -mips32r6 to gcc (same for the assembler and linker: they don't get -mips32r6 by default). gcc/ 2016-08-24 Szabolcs Nagy <szabolcs.n...@arm.com> * confi

<    1   2   3   4   5   >