Re: [PATCH] [AArch64, Falkor] Adjust Falkor's sign extend reg+reg address cost

On 08/01/2018 04:24 AM, James Greenhalgh wrote: OK if this is what is best for your subtarget. I have pushed this on behalf of Luis since he is on holiday. Thanks, Siddhesh

Re: [PATCH] [AArch64, Falkor] Switch to using Falkor-specific vector costs

On 08/01/2018 04:23 AM, James Greenhalgh wrote: On Wed, Jul 25, 2018 at 01:10:34PM -0500, Luis Machado wrote: The adjusted vector costs give Falkor a reasonable boost in performance for FP benchmarks (both CPU2017 and CPU2006) and doesn't change INT benchmarks that much. About 0.7% for CPU2017 F

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

While building for Newlib, some configure checks must be hard coded. The aligned_alloc() is supported since 2015 in Newlib. libstdc++-v3 PR target/85904 * configure.ac): Define HAVE_ALIGNED_ALLOC if building for Newlib. * configure: Regnerate. --- libstdc++-v3/con

[PATCH v3] Add HXT Phecda core support

HXT semiconductor's CPU core Phecda, as a variant of Qualcomm qdf24xx, reuses the same tuning structure and pipeline with it. 2018-08-08 Hongbo Zhang * config/aarch64/aarch64-cores.def: Add phecda core. * config/aarch64/aarch64-tune.md: Regenerate. * doc/invoke.texi: Ad

Re: [PATCH v3] Add HXT Phecda core support

Hi James, You said OK to this previous v2 patch: https://patchwork.ozlabs.org/patch/933135/ Now I re-base it to the latest GCC commit. If this is OK, please apply this patch on my behalf. Thanks. On 8 August 2018 at 18:38, Hongbo Zhang wrote: > HXT semiconductor's CPU core Phecda, as a variant o

Re: [PATCH] convert braced initializers to strings (PR 71625)

On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote: > On 08/07/2018 02:57 AM, Jason Merrill wrote: >> >> On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote: >>> >>> On 07/31/2018 07:38 AM, Jason Merrill wrote: On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote: > > >

Re: dejagnu version update?

On 7 August 2018 18:34:30 CEST, Segher Boessenkool wrote: >On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote: >> Since g++ already requires 1.5.3, it make no sense to bump to >anything older that 1.5.3, so let's bump to 1.5.3. Those packaging >systems and OSes that wanted to update by n

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

On 08/08/18 10:52 +0200, Sebastian Huber wrote: While building for Newlib, some configure checks must be hard coded. The aligned_alloc() is supported since 2015 in Newlib. libstdc++-v3 PR target/85904 * configure.ac): Define HAVE_ALIGNED_ALLOC if building for There's a stray c

Re: [PATCH 2/2] S/390: Remove TARGET_CPU_ZARCH

On 08/07/2018 10:13 AM, Ilya Leoshkevich wrote: > TARGET_CPU_ZARCH allowed to distinguish between g5/g6 and newer > machines. Since the former are now gone, we can assume that > TARGET_CPU_ZARCH is always true. As a side-effect, branch splitting > is now completely gone. Some parts of literal po

Re: [PATCH 1/2] S/390: Remove support for g5 and g6 machines

On 08/07/2018 10:13 AM, Ilya Leoshkevich wrote: > g5 and g6 were deprecated since gcc 6.1.0 (commit 3bd8520f). > > gcc/ChangeLog: > > 2018-08-02 Ilya Leoshkevich > > * common/config/s390/s390-common.c (processor_flags_table): > Remove flags. > * config.gcc: Remove with_arc

[Committed] S/390: Fix PR85295

Bootstrapped and regression tested on s390x with z900 and z13 default. gcc/ChangeLog: 2018-08-08 Andreas Krebbel PR target/85295 * config/s390/constraints.md ("NxHD0", "NxSD0"): New constraint definitions. * config/s390/s390.md ("movti"): Add more alternatives

[PATCH] line-map include-from representation

