Re: [PATCH] Use --push-state --as-needed and --pop-state instead of --as-needed and --no-as-needed for libgcc

On 11.04.2018 20:55, Jakub Jelinek wrote: > On Wed, Apr 11, 2018 at 06:07:17PM +0200, Matthias Klose wrote: >> On 11.04.2018 12:31, Jakub Jelinek wrote: >>> Hi! >>> >>> As discussed, using --as-needed and --no-as-needed is dangerous, because >>> it results in --no-as-needed even for libraries

Re: Patch ping^3

On Thu, 12 Apr 2018, Jakub Jelinek wrote: > Hi! > > I'd like to ping the > > http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html > - PR83157 - improve debug info for x86 setcc peepholes > > patch. Thanks. OK for stage1 and backporting after it soaked there for a while. I'm too

Patch ping^3

Hi! I'd like to ping the http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html - PR83157 - improve debug info for x86 setcc peepholes patch. Thanks. Jakub

Re: [PATCH] Fix copyprop_hardreg_forward_1 (PR rtl-optimization/85342)

On Wed, 11 Apr 2018, Jakub Jelinek wrote: > Hi! > > When switching regcprop.c to use validate_* and apply_change_group, > I have added code to restore recog_data.operands[i] if they have been > replaced after apply_change_group failure. That is bogus though, when > apply_change_group fails,

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

On Wed, Apr 11, 2018 at 09:47:22PM +0200, Thomas Koenig wrote: > Am 11.04.2018 um 20:33 schrieb Jakub Jelinek: > > > > I have attached updated patch which moves the test case to > > > gfortran.dg/gomp (where it actually passes). > > > > How could it pass there? dg-do run tests don't belong into

Re: [PATCH] Invoke maybe_warn_nonstring_arg for strcpy/stpcpy builtins.

On 04/11/2018 11:20 PM, Martin Sebor wrote: > On 04/11/2018 06:47 AM, Andreas Krebbel wrote: >> On 04/11/2018 10:02 AM, Jakub Jelinek wrote: >>> On Wed, Apr 11, 2018 at 09:48:05AM +0200, Andreas Krebbel wrote: c-c++-common/attr-nonstring-3.c fails on IBM Z. The reason appears to be that

Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955

On Wed, Apr 11, 2018 at 9:30 PM, Cesar Philippidis wrote: > On 04/09/2018 04:31 AM, Richard Biener wrote: >> On Fri, 6 Apr 2018, Jakub Jelinek wrote: >> >>> On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote: 2018-04-06 Cesar Philippidis

[nvptx, PR85296] Fix handling of extern var with flexible array member

Hi, for the recently added test-case pr85244-1.c, we run into the following failure with the standalone nvptx toolchain: ... spawn nvptx-none-run ./pr85244-1.exe error : Size doesn't match for 'val' in 'input file 2 at offset 3047', first specified in 'input file 1 at offset 1805'

Re: [PATCH] Fix non-AVX512VL handling of lo extraction from AVX512F xmm16+ (PR target/85328)

Hello Jakub! > On 11 Apr 2018, at 16:27, Jakub Jelinek wrote: > > Hi! > > In lots of patterns we assume that we never see xmm16+ hard registers > with 128-bit and 256-bit vector modes when not -mavx512vl, because > HARD_REGNO_MODE_OK refuses those. > Unfortunately, as this

Re: [PATCH] Disable -gsplit-dwarf for all LTO debug

On Thu, Apr 12, 2018 at 01:35:46PM +0200, Richard Biener wrote: > > The following disables split-dwarf for the LTO part of the early debug > (keeping it for the fat part) and makes sure the driver doesn't > see -gsplit-dwarf in effect. > > That works for all but the compile stage and slim

Re: [PATCH] Don't mark IFUNC resolver as only called directly

On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote: > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as > only called directly. > > OK for trunk? > > > H.J. > --- > gcc/ > > PR target/85345 > * cgraph.h: Include stringpool.h" and

[Committed] IBM Z: Spectre: Prevent thunk cfi to be emitted with -fno-dwarf2-cfi-asm

The CFI magic we emit as part of the indirect branch thunks in order to have somewhat sane unwind information must not be emitted with -fno-dwarf2-cfi-asm. Committed to mainline, gcc-7-branch, and gcc-6-branch. gcc/ChangeLog: 2018-04-12 Andreas Krebbel *

