Re: [Patch, avr, PR85624] - Fix ICE when initializing 128-byte aligned array

Jeff Law writes: > On 08/06/2018 04:53 AM, Senthil Kumar Selvaraj wrote: >> Ping! >> >> Regards >> Senthil >> >> Senthil Kumar Selvaraj writes: >> >>> Hi, >>> >>> The below patch fixes an ICE for the avr target when the setmemhi >>> expander is involved. >>> >>> The setmemhi expander generate

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

On 08/01/2018 12:18 PM, Tom de Vries wrote: > I think we need to add and handle: > ... > CUDA_ONE_CALL_MAYBE_NULL (cuOccupancyMaxPotentialBlockSize) > ... > I realized that the patch I posted introducing CUDA_ONE_CALL_MAYBE_NULL was incomplete, and needed to use the weak attribute in case of l

Re: [PATCH] Introduce instance discriminators

On Jul 30, 2018, Alexandre Oliva wrote: >> for gcc/ada >> * trans.c: Include debug.h. >> (file_map): New static variable. >> (gigi): Set it. Create decl_to_instance_map when needed. >> (Subprogram_Body_to_gnu): Pass gnu_subprog_decl to... >> (Sloc_to_locus): ... this. Add decl parm, map it to

Re: [PATCH] Make strlen range computations more conservative

On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote: >On 08/06/2018 11:40 AM, Jeff Law wrote: >> On 08/06/2018 11:15 AM, Martin Sebor wrote: > These examples do not aim to be valid C, they just point out >limitations > of the middle-end design, and a good deal of the problems are du

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

This option allows users to manually select what goes in the limited small data range, and still get smaller and faster small data access sequences for the selected data. We've considered adding a new attribute, say "sdata", to let the compiler pick the sdata/sbss section name itself, but that's

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 11:40 AM, Jeff Law wrote: On 08/06/2018 11:15 AM, Martin Sebor wrote: These examples do not aim to be valid C, they just point out limitations of the middle-end design, and a good deal of the problems are due to trying to do things that are not safe within the boundaries given by t

Re: [PATCH] Make strlen range computations more conservative

On 07/26/2018 02:55 AM, Richard Biener wrote: On Wed, 25 Jul 2018, Martin Sebor wrote: BUT - for the string_constant and c_strlen functions we are, in all cases we return something interesting, able to look at an initializer which then determines that type. Hopefully. I think the strlen() fold

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

On 08/06/2018 11:04 AM, Joseph Myers wrote: On Mon, 6 Aug 2018, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01884.html I'd expect testcases with signed char and unsigned char as well, if those work for C, including tests for signed char where some of the initialize

Re: [PATCH] Add fix-it hint for missing return statement in assignment operators (PR c++/85523)

On Fri, Aug 3, 2018 at 11:41 AM, David Malcolm wrote: > On Tue, 2018-05-01 at 07:18 -0400, Nathan Sidwell wrote: >> On 04/30/2018 08:29 PM, David Malcolm wrote: >> > Following on from the thread on the "gcc" list here: >> > >> >https://gcc.gnu.org/ml/gcc/2018-04/msg00172.html >> > >> > here's

Re: [PATCH] Make strlen range computations more conservative

But as I said, far more essential than the optimization is the ability to detect these invalid access (both reads and writes), such as in: The essential thing is to not introduce latent wrong code issues because you exploit C language constraints that are not preserved by GIMPLE transforms bec

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 10:32 AM, Martin Sebor wrote: > On 08/06/2018 09:12 AM, Jeff Law wrote: >> On 08/04/2018 03:56 PM, Martin Sebor wrote: >>> On 08/03/2018 01:00 AM, 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,

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 11:15 AM, Martin Sebor wrote: >>> These examples do not aim to be valid C, they just point out limitations >>> of the middle-end design, and a good deal of the problems are due >>> to trying to do things that are not safe within the boundaries given >>> by the middle-end design. >> I

[committed][libgomp, nvptx] Handle CUDA_ONE_CALL_MAYBE_NULL