This patch changes the way line-maps hold the included-from information. Currently this is an index to another (earlier) line-map, and relies on the fact that #include cause the termination of the current map and emission of a new map. It's then possible to determine the location of the inclu

[PATCH] PR libstdc++/86597 directory_entry observers should clear error_code

PR libstdc++/86597 * include/bits/fs_dir.h (directory_entry::_M_file_type(error_code&)): Clear error_code when cached type is used. * testsuite/27_io/filesystem/directory_entry/86597.cc: New test. Committed to trunk, gcc-8 backport to follow. commit 5849d364a0f816

Re: [PATCH] PR libstdc++/86597 directory_entry observers should clear error_code

On 08/08/18 14:08 +0100, Jonathan Wakely wrote: PR libstdc++/86597 * include/bits/fs_dir.h (directory_entry::_M_file_type(error_code&)): Clear error_code when cached type is used. * testsuite/27_io/filesystem/directory_entry/86597.cc: New test. Committed to trunk,

Re: [PATCH] Improve libstdc++ docs w.r.t newer C++ standards

On 31/07/18 16:03 +0100, Jonathan Wakely wrote: Instead of repeating all the old headers for every new standard I've changed the docs to only list the new headers for each standard. * doc/xml/manual/test.xml: Improve documentation on writing tests for newer standards. * d

Re: [PATCH 2/2] S/390: Remove TARGET_CPU_ZARCH

Ilya Leoshkevich wrote: > TARGET_CPU_ZARCH allowed to distinguish between g5/g6 and newer > machines. Since the former are now gone, we can assume that > TARGET_CPU_ZARCH is always true. As a side-effect, branch splitting > is now completely gone. Some parts of literal pool splitting are > also

[PATCH] Relax SUPPORTS_STACK_ALIGNMENT with !crtl->stack_realign_tried

Assert for SUPPORTS_STACK_ALIGNMENT was added for dynamic stack alignment. At the time, arg_pointer_rtx would only be eliminated by either hard_frame_pointer_rtx or stack_pointer_rtx only when dynamic stack alignment is supported. With commit cd557ff63f388ad27c376d0a225e74d3594a6f9d Author: hjl

Re: dejagnu version update?

On 08/08/18 12:17, Bernhard Reutner-Fischer wrote: > On 7 August 2018 18:34:30 CEST, Segher Boessenkool > wrote: >> On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote: >>> Since g++ already requires 1.5.3, it make no sense to bump to >> anything older that 1.5.3, so let's bump to 1.5.3.

Re: [PATCH] Improve libstdc++ docs w.r.t newer C++ standards

On 08/08/18 14:29 +0100, Jonathan Wakely wrote: On 31/07/18 16:03 +0100, Jonathan Wakely wrote: Instead of repeating all the old headers for every new standard I've changed the docs to only list the new headers for each standard. * doc/xml/manual/test.xml: Improve documentation on writi

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

On 08/08/18 13:18, Jonathan Wakely wrote: On 08/08/18 10:52 +0200, Sebastian Huber wrote: While building for Newlib, some configure checks must be hard coded. The aligned_alloc() is supported since 2015 in Newlib. libstdc++-v3 PR target/85904 * configure.ac): Define HAVE_ALIGNED_ALLOC

Re: [RFC,PATCH] Introduce -msdata=explicit for powerpc

On Wed, Aug 08, 2018 at 12:38:54AM -0300, Alexandre Oliva wrote: > On Aug 7, 2018, Segher Boessenkool wrote: > > On Tue, Aug 07, 2018 at 02:18:59AM -0300, Alexandre Oliva wrote: > > >> I saw comments, docs and init code that suggested the possibility of > >> using r2/.sdata2 for small data, but

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

Jonathan Wakely wrote: > On 08/08/18 10:52 +0200, Sebastian Huber wrote: > >While building for Newlib, some configure checks must be hard coded. > >The aligned_alloc() is supported since 2015 in Newlib. > > > >libstdc++-v3 > > > > PR target/85904 > > * configure.ac): Define HAVE_ALIGNED_ALL

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

