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

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

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

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

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 >> >>

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] 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 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:

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] 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 

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 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: [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

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

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

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

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 >*

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. >

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

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

[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. ---

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

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

[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

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

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

[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

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,

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

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 > >

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

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

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

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

[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

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

[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

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

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,

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

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.

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

[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: 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,

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: [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

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

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

[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:

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

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

[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

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

[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: [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 >

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

[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

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. *

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] 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: [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