Hi, This patch adds handling of functions that may not be present in the cuda driver. Such a function can be declared using CUDA_ONE_CALL_MAYBE_NULL in cuda-lib.def, it can be called with the usual convenience macros, but before calling its presence needs to be tested using new macro CUDA_CALL_EX

[committed][libgomp, nvptx] Minimize lifetime of CUDA_ONE_CALL defines

Hi, This patch makes sure that the lifetimes of the CUDA_ONE_CALL macro (which is defined twice in plugin-nvptx.c) are minimized, to make it obvious that the definitions are used only in the lib-cuda.def include. Build on x86_64 with nvptx accelerator and reg-tested libgomp. Committed to trunk.

Re: [Patch][Aarch64] Implement Aarch64 SIMD ABI and aarch64_vector_pcs attribute

Thanks for the feedback Kyrill.  I have updated my patch and attached the new version to this email.  The one change I did not make was to remove load_pair_dw_tftf and store_pair_dw_tftf and use the load_pair and vec_store_pair patterns.  Having to add two new iterators to remove two instructions d

Re: [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

On 2018-08-03 5:06 AM, Richard Earnshaw (lists) wrote: I don't think there's a suitable barrier.  The sync instruction seems like overkill. So, I'm going to install attached change after testing is complete. It's your call as port maintainers. I committed the attached change after testing on

Use EVRP within DOM to discover more constants

Now that we have EVRP analysis available within DOM, we can query it to see if an SSA_NAME has a singleton constant range. If so, we can substitute the constant for the SSA_NAME. This is most helpful in assignments (for GIMPLE_COND we'd simplify it later anyway)... Consider this: _930 = _631

Re: [C++ PATCH] PR c++/79133

On 8 July 2018 at 02:08, Ville Voutilainen wrote: > On 8 July 2018 at 01:54, Paolo Carlini wrote: >>> That would make this more consistent with such a shadow warning, but I >>> don't want >>> to use the shadowing wording (which would be easy to do; just set >>> 'shadowed' and do >>> a 'goto infor

Re: [PATCH][Middle-end] disable strcmp/strncmp inlining with O2 below and Os

thanks for reporting this issue. I will take a look. Qing > On Jul 30, 2018, at 8:45 AM, Christophe Lyon > wrote: > > On Wed, 25 Jul 2018 at 19:08, Qing Zhao > wrote: >> >> Hi, >> >> As Wilco suggested, the new added strcmp/strncmp inlining should be only >> en

Re: [PATCH] [Ada] Make middle-end string literals NUL terminated

Hi Bernd, Things are moving fast so I'll answer your messages incrementally :-) > On 3 Aug 2018, at 20:37, Bernd Edlinger wrote: [...] > Oh, how interesting. > > My patch only intends to add a dummy byte that is stripped again > in the assembly. The purpose is to make it trivial to find out if

Re: [PATCH] Make strlen range computations more conservative

On August 6, 2018 6:32:41 PM GMT+02:00, Martin Sebor wrote: >On 08/06/2018 09:12 AM, Jeff Law wrote: >> On 08/04/2018 03:56 PM, Martin Sebor wrote: >>> On 08/03/2018 01:00 AM, Jeff Law wrote: On 07/24/2018 05:18 PM, Bernd Edlinger wrote: > On 07/24/18 23:46, Jeff Law wrote: >> On 07/2

[SVE ACLE] Tidy up function names in testcases

While looking through the SVE ACLE tests again, I realised the naming of the test functions was a bit inconsistent. The patch below adopts the following scheme: test_[mxz]: a test that isn't focusing on the register allocation. More specifically, this means that there are no other func

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 11:15 AM, Martin Sebor wrote: >>> These examples do not aim to be valid C, they just point out limitations >>> of the middle-end design, and a good deal of the problems are due >>> to trying to do things that are not safe within the boundaries given >>> by the middle-end design. >> I

Re: [PATCH] Make strlen range computations more conservative

These examples do not aim to be valid C, they just point out limitations of the middle-end design, and a good deal of the problems are due to trying to do things that are not safe within the boundaries given by the middle-end design. I really think this is important -- and as such I think we need

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

On Mon, 6 Aug 2018, Martin Sebor wrote: > Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01884.html I'd expect testcases with signed char and unsigned char as well, if those work for C, including tests for signed char where some of the initializers are negative. (Tests that actual array c

[PATCH] Line map table allocation

Here's a line-map patch to make the new_linemap logic simpler. On the modules branch I need to allocate blocks of linemaps, and found the current allocation scheme a little confusing to adjust. This'll make that subsequent change simpler. While there, I set the default allocator (xmalloc) in

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

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01884.html On 07/30/2018 05:51 PM, Martin Sebor wrote: The middle-end contains code to determine the lengths of constant character arrays initialized by string literals. The code is used in a number of optimizations and warnings. However, the

Re: [PATCH][GCC][AARCH64] Use STLUR for atomic_store

On 03/08/18 13:18, Sudakshina Das wrote: Thank you for doing this. I am not a maintainer but I have a few nits on this patch: Thanks for the suggestions Sudi: nits have been removed, and new patch attached. Have also removed the reference to "stlur" in names as Richard suggested. New change

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 09:12 AM, Jeff Law wrote: On 08/04/2018 03:56 PM, Martin Sebor wrote: On 08/03/2018 01:00 AM, 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 comput

[PATCH][AAarch64][v3] Add support for TARGET_COMPUTE_FRAME_LAYOUT

Hi, The patch adds support for the TARGET_COMPUTE_FRAME_LAYOUT hook on AArch64 and removes unneeded frame layout recalculation. The removed aarch64_layout_frame calls are unnecessary because the functions in which they appear will be called during or after the reload pass in which the TARGET_C

Re: [testsuite] Fix gcc.dg/vect/no-section-anchors-vect-69.c on SPARC etc. (PR tree-optimization/80925)

On 08/06/2018 02:31 AM, Rainer Orth wrote: > Since this patch > > 2017-07-31 Steve Ellcey > > PR tree-optimization/80925 > * gcc.dg/vect/no-section-anchors-vect-69.c: Add > --param vect-max-peeling-for-alignment=0 option. > Remove unaligned access and peeling ch

Re: [PATCH 02/11] Arm - add speculation_barrier pattern

On 06/08/18 15:00, Christophe Lyon wrote: > On Fri, 27 Jul 2018 at 11:38, Richard Earnshaw > wrote: >> >> >> This patch defines a speculation barrier for AArch32. >> >> * config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER. >> * config/arm/arm.md (speculation_barrier)

Re: [PATCH] Diagnostic included-from loop

On Mon, 2018-08-06 at 11:32 -0400, Nathan Sidwell wrote: > We currently emit the 'included from' information in a peeled-once > loop. > This patch rerolls the loop. It'll make some future changes > simpler, > and we're not at all worried about speed here -- it's a diagnostic! > > In the long

Re: [Patch, avr, PR85624] - Fix ICE when initializing 128-byte aligned array

On 08/06/2018 04:53 AM, Senthil Kumar Selvaraj wrote: > Ping! > > Regards > Senthil > > Senthil Kumar Selvaraj writes: > >> Hi, >> >> The below patch fixes an ICE for the avr target when the setmemhi >> expander is involved. >> >> The setmemhi expander generated RTL ends up as an unrecognized in

Re: [PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

How about replacing clock_gettime with something else? It's not needed for the particular test. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: [PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

On Mon, Aug 6, 2018 at 5:44 PM, Jeff Law wrote: > On 08/06/2018 09:33 AM, Uros Bizjak wrote: >> On Mon, Aug 6, 2018 at 5:23 PM, Jeff Law wrote: >>> On 08/06/2018 09:10 AM, Uros Bizjak wrote: 2018-08-06 Uros Bizjak * g++.dg/torture/pr86763.C (dg-additional-options): Add -lrt.

Re: [PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

On 08/06/2018 09:33 AM, Uros Bizjak wrote: > On Mon, Aug 6, 2018 at 5:23 PM, Jeff Law wrote: >> On 08/06/2018 09:10 AM, Uros Bizjak wrote: >>> 2018-08-06 Uros Bizjak >>> >>> * g++.dg/torture/pr86763.C (dg-additional-options): Add -lrt. >>> >>> Tested on CentOS 5.10 and Fedora 28. >>> >>> OK

Re: C++ PATCH to fix infinite constexpr evaluation (PR c++/86767)

On 08/06/2018 11:35 AM, Marek Polacek wrote: This PR points out infinite looping in constexpr evaluation for e.g. Bootstrapped/regtested on x86_64-linux, ok for trunk/8.3? 2018-08-06 Marek Polacek PR c++/86767 * constexpr.c (cxx_eval_statement_list): Handle continue. ok.

Re: [PATCH] Make strlen range computations more conservative

On 08/02/2018 10:19 PM, Martin Sebor wrote: > On 08/01/2018 12:55 AM, Bernd Edlinger wrote: >>> Certainly not every "strlen" has these semantics.  For example, >>> this open-coded one doesn't: >>> >>>    int len = 0; >>>    for (int i = 0; s.a[i]; ++i) >>> ++len; >>> >>> It computes 2 (with no

Re: [PATCH] Make strlen range computations more conservative

On 08/05/2018 11:27 AM, Richard Biener wrote: On August 4, 2018 10:52:02 PM GMT+02:00, Martin Sebor wrote: On 08/03/2018 01:43 AM, Jakub Jelinek wrote: On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote: If I call this with foo (2, 1), do you still claim it is not valid C? String

C++ PATCH to fix infinite constexpr evaluation (PR c++/86767)

This PR points out infinite looping in constexpr evaluation for e.g. for (...) { continue; while (1); } where we tried to evaluate the while despite the continue. The problem started with r240591 and its cxx_eval_statement_list changes. This patch fixes it by handling cont

Re: [PATCH] Make strlen range computations more conservative

On 07/27/2018 12:48 AM, Bernd Edlinger wrote: > I have one more example similar to PR86259, that resembles IMHO real world > code: > > Consider the following: > > > int fun (char *p) > { > char buf[16]; > > assert(strlen(p) < 4); //here: security relevant check > > sprintf(buf, "echo %s

Re: [PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

On Mon, Aug 6, 2018 at 5:23 PM, Jeff Law wrote: > On 08/06/2018 09:10 AM, Uros Bizjak wrote: >> 2018-08-06 Uros Bizjak >> >> * g++.dg/torture/pr86763.C (dg-additional-options): Add -lrt. >> >> Tested on CentOS 5.10 and Fedora 28. >> >> OK for mainline? > But what about systems without librt

[PATCH] Diagnostic included-from loop

We currently emit the 'included from' information in a peeled-once loop. This patch rerolls the loop. It'll make some future changes simpler, and we're not at all worried about speed here -- it's a diagnostic! In the long term, the include-at path will include modules (imported at). Having

Re: dejagnu version update?

On Aug 4, 2018, at 9:32 AM, Bernhard Reutner-Fischer wrote: > On Tue, 16 May 2017 at 21:08, Mike Stump wrote: >> >> On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote: >>> The change I care about in 1.5.3 >> >> So, we haven't talked much about the version people want most. If we >> update,

Re: [PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

On 08/06/2018 09:10 AM, Uros Bizjak wrote: > 2018-08-06 Uros Bizjak > > * g++.dg/torture/pr86763.C (dg-additional-options): Add -lrt. > > Tested on CentOS 5.10 and Fedora 28. > > OK for mainline? But what about systems without librt? I'm thinking primarily of the embedded *-elf targets.

Re: [PATCH] Fix memory leak in selftest::test_expansion_to_rtl

On 08/02/2018 07:14 PM, David Malcolm wrote: > "make selftest-valgrind" shows: > > 187 bytes in 1 blocks are definitely lost in loss record 567 of 669 > at 0x4A081D4: calloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > by 0x1F08260: xcalloc (xmalloc.c:162) > by 0xB24

Re: [PATCH] Make strlen range computations more conservative

On 08/04/2018 03:56 PM, Martin Sebor wrote: > On 08/03/2018 01:00 AM, 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 cons

[PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

2018-08-06 Uros Bizjak * g++.dg/torture/pr86763.C (dg-additional-options): Add -lrt. Tested on CentOS 5.10 and Fedora 28. OK for mainline? Uros. Index: g++.dg/torture/pr86763.C === --- g++.dg/torture/pr86763.C(revision 2

[Committed] S/390: Don't unroll memory blk op loops

From: Andreas Krebbel gcc/ChangeLog: 2018-08-06 Andreas Krebbel * config/s390/s390.c (s390_loop_unroll_adjust): Prevent small loops with memory block operations from getting unrolled. gcc/testsuite/ChangeLog: 2018-08-06 Andreas Krebbel * gcc.target/s390/nomemloo

Re: [PATCH] Make strlen range computations more conservative

On 08/03/2018 01:48 AM, Jakub Jelinek wrote: > On Fri, Aug 03, 2018 at 01:19:14AM -0600, Jeff Law wrote: >> I'm leaning towards a similar conclusion, namely that we can only rely >> on type information for the pointer that actually gets passed to strlen, >> which 99.9% of the time is (char *), pote

Re: [PATCH] Optimize logarithm addition and subtraction

On 08/05/2018 12:35 PM, Marc Glisse wrote: > On Sun, 5 Aug 2018, Bernd Edlinger wrote: > >>> merging log a + log b => log a*b and >> >> Maybe a*b could overflow, while adding the logarithms would not? > > Well, that's a discussion that happens every time a new transformation > is added to -funsaf

[spu, commit] Define TARGET_HAVE_SPECULATION_SAFE_VALUE

Hello, the SPU processor is not affected by speculation, so this macro can safely be defined as speculation_safe_value_not_needed. Committed to mainline. Bye, Ulrich gcc/ChangeLog: PR target/86807 * config/spu/spu.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to specu

Re: dejagnu version update?

On Sat, 4 Aug 2018 at 17:32, Bernhard Reutner-Fischer wrote: > debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough > to contain both fixes. Commercial distros seem to ship fixed versions, > too. The CentOS 7.4.1708 version on gcc112 doesn't seem to be fixed.

Re: [PATCH, testsuite]: Fix PR 86153, test case g++.dg/pr83239.C fails

On Wed, 1 Aug 2018 at 12:34, Uros Bizjak wrote: > > Hello! > > The testcase fails with: > > FAIL: g++.dg/pr83239.C -std=gnu++11 scan-tree-dump-not optimized > "_ZNSt6vectorIiSaIiEE17_M_default_appendEm" > FAIL: g++.dg/pr83239.C -std=gnu++14 scan-tree-dump-not optimized > "_ZNSt6vectorIiSaIiEE1

Re: [PATCH 02/11] Arm - add speculation_barrier pattern

On Fri, 27 Jul 2018 at 11:38, Richard Earnshaw wrote: > > > This patch defines a speculation barrier for AArch32. > > * config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER. > * config/arm/arm.md (speculation_barrier): New expand. > (speculation_barrier_insn): N

Re: [C++ PATCH] Implement P0595R1 - so far as __builtin_is_constant_evaluated rather than std::is_constant_evaluated magic builtin

On Wed, Aug 1, 2018 at 7:07 PM, Jakub Jelinek wrote: > On Wed, Aug 01, 2018 at 12:35:09AM +1000, Jason Merrill wrote: >> On Mon, Jul 23, 2018 at 8:50 PM, Richard Biener >> wrote: >> > On Mon, Jul 23, 2018 at 12:28 PM Jakub Jelinek wrote: >> >> >> >> On Mon, Jul 23, 2018 at 12:17:42PM +0200, Rich

Re: [committed] Fix reload assert due to CLOBBER_HIGH support

On 08/06/2018 07:48 AM, Jeff Law wrote: > > > forget_old_reloads_1 can be called with NULL_RTX for SETTER which causes > a segfault in the assert that SETTER is not a CLOBBER_HIGH expression > (see the call from within reload_as_needed) > > > forget_old_reloads_1 (XEXP (in_reg, 0), NULL_RTX, N

[committed] Fix reload assert due to CLOBBER_HIGH support

forget_old_reloads_1 can be called with NULL_RTX for SETTER which causes a segfault in the assert that SETTER is not a CLOBBER_HIGH expression (see the call from within reload_as_needed) forget_old_reloads_1 (XEXP (in_reg, 0), NULL_RTX, NULL); Clearly this only happens on reload targets. V

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

Alan Hayward writes: > Add the clobber high expressions to tls_desc for aarch64. > It also adds three tests. > > In addition I also tested by taking the gcc torture test suite and making > all global variables __thread. Then emended the suite to compile with -fpic, > save the .s file and only for

Re: [PATCH v2 1/4] vxworks: add target/h/wrn/coreip to the set of system include paths

> On 6 Aug 2018, at 14:12, Olivier Hainque wrote: >> * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to >> default search path. > > Ok, thanks. With a nit on the ChangeLog formatting: * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to default s

Re: [PATCH v2 1/4] vxworks: add target/h/wrn/coreip to the set of system include paths

Hi Rasmus, > On 28 Jun 2018, at 10:43, Rasmus Villemoes wrote: > > 2018-06-04 Rasmus Villemoes > >* config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to > default search path. Ok, thanks. Olivier

Re: [PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics

On Wed, Jul 18, 2018 at 6:10 PM, Janne Blomqvist wrote: > On Wed, Jul 18, 2018 at 4:26 PM, Thomas König wrote: > >> Hi Kyrlll, >> >> > Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov < >> kyrylo.tkac...@foss.arm.com>: >> > >> > Thomas, Janne, would this relaxation of NaN handling be acceptable >>

Re: [PATCH] Make strlen range computations more conservative

On 08/05/18 17:58, Jeff Law wrote: > On 08/05/2018 12:08 AM, Bernd Edlinger wrote: >> I see this from a software engineering POV. >> >> If we have code like this: >> >> void test (const char *x) >> { >> assert (strlen (x) < 10); >> } >> >> One would usually expect the program to abort (or at le

Re: Async I/O patch with compilation fix

On Sat, 4 Aug 2018 at 00:42, Thomas König wrote: > > Hi Cristophe, > > this is seriously weird - there is not even an I/O statement in that test > case. > > One question: Is this real hardware or an emulator? I'm using QEMU > Also, Could you try a few things? > > Run the test case manually. Do y

Re: [Patch, avr, PR85624] - Fix ICE when initializing 128-byte aligned array

Ping! Regards Senthil Senthil Kumar Selvaraj writes: > Hi, > > The below patch fixes an ICE for the avr target when the setmemhi > expander is involved. > > The setmemhi expander generated RTL ends up as an unrecognized insn > if the alignment of the destination exceeds that of a QI > mode const

Re: [PATCH] AMD perf PMU events for AMD Family 17h.

Oup, I have gcc-patches as default mailing list for git format-patch. Please ignore this email thread. Martin

[PATCH] AMD perf PMU events for AMD Family 17h.

Hello. Following patch adds PMC events for AMD Family 17 CPUs as defined in [1]. It covers events described in section: 2.1.13. Regex pattern in mapfile.csv covers all CPUs of the family. Thanks, Martin [1] https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf Signed-off-by:

[testsuite] Fix gcc.dg/vect/no-section-anchors-vect-69.c on SPARC etc. (PR tree-optimization/80925)

Since this patch 2017-07-31 Steve Ellcey PR tree-optimization/80925 * gcc.dg/vect/no-section-anchors-vect-69.c: Add --param vect-max-peeling-for-alignment=0 option. Remove unaligned access and peeling checks. * gcc.dg/vect/section-anchors-vect-69.c: Ditt

Re: [patch] improve internals documentation for nested function descriptors

> Here's another attempt at documenting what's there now, this time > avoiding using the ambiguous term "custom" at all in the text. I've > also tried to address the other comments. Is this any better? Yes, it's fine with me, thanks. -- Eric Botcazou

[PATCH,committed] [MAINTAINERS] Update email address

Hi, Updating my email address in the MAINTAINERS file. Thanks, Naveen Index: ChangeLog === --- ChangeLog (revision 263324) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2018-08-06 Naveen H.S + + * MAINTAINERS: Update my email addr