Now I'm puzzled. I don't see how an infinite would show up in the original expression. I don't know hyperbolic functions, so I just constructed a small test program, and the original vs. the substitution you mention are not at all similar. paul > On Aug 7, 2018, at 4:42 PM, Giuliano

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

On 08/08/18 15:57 +0200, Ulrich Weigand wrote: Jonathan Wakely wrote: On 08/08/18 10:52 +0200, Sebastian Huber wrote: >While building for Newlib, some configure checks must be hard coded. >The aligned_alloc() is supported since 2015 in Newlib. > >libstdc++-v3 > >PR target/85904 >* config

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

On 08/08/18 16:01, Jonathan Wakely wrote: On 08/08/18 15:57 +0200, Ulrich Weigand wrote: Jonathan Wakely wrote: On 08/08/18 10:52 +0200, Sebastian Huber wrote: >While building for Newlib, some configure checks must be hard coded. >The aligned_alloc() is supported since 2015 in Newlib. > >libstd

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

On 08/07/2018 06:52 AM, Cesar Philippidis wrote: > I attached an updated version of the CUDA driver patch, although I > haven't rebased it against your changes yet. It still needs to be tested > against CUDA 5.5 using the systems/Nvidia's cuda.h. But I wanted to give > you an update. > > Does thi

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

On 08/08/18 16:04 +0200, Sebastian Huber wrote: On 08/08/18 16:01, Jonathan Wakely wrote: On 08/08/18 15:57 +0200, Ulrich Weigand wrote: Jonathan Wakely wrote: On 08/08/18 10:52 +0200, Sebastian Huber wrote: While building for Newlib, some configure checks must be hard coded. The aligned_allo

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

Jonathan Wakely wrote: > Aha, so newlib was using memalign previously: > > @@ -53,20 +54,24 @@ aligned_alloc (std::size_t al, std::size_t sz) > #else > extern "C" void *memalign(std::size_t boundary, std::size_t size); > #endif > -#define aligned_alloc memalign Yes, exactly ... this commit in

Re: [PATCH v3] Add HXT Phecda core support

On Wed, Aug 08, 2018 at 05:38:09AM -0500, Hongbo Zhang wrote: > HXT semiconductor's CPU core Phecda, as a variant of Qualcomm qdf24xx, > reuses the same tuning structure and pipeline with it. Thank you. This patch is still OK. I've applied it on your behalf as r263404. Thanks, James > > 2018-0

[committed][libgomp, nvptx] Note that cuGetErrorString is in CUDA_VERSION >= 6000

Hi, Cuda driver api function cuGetErrorString is available in version 6.0 and higher. This patch: - removes a comment saying the declaration is not available in cuda.h 6.0 - fixes the presence test to use CUDA_VERSION < 6000 - moves the declaration to toplevel Build on x86_64 with nvptx accelera

[committed][libgomp, nvptx] Remove hard-coded const in nvptx_open_device

Hi, CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR is defined in cuda driver api version 6.0 and higher. Currently nvptx_open_device uses a hard-coded constant instead. This patch fixes that by: - defining CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR to the hardcoded constant at

[committed][libgomp, nvptx] Allow cuGetErrorString to be NULL

Hi, Cuda driver api function cuGetErrorString is available in version 6.0 and higher. Currently, when the driver that is used does not contain this function, the libgomp nvptx plugin will not build (PLUGIN_NVPTX_DYNAMIC == 0) or run (PLUGIN_NVPTX_DYNAMIC == 1). This patch fixes this problem by t

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

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 (std::size_t al, std::size_t sz) #else extern "C" void *memalign(std::size_t boundary, std::size_t size); #endif -#define aligned_alloc memal

[committed][libgomp, nvptx] Fall back to cuLinkAddData/cuLinkCreate if _v2 not found

On Tue, Aug 07, 2018 at 06:52:59AM -0700, Cesar Philippidis wrote: > I spotted an error > with the patch; I realized that the cuda.h that ships with libgomp > emulates version CUDA 8.0. That lead to problems using cuLinkAddData, > because that function gets remapped to cuLinkAddData_v2 in CUDA 6.5

Re: dejagnu version update?