[PATCH] Fix PR85371

This fixes crashes on Darwin with -flto -g because we pass the wrong (NULL) debug_line_section in case dw_val_class_lineptr: dw2_asm_output_offset (DWARF_OFFSET_SIZE, AT_lbl (a), debug_line_section, "%s", name); break; which is

[PATCH] Don't mark IFUNC resolver as only called directly

Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as only called directly. OK for trunk? H.J. --- gcc/ PR target/85345 * cgraph.h: Include stringpool.h" and "attribs.h". (cgraph_node::only_called_directly_or_aliased_p): Return false for IFUNC

Re: [PATCH] Disable -gsplit-dwarf for all LTO debug

On Thu, 12 Apr 2018, Jakub Jelinek wrote: > On Thu, Apr 12, 2018 at 01:35:46PM +0200, Richard Biener wrote: > > > > The following disables split-dwarf for the LTO part of the early debug > > (keeping it for the fat part) and makes sure the driver doesn't > > see -gsplit-dwarf in effect. > > > >

Re: [PATCH] Don't mark IFUNC resolver as only called directly

> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote: > > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as > > only called directly. > > > > OK for trunk? > > > > > > H.J. > > --- > > gcc/ > > > > PR target/85345 > > * cgraph.h: Include

Re: [PATCH] Fix non-AVX512VL handling of lo extraction from AVX512F xmm16+ (PR target/85328)

> On 12 Apr 2018, at 13:53, Jakub Jelinek wrote: > > On Thu, Apr 12, 2018 at 01:46:40PM +0300, Kirill Yukhin wrote: >> >> Hello Jakub! >> >>> On 11 Apr 2018, at 16:27, Jakub Jelinek wrote: >>> In lots of patterns we assume that we never see xmm16+ hard

Re: [PATCH] Ada: Fix s-oscons.ads generation

On 07/03/18 14:15, Arnaud Charlet wrote: The $(GNATLIBCFLAGS) are already included in $(GNATLIBCFLAGS_FOR_C). We must call the C compiler with the right machine flags. So, add $(GNATLIBCFLAGS_FOR_C) to $(OSCONS_EXTRACT). For example, on a bi-arch compiler supporting 32-bit and 64-bit

[PATCH] Disable -gsplit-dwarf for all LTO debug

The following disables split-dwarf for the LTO part of the early debug (keeping it for the fat part) and makes sure the driver doesn't see -gsplit-dwarf in effect. That works for all but the compile stage and slim objects (the default) which then ends up generating an empty .dwo file. I'm not

Re: Patch ping^3

On Thu, Apr 12, 2018 at 10:41:22AM +0200, Richard Biener wrote: > On Thu, 12 Apr 2018, Jakub Jelinek wrote: > > I'd like to ping the > > > > http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html > > - PR83157 - improve debug info for x86 setcc peepholes > > > > patch. Thanks. > > OK for

[og7, nvptx, committed] Fix propagation of branch cond in vw-neutered code