Hi, On Wed, 8 Aug 2018, Bernhard Reutner-Fischer wrote: > How come? > > If one wants to develop on a distro that is notoriously outdated then > you have to obtain the missing pieces yourself. It's not about developing on an "notoriously outdated" distro, but about _testing_ on it. There are

Re: [PATCH] line-map include-from representation

On Wed, 2018-08-08 at 09:06 -0400, Nathan Sidwell wrote: > This patch changes the way line-maps hold the included-from > information. > Currently this is an index to another (earlier) line-map, and > relies > on the fact that #include cause the termination of the current map > and > emission o

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

On 08/08/18 15:33 +0100, 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 (std::size_t al, std::size_t sz) #else extern "C" void *memalign(std::size_t boundary, std::siz

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

On Wed, Aug 08, 2018 at 07:09:16AM -0700, Cesar Philippidis wrote: > On 08/07/2018 06:52 AM, Cesar Philippidis wrote: > > > I attached an updated version of the CUDA driver patch, although I > > haven't rebased it against your changes yet. It still needs to be tested > > against CUDA 5.5 using the

Re: [PATCH] line-map include-from representation

On 08/08/2018 10:46 AM, David Malcolm wrote: [...snip...] We don't seem to have much test coverage for this code. Sorry to be a pain, but could you please try adding a testcase of a diagnostic issued from within a couple of levels of nested includes, perhaps using /* { dg-options "-fdiagnosti

Re: [PATCH] line-map include-from representation

On Wed, 2018-08-08 at 11:28 -0400, Nathan Sidwell wrote: > On 08/08/2018 10:46 AM, David Malcolm wrote: > > > [...snip...] > > > > We don't seem to have much test coverage for this code. Sorry to > > be a > > pain, but could you please try adding a testcase of a diagnostic > > issued > > from wi

Re: [PATCH] line-map include-from representation

On Wed, 2018-08-08 at 11:36 -0400, David Malcolm wrote: > On Wed, 2018-08-08 at 11:28 -0400, Nathan Sidwell wrote: > > On 08/08/2018 10:46 AM, David Malcolm wrote: > > > > > [...snip...] > > > > > > We don't seem to have much test coverage for this code. Sorry to > > > be a > > > pain, but could

Re: [PATCH] Make strlen range computations more conservative

On 08/07/2018 11:46 AM, Richard Biener wrote: On August 7, 2018 6:31:36 PM GMT+02:00, Martin Sebor wrote: On 08/07/2018 09:33 AM, Bernd Edlinger wrote: On 08/07/18 17:02, Martin Sebor wrote: On 08/06/2018 11:45 PM, Richard Biener wrote: On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor

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

On 08/08/18 15:46 +0100, Jonathan Wakely wrote: On 08/08/18 15:33 +0100, 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 (std::size_t al, std::size_t sz) #else extern

Re: [PATCH] Make strlen range computations more conservative

On 08/08/18 17:51, Martin Sebor wrote: > On 08/07/2018 11:46 AM, Richard Biener wrote: >> >> Pointer types carry no information in GIMPLE. > > So what do you suggest as a solution? > > The strlen optimization can be decoupled from warnings and > disabled, and the aggressive loop optimization can

[PING] [PATCH] Create internally nul terminated string literals in fortan FE

Hi, I'd like to ping this patch: https://gcc.gnu.org/ml/fortran/2018-08/msg0.html I attach a new version, which contains only a minor white-space change from the previous version, in the function header of gfc_build_hollerith_string_const to contain "static tree" on one line instead of two.

Re: [PATCH][AArch64] Implement new intrinsics vabsd_s64 and vnegd_s64

On 01/08/18 18:35, James Greenhalgh wrote: On Wed, Aug 01, 2018 at 07:13:53AM -0500, Vlad Lazar wrote: On 31/07/18 22:48, James Greenhalgh wrote: On Fri, Jul 20, 2018 at 04:37:34AM -0500, Vlad Lazar wrote: Hi, The patch adds implementations for the NEON intrinsics vabsd_s64 and vnegd_s64. (ht

Ping for STRING_CST patches

Hi, I'd like to ping the following patches: [PATCH] Check the STRING_CSTs in varasm.c https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00361.html [PATCH] Fix not properly nul-terminated string constants in JIT https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html [PATCH] Handle overlength strin

Re: dejagnu version update?

On Wed, Aug 08, 2018 at 01:17:49PM +0200, Bernhard Reutner-Fischer wrote: > On 7 August 2018 18:34:30 CEST, Segher Boessenkool > wrote: > >On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote: > >> Since g++ already requires 1.5.3, it make no sense to bump to > >anything older that 1.5.3, s

Re: [PATCH] Make strlen range computations more conservative

On August 8, 2018 5:51:16 PM GMT+02:00, Martin Sebor wrote: >On 08/07/2018 11:46 AM, Richard Biener wrote: >> On August 7, 2018 6:31:36 PM GMT+02:00, Martin Sebor > wrote: >>> On 08/07/2018 09:33 AM, Bernd Edlinger wrote: On 08/07/18 17:02, Martin Sebor wrote: > On 08/06/2018 11:45 PM, Ri

Re: [PATCH] convert braced initializers to strings (PR 71625)

Hi Martin, sorry, I hope you forgive me, when I add a few comments to your patch. > + unsigned HOST_WIDE_INT nelts = CONSTRUCTOR_NELTS (ctor); > + tree eltype = TREE_TYPE (type); ... > + /* Bail if the CTOR has a block of more than 256 embedded nuls > +due to implicitly initialized

Re: [PATCH] line-map include-from representation

On 08/08/2018 11:36 AM, David Malcolm wrote: In r255786 I adjusted prune.exp to move the dg-regexp handling to before the pruning. Unfortunately, handle-multiline-outputs is still after the pruning. I guess we could try moving that to before as well, but I suspect it might break some things.

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/08/18 19:33, Bernd Edlinger wrote: > Hi Martin, > > sorry, I hope you forgive me, when I add a few comments to your patch. > >> +  unsigned HOST_WIDE_INT nelts = CONSTRUCTOR_NELTS (ctor); >> +  tree eltype = TREE_TYPE (type); > ... >> +  /* Bail if the CTOR has a block of more than 256

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

Sorry about that. In the e-mail text field I wrote sinh(tanh(x)) and cosh(tanh(x)) where it was supposed to be sinh(atanh(x)) and cosh(atanh(x)), thus I am talking about the inverse hyperbolic tangent function. The patch code and comments are still correct. On Wed, Aug 8, 2018 at 10:58 AM, Paul Ko

Re: [PATCH] convert braced initializers to strings (PR 71625)

Sorry, again, but could it be possible that this test case changed with your patch? $ cat w.c const char x[] = { }; int main() { __builtin_printf("%ld\n", sizeof(x)); return 0; } $ gcc w.c $ ./a.out 1 without your patch $ ./a.out 0 Jason/Joseph, is this meant to be accepted? It's rej

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

Thanks. Ok, so the expressions you gave are undefined for x==1, which says that substituting something that is also undefined for x==1 is permitted. You can argue from "undefined" rather than relying on IEEE features like NaN or infinite. paul > On Aug 8, 2018, at 2:57 PM, Giuliano A

m68k: handle more cases of TLS symbols with offset

This is a better fix for PR target/46179. There are more DImode insns that call adjust_operand during output processing. Instead of scanning the insns in the FINAL_PRESCAN_INSN hook, adjust them directly before they are output by print_operand or print_operand_address. Andreas. PR targe

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/08/18 21:50, Martin Sebor wrote: >> Sorry, again, but could it be possible that this test case changed >> with your patch? >> >> $ cat w.c >> const char  x[] = {  }; >> int main() >> { >>    __builtin_printf("%ld\n", sizeof(x)); >>    return 0; >> } >> $ gcc w.c >> $ ./a.out >> 1 >> >> withou

Re: Ping for STRING_CST patches

On Wed, 8 Aug 2018, Bernd Edlinger wrote: > [PATCH] Handle overlength strings in the C FE > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00142.html At least this one had at least one review comment . -- Joseph S. Myers jos...@codesourc

Re: [PATCH] convert braced initializers to strings (PR 71625)

On Wed, 8 Aug 2018, Martin Sebor wrote: > Jason/Joseph, is this meant to be accepted? It's rejected with > a hard error with -Wpedantic but I don't see any tests for it: > > warning: ISO C forbids empty initializer braces [-Wpedantic] >const char x[] = { }; > ^ > error: z

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/08/2018 05:08 AM, Jason Merrill wrote: On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote: On 08/07/2018 02:57 AM, Jason Merrill wrote: On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote: On 07/31/2018 07:38 AM, Jason Merrill wrote: On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/08/2018 02:48 PM, Joseph Myers wrote: On Wed, 8 Aug 2018, Martin Sebor wrote: Jason/Joseph, is this meant to be accepted? It's rejected with a hard error with -Wpedantic but I don't see any tests for it: warning: ISO C forbids empty initializer braces [-Wpedantic] const char x[] = {

Re: [PATCH] assume sprintf formatting of wide characters may fail (PR 86853)

On 08/04/2018 12:46 PM, Martin Sebor wrote: > The sprintf handling of wide characters neglects to consider > that calling the function may fail due to a conversion error > (when the wide character is invalid or not representable in > the current locale).  The handling also misinterprets > the POSIX

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

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 (std::size_t al, std::size_t sz)  #else  extern "C" void *memalign(std::size_t boundary, std::size_t

Re: [PATCH v2 01/10] Initial TI PRU GCC port

On Tuesday, 7 Aug 2018, 16:56:16 EEST Sandra Loosemore wrote: > > * doc/extend.texi: Document PRU pragmas. > > * doc/invoke.texi: Document PRU-specific options. > > * doc/md.texi: Document PRU asm constraints. > > I have a few nit-picky comments about the documentation parts. Thank you for the re

Re: [RFC,PATCH] Introduce -msdata=explicit for powerpc

On Aug 7, 2018, Segher Boessenkool wrote: > The approach looks like it should work, but it does not seem all that > convenient to me. And there's more, it's actually redundant. -msdata -G 0 is equivalent to the proposed -msdata=explicit. Patch withdrawn. Sorry about the noise. -- Alexandre O

Re: [PATCH] Make strlen range computations more conservative

On 07/24/2018 05:18 PM, Bernd Edlinger wrote: > On 07/24/18 23:46, Jeff Law wrote: >> On 07/24/2018 01:59 AM, Bernd Edlinger wrote: >>> Hi! >>> >>> This patch makes strlen range computations more conservative. >>> >>> Firstly if there is a visible type cast from type A to B before passing >>> then

Re: [PATCH] Make strlen range computations more conservative

On 08/02/2018 09:42 AM, Martin Sebor wrote: > The warning bits are definitely not okay by me.  The purpose > of the warnings (-W{format,sprintf}-{overflow,truncation} is > to detect buffer overflows.  When a warning doesn't have access > to string length information for dynamically created strings

Re: [RFC][PATCH][mid-end] Optimize immediate choice in comparisons.

On 08/07/2018 02:11 PM, Richard Sandiford wrote: > Hi Vlad, > > Thanks for the patch. > > Vlad Lazar writes: >> Hi. >> >> This patch optimises the choice of immediates in integer comparisons. Integer >> comparisons allow for different choices (e.g. a > b is equivalent to a >= >> b+1) >> and the

Re: [RFC,PATCH] Introduce -msdata=explicit for powerpc

On Aug 8, 2018, Segher Boessenkool wrote: > Then you get sdata2 used (via srodata in generic code), and it is accessed > via GPR2 (via the sda21 reloc and linker magic). It is hard to trace down :-) Aah, it didn't occur to me that the r2 uses could be introduced by the linker. I was cutting c

Re: [PATCH] Make strlen range computations more conservative

On August 9, 2018 7:26:19 AM GMT+02:00, Jeff Law wrote: >On 07/24/2018 05:18 PM, Bernd Edlinger wrote: >> On 07/24/18 23:46, Jeff Law wrote: >>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote: Hi! This patch makes strlen range computations more conservative. Firstly if there