Hi, Currently, when we enable -mlong-vector-in-workers in gemm.f90, we get: ... { .reg.u32%tidy; .reg.u64%t_bcast; .reg.u64%y64; mov.u32 %tidy, %tid.y; cvt.u64.u32 %y64, %tidy; add.u64 %y64, %y64, 1; cvta.shared.u64

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote: > Not sure if I missed some important part of the discussion but > for the testcase we want to preserve the tailcall, right? So > it would be enough to set avoid_libcall to > endp != 0 && CALL_EXPR_TAILCALL (exp) (and thus also

Fix PR target/85238

This makes -g work again in LTO mode for Windows targets by kludging around the missing support for copying PE-COFF debug sections in the simple object module of libiberty, thus effectively disabling early debug in LTO mode. The patch also contains a fixlet for a related oversight in the LTO

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, 12 Apr 2018, Jakub Jelinek wrote: > On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote: > > Not sure if I missed some important part of the discussion but > > for the testcase we want to preserve the tailcall, right? So > > it would be enough to set avoid_libcall to > > endp

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote: > Well, but that wouldn't be a fix for a regression and IMHO there's > no reason for a really lame mempcpy. If targets disgree well, It is a regression as well, in the past we've emitted mempcpy when user wrote mempcpy, now we

Re: [PATCH] sel-sched: run cleanup_cfg just before loop_optimizer_init (PR 84659)

On 12.04.2018 0:55, Alexander Monakov wrote: > As noted in PR 85354, we cannot simply invoke cfg_cleanup after dominators are > computed, because they may become invalid but neither freed nor recomputed, so > this trips checking in flow_loops_find. > > We can move cleanup_cfg earlier (and run it

Re: [PATCH] Fix non-AVX512VL handling of lo extraction from AVX512F xmm16+ (PR target/85328)

On Thu, Apr 12, 2018 at 01:46:40PM +0300, Kirill Yukhin wrote: > > Hello Jakub! > > > On 11 Apr 2018, at 16:27, Jakub Jelinek wrote: > > In lots of patterns we assume that we never see xmm16+ hard registers > > with 128-bit and 256-bit vector modes when not -mavx512vl, because

[PATCH] Make redirection only for target_clones: V2 (PR ipa/85329).

Hi. I'm sending V2. The patch adjusts: - make redirection just for target_clones, done simply by recording nodes where expand_target_clones return true - reset various DECL_* flags on default version, needed for ipa-visibility assert I've seen - handle empty string in target_clones:

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

> Hi. > > I'm reminding review request from Richi for generic part > and Uros/Honza for target part. OK for i386 bits. Honza > > Thanks, > Martin

Re: [wwwdocs] document new options in gcc-8/changes.html

On Wed, Apr 11, 2018 at 10:02 PM, Martin Sebor wrote: > On 04/04/2018 05:03 PM, Paolo Carlini wrote: >> >> Hi Martin >> >> On 05/04/2018 00:28, Martin Sebor wrote: >>> >>> + implementations do suppresses the warning. >> >> suppress > > > I was about to fix this but

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

Hi. I'm reminding review request from Richi for generic part and Uros/Honza for target part. Thanks, Martin

[PATCH] libgcc/CET: Add _CET_ENDBR to __stack_split_initialize

Program received signal SIGSEGV, Segmentation fault. __stack_split_initialize () at /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751 751 leaq-16000(%rsp),%rax # We should have at least 16K. Missing separate debuginfos, use: dnf debuginfo-install

Re: [PATCH] Make redirection only for target_clones: V2 (PR ipa/85329).

Forgot to add the patch. Martin >From fb1bbf142af6668eeb1bdfeec96920de2f0edb21 Mon Sep 17 00:00:00 2001 From: marxin Date: Thu, 12 Apr 2018 12:15:17 +0200 Subject: [PATCH] Make redirection only for target_clones: V2 (PR ipa/85329). gcc/ChangeLog: 2018-04-12 Martin Liska

Re: [PATCH] Don't mark IFUNC resolver as only called directly

On Thu, Apr 12, 2018 at 5:17 AM, Jan Hubicka wrote: >> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote: >> > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as >> > only called directly. >> > >> > OK for trunk? >> > >> > >> > H.J. >> >

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, 12 Apr 2018, Martin Liška wrote: > Hi. > > I'm reminding review request from Richi for generic part > and Uros/Honza for target part. Not sure if I missed some important part of the discussion but for the testcase we want to preserve the tailcall, right? So it would be enough to set

Re: [PATCH] Don't mark IFUNC resolver as only called directly

On Thu, Apr 12, 2018 at 5:13 AM, Richard Biener wrote: > On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote: >> Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as >> only called directly. >> >> OK for trunk? >> >> >> H.J. >> ---

[og7, nvptx] Simplifly logic in nvptx_single

Hi, this patch simplifies the logic in nvptx_single. Build x86_64 with nvptx accelerator and tested libgomp. Thanks, - Tom [nvptx] Simplifly logic in nvptx_single 2018-04-12 Tom de Vries * config/nvptx/nvptx.c (nvptx_single): Simplify init of vector variable. Add

Re: [PATCH] Make redirection only for target_clones: V2 (PR ipa/85329).

> 2018-04-12 Martin Liska > > PR ipa/85329 > * multiple_target.c (create_dispatcher_calls): Set apostrophes > for target_clone error message. > (separate_attrs): Add new argument and check for an emptry > string. > (expand_target_clones):

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

Jakub Jelinek wrote: > On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote: >> The tailcall issue is just a distraction. Historically the handling of >> mempcpy  >> has been horribly inefficient in both GCC and GLIBC for practically all >> targets. >> This is why it was decided to

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote: > Jakub Jelinek wrote: > > On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote: > >> Not sure if I missed some important part of the discussion but > >> for the testcase we want to preserve the tailcall, right? So > >> it

Re: Patch ping^3

On 04/12/2018 02:41 AM, Richard Biener wrote: > On Thu, 12 Apr 2018, Jakub Jelinek wrote: > >> Hi! >> >> I'd like to ping the >> >> http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html >> - PR83157 - improve debug info for x86 setcc peepholes >> >> patch. Thanks. > > OK for stage1 and

Re: [PATCH] Make redirection only for target_clones: V2 (PR ipa/85329).

On Thu, Apr 12, 2018 at 03:46:26PM +0200, Jan Hubicka wrote: > If you make C++ inline and get the idea to use target cloning attribute on > this, > this will likely lead to link error if you compile multiple files because you > turn comdat to non-comdat. > > For comdats this woudl effectivly

Re: [wwwdocs] [COMMITTED] ARC gcc8 changes entry

On 11 April 2018 13:05:52 CEST, Claudiu Zissulescu wrote: >Hi, > >Please find the ARC's gcc8 changes entry section as committed to >wwwdocs. s/qualifer/qualifier/ thanks,

[PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657, take 2)

On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote: > > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got added, > > in 2013 other power versions, in 2016 s390*, etc.  Doing a decent mempcpy > > isn't hard if you have asm version of memcpy and one spare register. >

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

Jakub Jelinek wrote: > On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote: >> Not sure if I missed some important part of the discussion but >> for the testcase we want to preserve the tailcall, right? So >> it would be enough to set avoid_libcall to >> endp != 0 && CALL_EXPR_TAILCALL

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

Jakub Jelinek wrote: >On Thu, Apr 12, 2018 at 04:30:07PM +, Wilco Dijkstra wrote: >> Jakub Jelinek wrote: >> Frankly I don't see why it is a P1 regression. Do you have a benchmark that > >That is how regression priorities are defined. How can one justify considering this a release blocker

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, Apr 12, 2018 at 04:30:07PM +, Wilco Dijkstra wrote: > Jakub Jelinek wrote: > > On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote: > > >> The tailcall issue is just a distraction. Historically the handling of > >> mempcpy  > >> has been horribly inefficient in both GCC

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, Apr 12, 2018 at 05:17:29PM +0200, Richard Biener wrote: > >For -Os that is easily measurable regression, for -O2 it depends on the > >relative speed of memcpy vs. mempcpy and whether one or both of them > >are in > >I-cache or not. > > Well, then simply unconditionally not generate a

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On April 12, 2018 5:38:44 PM GMT+02:00, Jakub Jelinek wrote: >On Thu, Apr 12, 2018 at 05:17:29PM +0200, Richard Biener wrote: >> >For -Os that is easily measurable regression, for -O2 it depends on >the >> >relative speed of memcpy vs. mempcpy and whether one or both of them >>

Re: [PATCH] PR libstdc++/85222 allow catching iostream errors as gcc4-compatible ios::failure

On 10 April 2018 at 00:36, Jonathan Wakely wrote: > Define a new exception type derived from std::ios::failure[abi:cxx11] > which also aggregates an object of the gcc4-compatible ios::failure > type. Make __throw_ios_failure throw this new type for iostream errors > that raise exceptions. Provide

C++ PATCH for c++/85258, ICE with invalid range-based for-loop

This is a crash on invalid which started when we changed decl_maybe_constant_var_p to say true for references. Then in tsubst_copy we take this branch: if (decl_maybe_constant_var_p (r)) { /* We can't call cp_finish_decl, so handle the

Re: [PATCH] Make redirection only for target_clones: V2 (PR ipa/85329).

On Thu, Apr 12, 2018 at 07:53:35PM +0200, Jakub Jelinek wrote: > On Thu, Apr 12, 2018 at 03:46:26PM +0200, Jan Hubicka wrote: > > If you make C++ inline and get the idea to use target cloning attribute on > > this, > > this will likely lead to link error if you compile multiple files because > >

[PATCH][OBVIOUS] PR85347: New testcase vec-ldl-1.c FAILs on powerpc64-linux

This new test case required a dejagnu qualifier to restrict its execution on big-endian platforms. The patch bootstrapped and tested without regressions.  Was committed as obvious. gcc/testsuite/ChangeLog: 2018-04-12  Kelvin Nilsen      PR target/85347     *

Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955

On Wed, Apr 11, 2018 at 12:30 PM, Cesar Philippidis wrote: > On 04/09/2018 04:31 AM, Richard Biener wrote: >> On Fri, 6 Apr 2018, Jakub Jelinek wrote: >> >>> On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote: 2018-04-06 Cesar Philippidis

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Thu, Apr 12, 2018 at 8:53 AM, Wilco Dijkstra wrote: > So generally it's a good idea to change mempcpy into memcpy by default. It's > not slower than calling mempcpy even if you have a fast implementation, it's > faster > if you use an up to date GLIBC which calls

Re: Fix PR target/85238

On April 12, 2018 4:18:47 PM GMT+02:00, Eric Botcazou wrote: >This makes -g work again in LTO mode for Windows targets by kludging >around >the missing support for copying PE-COFF debug sections in the simple >object >module of libiberty, thus effectively disabling early

Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955

On 04/12/2018 11:27 AM, H.J. Lu wrote: > On Wed, Apr 11, 2018 at 12:30 PM, Cesar Philippidis > wrote: >> On 04/09/2018 04:31 AM, Richard Biener wrote: >>> On Fri, 6 Apr 2018, Jakub Jelinek wrote: >>> On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote:

Re: [PATCH] libgcc/CET: Skip signal frames when unwinding shadow stack

On Wed, Apr 11, 2018 at 3:37 AM, H.J. Lu wrote: > When -fcf-protection -mcet is used, I got > > FAIL: g++.dg/eh/sighandle.C > > (gdb) bt > #0 _Unwind_RaiseException (exc=exc@entry=0x416ed0) > at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140 > #1

C++ PATCH for c++/85356, C++17 ICE with pointer to member function in template

We weren't instantiating exception-specifications when a template referred to them, but that won't fly in the C++17 world where they're part of the type, so we need to resolve them to do overload resolution for non-dependent expressions. The change to check_redeclaration_exception_specification

[PATCH] avoid duplicate warning for strcmp with a nonstring (PR 85359)

The attached patch makes a small tweak to avoid issuing a duplicate warning for calls to strcmp with a nonstring argument. The most onerous part of this was figuring out how to test for the absence of duplicate warnings. The "hack" I used (dg-regexp) is in place until a more straightforward

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

Well, here's a variation which actually passes regression-test. Seems I implicitly believed that the implicit save on main program variables actually works... well, it turns out that it doesn't, which is now PR85364. OK for trunk? Thomas 2018-04-12 Thomas Koenig

Re: C++ PATCH for c++/85258, ICE with invalid range-based for-loop

OK. On Thu, Apr 12, 2018 at 1:47 PM, Marek Polacek wrote: > This is a crash on invalid which started when we changed > decl_maybe_constant_var_p > to say true for references. Then in tsubst_copy we take this branch: > if (decl_maybe_constant_var_p (r)) >

[PATCH] configure.ac: honor --with-gcc-major-version in gcc-driver-name.h (PR jit/85384)

This patch updates gcc/configure.ac to use gcc_base_ver. I had to drop the \$\$ from the sed expression to get it to work within the configure script; I'm not entirely sure what their purpose is. Without them, it's still matching on the first group of numeric characters in BASE-VER. Tested with

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

On Thu, Apr 12, 2018 at 11:14:45PM +0200, Thomas Koenig wrote: > 2018-04-12 Thomas Koenig > > PR fortran/83064 > PR testsuite/85346 > * trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind > for annotation and remove dependence on

[PATCH] Fix -fsanitize=address VLA instrumentation (PR sanitizer/85230)

Hi! As mentioned in the PR, we need to unpoison the red zones when leaving a scope with VLA variable(s); this is done through __asan_allocas_unpoison call, unfortunately it is called after the __builtin_stack_restore which restores the stack pointer; now, if an interrupt comes in between the

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657, take 2)

On Thu, Apr 12, 2018 at 07:37:22PM +0200, Jakub Jelinek wrote: > On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote: > > > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got > > > added, > > > in 2013 other power versions, in 2016 s390*, etc.  Doing a decent mempcpy

[PATCH] Fix CSE CLZ/CTZ handling (PR rtl-optimization/85376)

Hi! The following testcase is miscompiled, because due to various disabled optimization passes we end up with a dead bsf instruction (CTZ) of a register known to be zero. fold_rtx uses simplify_unary_operation, which has in this case: case CTZ: if (wi::ne_p (op0, 0))

Re: [PATCH] configure.ac: honor --with-gcc-major-version in gcc-driver-name.h (PR jit/85384)

On Thu, Apr 12, 2018 at 04:51:21PM -0400, David Malcolm wrote: > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > OK for trunk? > > config/ChangeLog: > PR jit/85384 > * acx.m4 (GCC_BASE_VER): Remove \$\$ from sed expression. > > gcc/ChangeLog: > PR jit/85384

[PATCH] rs6000: Fix an ICE with -mno-direct-move (PR85291)

This fixes an ICE with -mno-direct-move. Tested etc.; committing. Segher 2018-04-12 Segher Boessenkool * config/rs6000/rs6000.md (fix_truncsi2): Use legacy code if asked to not generate direct moves. (fix_truncsi2_stfiwx): Similar.

Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955

On Thu, Apr 12, 2018 at 11:39:43AM -0700, Cesar Philippidis wrote: > Strange. I didn't observe any regressions when I tested it. But, then > again, I was testing against revision > > r259092 | jason | 2018-04-04 09:42:55 -0700 (Wed, 04 Apr 2018) | 4 lines > > which is over a week old. I'll

Re: [PATCH] PR libstdc++/85222 allow catching iostream errors as gcc4-compatible ios::failure

This fixes some comments with misspelled files and classes. Committed to trunk and gcc-7-branch. It occurred to me that the name of the new __ios_failure type is visible in the verbose terminate handler messages: terminate called after throwing an instance of 'std::__ios_failure' what():

Re: [PATCH] Don't mark IFUNC resolver as only called directly

On Thu, Apr 12, 2018 at 6:39 AM, H.J. Lu wrote: > On Thu, Apr 12, 2018 at 5:17 AM, Jan Hubicka wrote: >>> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote: >>> > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as >>>

[committed] Prevent erroneous "macro had not yet been defined" messages (PR c++/85385)

PR c++/85385 reports an issue where we emit bogus "macro had not yet been defined" notes when a macro is mis-used: $ cat test.c #define MACRO(X,Y) void test () { MACRO(42); } $ ./xg++ -B. -c test.c test.c:5:11: error: macro "MACRO" requires 2 arguments, but only 1 given

[PATCH, rs6000] (PR84302) Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative

The powerpc versions of _mm_slli_epi32 and __mm_slli_epi64 in emmintrin.h do not properly handle shift values between 16 and 31, inclusive. These were setting up the shift with vec_splat_s32, which only accepts *5 bit signed* shift values, or a range of -16 to 15. Values above 15 produced an

Re: [PATCH] avoid duplicate warning for strcmp with a nonstring (PR 85359)

Attached is a minor update that avoids additional duplicate warnings exposed by more extensive testing (for PR 85369). On 04/12/2018 02:52 PM, Martin Sebor wrote: The attached patch makes a small tweak to avoid issuing a duplicate warning for calls to strcmp with a nonstring argument. The most

[PATCH] issue nonstring warning for strcpy even on s360 (PR 85369)

PR 85369 notes that the c-c++-common/attr-nonstring-3.c fails on IBM Z (and other similar targets) whose back-end provides the movstr expander. The failure is cause by an expected warning failing to trigger because the strcpy call is expanded early and the checker never runs. The attached patch

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On April 12, 2018 4:31:12 PM GMT+02:00, Jakub Jelinek wrote: >On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote: >> Well, but that wouldn't be a fix for a regression and IMHO there's >> no reason for a really lame mempcpy. If targets disgree well, > >It is a