Re: [PATCH] Fix when -lssp is added by driver (PR middle-end/81400).

On 07/26/2017 07:45 PM, Jeff Law wrote: > On 07/12/2017 07:38 AM, Martin Liška wrote: >> Hi. >> >> Following patch adds -lspp when one uses -mstack-protector-guard=global. >> >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >> >> Ready to be installed? >> >> Martin >> >

[PATCH] Fix a pasto in gfc_check_num_images

Hi! bootstrap-ubsan reported taking address of a &distance->where when distance is NULL. The function has one block guarded with if (distance) and another guarded with if (failed), so I think this is just a pasto from the earlier if (distance) block. Bootstrapped/regtested on x86_64-linux and i6

[PATCH] Fix UB in ipa-polymorphic-call.c (PR tree-optimization/81603)

Hi! ipa_polymorphic_call_context offset field is in bits (for whatever reason), and the following computations can overflow and invoke UB. This patch computes it in offset_int instead and punts if there is overflow. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-07-31

Re: [RFC] Remaining references of Java

On 07/25/2017 01:55 PM, Richard Biener wrote: > On Tue, Jul 11, 2017 at 4:35 PM, Martin Liška wrote: >> Hi. >> >> There's a small follow-up with remaining occurrences: >> >> 1) dwarf2out.c: >> >> 20213 origin_die = lookup_type_die (origin); >> 20214else if (TREE_CODE (origin) == BLOCK)

Re: [PATCH 4/N] Recover GOTO predictor.

Richi? Thanks On 06/30/2017 03:48 PM, Martin Liška wrote: > On 06/22/2017 12:27 PM, Richard Biener wrote: >> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote: >>> Hello. >>> >>> There's one additional predictor enhancement that is GOTO predict that >>> used to working. Following patch adds ex

Re: [RFC] [PATCH] Introduce configure flag --with-stage1-cflags.

I would like to ping this. Input from other people will be appreciated ;) Thanks, Martin On 06/19/2017 02:30 PM, Richard Biener wrote: > On Mon, Jun 19, 2017 at 12:51 PM, Martin Liška wrote: >> PING^1 >> >> Richi are you fine with the suggested change? I basically followed your >> advises :) >

[PATCH] Fix ubsan_type_descriptor

Hi! Last week I've finally decided to find time to look into sometimes very weird signed-integer-overflow runtime messages, which report that say signed integer overflow: 1234567890123456 \\* 1234567890123456 cannot be represented in type 'long int[10]' Obviously the integer overflow is not happe

[PATCH] Introduce TARGET_SUPPORTS_ALIASES

Hi. Doing the transformation suggested by Honza. Patch can bootstrap on ppc64le-redhat-linux and x86_64-linux-gnu and survives regression tests. And I also verified that works on hppa2.0w-hp-hpux11.11 (target w/o aliasing support). Ready to be installed? Martin >From f8584bcb678dba92241c20b3e8

Re: [PATCH] Fix UB in ipa-polymorphic-call.c (PR tree-optimization/81603)

On Mon, 31 Jul 2017, Jakub Jelinek wrote: > Hi! > > ipa_polymorphic_call_context offset field is in bits (for whatever reason), > and the following computations can overflow and invoke UB. > This patch computes it in offset_int instead and punts if there is overflow. > > Bootstrapped/regtested o

Re: [PATCH] Fix ubsan_type_descriptor

On Mon, 31 Jul 2017, Jakub Jelinek wrote: > Hi! > > Last week I've finally decided to find time to look into sometimes very > weird signed-integer-overflow runtime messages, which report that say > signed integer overflow: 1234567890123456 \\* 1234567890123456 cannot be > represented in type 'lo

Re: [PATCH] Do UBSAN sanitization just when current_function_decl != NULL_TREE (PR sanitize/81530).

On Fri, Jul 28, 2017 at 01:20:57PM +0200, Martin Liška wrote: > Hi. > > In r249158 I added new sanitize_flags_p function. However I removed various > calls of > do_ubsan_in_current_function: > > /* True if we want to play UBSan games in the current function. */ > > bool > do_ubsan_in_current_f

Re: [Patch] Testsuite fixes for failures caused by patch for PR 80925 - loop peeling and alignment

On Fri, Jul 28, 2017 at 8:22 PM, Steve Ellcey wrote: > On Fri, 2017-07-28 at 09:47 +0200, Richard Biener wrote: >> On Fri, Jul 28, 2017 at 12:16 AM, Steve Ellcey wrote: >> > >> > Any comments from the power and/or vectorizer folks? >> On one side I'm inclined to simplify the testsuite by adding >

Re: [PATCH] Handle BIT_INSERT_EXPR in hashable_expr_equal_p

On Sat, Jul 29, 2017 at 8:48 PM, Andrew Pinski wrote: > Hi, > When I was playing around where lowering of bit-field accesses go in > the pass order, I found that DOM had the same issue as PRE had when it > came to comparing BIT_INSERT_EXPR for equality. The same exact > testcase was showing the

[PING*3][PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

Hello, Ping for the updated patch, originally submitted at . Thank you in advance! -- Pierre-Marie de Rodat

Re: [PATCH v2] Dump BB number when dumping a BB with label.

On Mon, Jul 31, 2017 at 8:43 AM, Martin Liška wrote: > On 07/28/2017 01:21 PM, Richard Biener wrote: >> On Fri, Jul 28, 2017 at 12:52 PM, Martin Liška wrote: >>> On 07/28/2017 09:58 AM, Richard Biener wrote: On Fri, Jul 28, 2017 at 9:50 AM, Martin Liška wrote: > On 07/28/2017 09:21 AM,

Re: [PATCH] Fix a pasto in gfc_check_num_images

On Mon, Jul 31, 2017 at 9:39 AM, Jakub Jelinek wrote: > Hi! > > bootstrap-ubsan reported taking address of a &distance->where when > distance is NULL. The function has one block guarded with if (distance) > and another guarded with if (failed), so I think this is just a pasto > from the earlier i

Re: [PATCH v2] Dump BB number when dumping a BB with label.

On 07/31/2017 10:50 AM, Richard Biener wrote: > On Mon, Jul 31, 2017 at 8:43 AM, Martin Liška wrote: >> On 07/28/2017 01:21 PM, Richard Biener wrote: >>> On Fri, Jul 28, 2017 at 12:52 PM, Martin Liška wrote: On 07/28/2017 09:58 AM, Richard Biener wrote: > On Fri, Jul 28, 2017 at 9:50 AM,

Re: [PATCH] Do UBSAN sanitization just when current_function_decl != NULL_TREE (PR sanitize/81530).

On 07/31/2017 10:27 AM, Marek Polacek wrote: > On Fri, Jul 28, 2017 at 01:20:57PM +0200, Martin Liška wrote: >> Hi. >> >> In r249158 I added new sanitize_flags_p function. However I removed various >> calls of >> do_ubsan_in_current_function: >> >> /* True if we want to play UBSan games in the cur

Re: [PATCH 4/N] Recover GOTO predictor.

On Mon, Jul 31, 2017 at 9:46 AM, Martin Liška wrote: > Richi? 4 is fine. > Thanks > > On 06/30/2017 03:48 PM, Martin Liška wrote: >> On 06/22/2017 12:27 PM, Richard Biener wrote: >>> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote: Hello. There's one additional predictor enha

Re: [PATCH] Fix PR81354 (rewrite gimple_split_edge)

On Sun, Jul 30, 2017 at 8:04 PM, Bill Schmidt wrote: > Hi, > > PR81354 identifies a latent bug that can happen in SLSR since the > conditional candidate support was first added. SLSR relies on the > address of a GIMPLE PHI remaining constant during the course of the > optimization pass, but it ne

Re: [ARM, VXworks] Fix build

On 25/07/17 11:31, Olivier Hainque wrote: > Hi Richard, > > (back from a few days away) > >> On Jul 17, 2017, at 12:01 , Eric Botcazou wrote: >> >>> That's good news. Does that mean we'll be able to drop the old stuff >>> though? I'd really like to make progress towards removing the old ABI >>

Re: [PATCH] Introduce TARGET_SUPPORTS_ALIASES

On Mon, Jul 31, 2017 at 9:04 AM, Martin Liška wrote: > Hi. > > Doing the transformation suggested by Honza. > > Patch can bootstrap on ppc64le-redhat-linux and x86_64-linux-gnu and survives > regression tests. > And I also verified that works on hppa2.0w-hp-hpux11.11 (target w/o aliasing > suppo

Re: [PING] [PATCH v4 0/12] [i386] Improve 64-bit Microsoft to System V ABI pro/epilogues

On 07/28/2017 09:41 AM, H.J. Lu wrote: On Fri, Jul 28, 2017 at 6:57 AM, Daniel Santos wrote: On 07/26/2017 02:03 PM, H.J. Lu wrote: This patch caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81563 Hello. I've rebased my patch set and I'm now retesting. I'm afraid that your changes are

C++ PATCH to fix ICE with bit-fields and ?: (PR c++/81607)

We crash in the gimplifier because it sees a shift expression with different types of op1/op2. The problem arises in cp_fold: it gets "1 ? d.c : 0" of type int which is folded to "d.c", but it then sees that d.c is a bit-field with declared type long int, so if produces "(long int) d.c" -- but tha

[PATCH 0/6] [i386] PR80969 Fix ICE with -mabi=ms -mavx512f

When working on the Wine64 project to use aligned SSE MOVs after SP realignment and adding -mcall-ms2sysv-xlogues, I overlooked the fact that the function body may require a stack alignment greater than 16-bytes. This can result in an ICE with -mabi=ms -mavx512f and some other cases. This pat

[PATCH 1/6] [i386] Correct comments, add assertions to sp_valid_at and fp_valid_at

When we realign the stack frame (without DRAP), there may be a range of CFA offsets that should never be touched because they are alignment padding and any reference to them is almost certainly an error. Previously, only the offset of where the realigned stack frame starts was recorded and checked

[PATCH 2/6] [i386] Remove ix86_frame::outlined_save_offset

This value was used in an earlier incarnation of the -mcall-ms2sysv-xlogues patch set but is now set and never read. The value of ix86_frame::sse_reg_save_offset serves the same purpose. Signed-off-by: Daniel Santos --- gcc/config/i386/i386.c | 1 - gcc/config/i386/i386.h | 4 +--- 2 files chan

[PATCH 3/6] [i386] Remove machine_function::call_ms2sysv_pad_out

The -mcall-ms2sysv-xlogues project added the boolean fields call_ms2sysv_pad_in and call_ms2sysv_pad_out to struct machine_function to track rather or not an additional 8 bytes of padding was needed for stack alignment prior to and after the stub save area. This design was based upon the faulty as

[PATCH 4/6] [i386] Modify ix86_compute_frame_layout

These changes affect how the stack frame is calculated from the region starting at frame.reg_save_offset until frame.frame_pointer_offset, which includes either the stub save area or the (inline) SSE register save area and the va_args register save area. The calculation used when not realigning th

[PATCH 5/6] [i386] Modify SP realignment in ix86_expand_prologue, et. al.

The SP allocation calculation is now done in ix86_compute_frame_layout and the result stored in ix86_frame::stack_realign_allocate. This change also updates comments for choose_baseaddr to clarify that the alignment returned doesn't necessarily reflect the alignment of the cfa_offset passed (e.g.,

[PATCH 6/6] [i386, testsuite] Add tests, fix bug in check_avx2_hw_available

The testcase in the PR is used as a base and relevant variants are added to test other factors affected by the patch set. pr80969-1.c Base test case. pr80969-2.c With ms to sysv call. pr80969-2a.c With ms to sysv call using stubs. pr80969-3.c With alloca (for DRAP test). pr80969-4.c With

[PATCH][v2] Introduce TARGET_SUPPORTS_ALIASES

On 07/31/2017 11:57 AM, Yuri Gribov wrote: > On Mon, Jul 31, 2017 at 9:04 AM, Martin Liška wrote: >> Hi. >> >> Doing the transformation suggested by Honza. >> >> Patch can bootstrap on ppc64le-redhat-linux and x86_64-linux-gnu and >> survives regression tests. >> And I also verified that works on

Re: C PATCH to display types when printing a conversion warning (PR c/81233)

Ping. On Thu, Jul 20, 2017 at 12:53:10PM +0200, Marek Polacek wrote: > On Wed, Jul 19, 2017 at 10:51:33AM -0400, David Malcolm wrote: > > The changes to diagnostic-core.h and diagnostic.c are OK. > > Thanks. > > > > Also, > > > PEDWARN_FOR_ASSIGNMENT didn't work with the addition of printing TY

[Committed] S/390: Support z14 as CPU name.

With IBM z14 officially announced we can add support for z14 as preferred CPU name. We still pass arch12 to Binutils in order to keep older Binutils versions supported. Bootstrapped and regression-tested on s390x. Committed to mainline and GCC 7 branch. Bye, -Andreas- gcc/ChangeLog: 2017-07

Re: [PATCH] Make inlining consistent in LTO and non-LTO mode (PR target/71991).

Honza? Thanks, Martin On 06/30/2017 03:50 PM, Martin Liška wrote: > On 06/28/2017 05:18 PM, Jan Hubicka wrote: >>> On 06/28/2017 04:24 PM, Jan Hubicka wrote: > - /* If callee has no option attributes, then it is ok to inline. */ > - if (!callee_tree) > + /* If callee has no option

Re: [PATCH v12] add -fpatchable-function-entry=N,M option

On Jul 26, 2017, at 5:33 PM, Andreas Schwab wrote: > > On Jul 26 2017, Torsten Duwe wrote: > >> On Wed, Jul 26, 2017 at 04:16:25PM +0200, Andreas Schwab wrote: >>> On Jul 07 2017, Torsten Duwe wrote: >>> diff --git a/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c b/gcc/

[PATCH, committed] Add myself to MAINTAINERS

ChangeLog: 2017-07-31 Robin Dapp * MAINTAINERS (write after approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (revision 250740) +++ MAINTAINERS (working copy) @@ -356,6 +356,7 @@ Lawrence Crowl Ian Dall

Re: [PATCH, i386]: Implement attribute ((naked))

On Sun, Jul 30, 2017 at 10:14 PM, Uros Bizjak wrote: > Hello! > > attribute ((naked)) generates function body without function frame, > and as shown in PR 25967 [1], users are looking for this feature also > for x86 targets. Recently, Daniel introduced a testcase that would > benefit from this att

Re: [PATCH] Fix PR81354 (rewrite gimple_split_edge)

That would certainly be much simpler! I'll regstrap it and test it on the other occurrence I've found to be certain. -- Bill > On Jul 31, 2017, at 4:15 AM, Richard Biener > wrote: > > On Sun, Jul 30, 2017 at 8:04 PM, Bill Schmidt > wrote: >> Hi, >> >> PR81354 identifies a latent bug that ca

[PATCH] Fix typo in std::stack (PR libstdc++/81599)

The documentation of std::stack says that the underlying container must support pop_front, but that is wrong, it meant to say pop_back, so this patch fixes that. Ok for trunk? 2017-07-31 Marek Polacek PR libstdc++/81599 * include/bits/stl_stack.h: Fix typo. diff --git gcc/inc

[WWW PATCH]: Mention that x86 now supports "naked" function attribute.

One liner that mentions new addition to x86 port. OK for wwwdocs? Uros. Index: htdocs/gcc-8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v retrieving revision 1.7 diff -u -r1.7 changes.html --- htdocs/gcc-8/c

Re: [PATCH] Fix typo in std::stack (PR libstdc++/81599)

On 31 July 2017 at 16:25, Marek Polacek wrote: > The documentation of std::stack says that the underlying container must > support > pop_front, but that is wrong, it meant to say pop_back, so this patch fixes > that. Indeed, the documentation has a copy-pasto originating from bits/stl_queue.h.

Re: [PATCH] Fix typo in std::stack (PR libstdc++/81599)

On Mon, Jul 31, 2017 at 04:37:19PM +0300, Ville Voutilainen wrote: > On 31 July 2017 at 16:25, Marek Polacek wrote: > > The documentation of std::stack says that the underlying container must > > support > > pop_front, but that is wrong, it meant to say pop_back, so this patch fixes > > that. >

[PATCH] Compile pr79793-[12].c with -mtune=generic

pr79793-1.c and pr79793-2.c are failed when GCC is configured with --with-cpu=slm since lea is used to adjust stack, instead of sub/add. This patch uses -mtune=generic to always generate sub and add. OK for trunk? H.J. * gcc.target/i386/pr79793-1.c: Compile with -mtune=generic.

Re: [PATCH] Compile pr79793-[12].c with -mtune=generic

On Mon, Jul 31, 2017 at 3:47 PM, H.J. Lu wrote: > pr79793-1.c and pr79793-2.c are failed when GCC is configured with > --with-cpu=slm since lea is used to adjust stack, instead of sub/add. > This patch uses -mtune=generic to always generate sub and add. > > OK for trunk? OK. Thanks, Uros. > H.J

Re: [PATCH 2/6] [i386] Remove ix86_frame::outlined_save_offset

On Mon, Jul 31, 2017 at 1:24 PM, Daniel Santos wrote: > This value was used in an earlier incarnation of the > -mcall-ms2sysv-xlogues patch set but is now set and never read. The > value of ix86_frame::sse_reg_save_offset serves the same purpose. OK as obvious patch. Thanks, Uros. > Signed-off

Re: [PATCH 3/6] [i386] Remove machine_function::call_ms2sysv_pad_out

On Mon, Jul 31, 2017 at 1:24 PM, Daniel Santos wrote: > The -mcall-ms2sysv-xlogues project added the boolean fields > call_ms2sysv_pad_in and call_ms2sysv_pad_out to struct machine_function > to track rather or not an additional 8 bytes of padding was needed for > stack alignment prior to and afte

Re: [PATCH] Fix PR81354 (rewrite gimple_split_edge)

> On Jul 31, 2017, at 8:19 AM, Bill Schmidt wrote: > > That would certainly be much simpler! I'll regstrap it and test it on the > other > occurrence I've found to be certain. Unfortunately, this fails bootstrap: /home/wschmidt/gcc/gcc-mainline-test/gcc/calls.c: In function 'rtx_def* emit

[PATCH PR81620]Don't set has_max_use_after flag for store-store chain

c3e44 Mon Sep 17 00:00:00 2001 From: Bin Cheng Date: Mon, 31 Jul 2017 10:24:07 +0100 Subject: [PATCH 1/2] pr81620-20170731.txt --- gcc/testsuite/gcc.dg/tree-ssa/pr81620-1.c | 20 gcc/testsuite/gcc.dg/tree-ssa/pr81620-2.c | 25 + gcc/tree-pred

[PATCH PR81267]Rewrite into loop closed ssa form in case of any store-store chain

-optimization/81627 * gcc.dg/tree-ssa/pr81627.c: New.From d366015187de926a8fe3248325b229bed99b27b5 Mon Sep 17 00:00:00 2001 From: Bin Cheng Date: Mon, 31 Jul 2017 11:16:44 +0100 Subject: [PATCH 2/2] pr81627-20170731.txt --- gcc/testsuite/gcc.dg/tree-ssa/pr81627.c | 28

C PATCH to further improve diagnostic for -Wsign-compare (PR c/81417)

This patch improves the diagnostic of -Wsign-compare for ?: by also printing the types, similarly to my recent patch. But we can do even better here if we actually point to the operand in question, so I passed the locations of the operands from the parser. So instead of x.c:8:16: warning: signe

Re: [PATCH] libstdc++: Support std::is_aggregate on clang++ (was [cfe-dev] clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7)

On 27/07/17 16:27 +0900, Katsuhiko Nishimra wrote: From 56c4a18d0d8c8ce7aa1239880138775e4db06645 Mon Sep 17 00:00:00 2001 From: Katsuhiko Nishimra Date: Thu, 27 Jul 2017 16:03:54 +0900 Subject: [PATCH] libstdc++: Support std::is_aggregate on clang++ Currently, libstdc++ tries to detect __is_agg

PING: [PATCH] PR driver/81523: Make -static override -pie

On Mon, Jul 24, 2017 at 10:24 AM, H.J. Lu wrote: > On Sun, Jul 23, 2017 at 8:14 AM, H.J. Lu wrote: >> -static and -pie together behave differently depending on whether GCC is >> configured with --enable-default-pie. On x86, "-static -pie" fails to >> create executable when --enable-default-pie i

Re: [PATCH] libstdc++: Support std::is_aggregate on clang++ (was [cfe-dev] clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7)

On Mon, Jul 31, 2017 at 10:53 AM, Jonathan Wakely wrote: > On 27/07/17 16:27 +0900, Katsuhiko Nishimra wrote: >> >> From 56c4a18d0d8c8ce7aa1239880138775e4db06645 Mon Sep 17 00:00:00 2001 >> From: Katsuhiko Nishimra >> Date: Thu, 27 Jul 2017 16:03:54 +0900 >> Subject: [PATCH] libstdc++: Support st

Re: C PATCH to further improve diagnostic for -Wsign-compare (PR c/81417)

On Mon, 2017-07-31 at 16:14 +0200, Marek Polacek wrote: > This patch improves the diagnostic of -Wsign-compare for ?: by also > printing > the types, similarly to my recent patch. But we can do even better > here if we > actually point to the operand in question, so I passed the locations > of the

Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640)

On 07/26/2017 02:02 PM, Alexander Monakov wrote: > On Wed, 26 Jul 2017, Alexander Monakov wrote: > >> On Wed, 26 Jul 2017, Jeff Law wrote: >>> I'm not sure what you mean by extraneous compiler barriers -- isn't the >>> worst case scenario here that the target emits them as well? So there >>> woul

Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640)

On 07/26/2017 12:13 PM, Alexander Monakov wrote: > On Wed, 26 Jul 2017, Jeff Law wrote: >> I'm not sure what you mean by extraneous compiler barriers -- isn't the >> worst case scenario here that the target emits them as well? So there >> would be an extraneous one in that case, but that ought to

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 05/08

On 07/21/2017 02:25 PM, Segher Boessenkool wrote: > On Thu, Jul 20, 2017 at 08:20:52AM -0600, Jeff Law wrote: >>> Can only combine-stack-adjustments do this? It seems like something >>> many passes could do, and then your new note doesn't help. >> SO far it's only been observed with c-s-a, but fur

Re: C PATCH to further improve diagnostic for -Wsign-compare (PR c/81417)

On 07/31/2017 08:14 AM, Marek Polacek wrote: This patch improves the diagnostic of -Wsign-compare for ?: by also printing the types, similarly to my recent patch. But we can do even better here if we actually point to the operand in question, so I passed the locations of the operands from the pa

[PATCH][AArch64] PR71951: Fix unwinding with -fomit-frame-pointer

As described in PR71951, if libgcc is built with -fomit-frame-pointer, unwinding crashes, for example while doing a backtrace. The underlying reason is the Dwarf unwinder does not setup the frame pointer register in the initialization code. When later unwinding a function that uses the frame poin

Re: C PATCH to further improve diagnostic for -Wsign-compare (PR c/81417)

On Mon, Jul 31, 2017 at 09:54:03AM -0600, Martin Sebor wrote: > On 07/31/2017 08:14 AM, Marek Polacek wrote: > > This patch improves the diagnostic of -Wsign-compare for ?: by also printing > > the types, similarly to my recent patch. But we can do even better here if > > we > > actually point to

Re: [WWW PATCH]: Mention that x86 now supports "naked" function attribute.

On Mon, 31 Jul 2017, Uros Bizjak wrote: > One liner that mentions new addition to x86 port. > > OK for wwwdocs? Sure. (Even without asking. ;-) Thanks, Gerald

[PATCH] Fix reassoc var_bound range test optimization (PR tree-optimization/81588)

Hi! This patch fixes a couple of issues in optimize_range_tests_var_bound. One is that if we have ranges[i].in_p, we should be inverting the comparison rather than just swapping or not swapping operands. Then because we want to handle only LT/LE, we want to swap operands and the comparison code i

[PATCH, rs6000] Fix PR81622

Hi, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 reports an ICE-on-invalid for the vec_ld and vec_st built-in functions. This fires when the last argument of the built-in is not a pointer or array type, as is required. We break on this during early expansion of the built-ins into tree code

Re: [PATCH, rs6000] Fix PR81622

On Mon, Jul 31, 2017 at 11:19:26AM -0500, Bill Schmidt wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 reports an ICE-on-invalid > for the vec_ld and vec_st built-in functions. This fires when the last > argument of the built-in is not a pointer or array type, as is required. > We brea

Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640)

On Mon, 31 Jul 2017, Jeff Law wrote: > >> In the middle end patch, do we need a barrier before the fence as well? > >> The post-fence barrier prevents reordering the fence with anything which > >> follows the fence. But do we have to also prevent reordering the fence > >> with prior instructions w

Re: C PATCH to further improve diagnostic for -Wsign-compare (PR c/81417)

On 07/31/2017 10:05 AM, Marek Polacek wrote: On Mon, Jul 31, 2017 at 09:54:03AM -0600, Martin Sebor wrote: On 07/31/2017 08:14 AM, Marek Polacek wrote: This patch improves the diagnostic of -Wsign-compare for ?: by also printing the types, similarly to my recent patch. But we can do even bette

[PATCH, Fortran] Correctly set -fd-lines-as-comments with -fdec

All, This is a simple patch. The original intent was for -fdec to set -fd-lines-as-comments by default if flag_d_lines was unspecified by the user. However, currently flag_d_lines is interrogated in set_dec_flags(), usually before its final value is determined. The attached patch fixes this behavi

[PATCH, Fortran] Slight cleanup in set_dec_flags

All, Attached is a trivial patch which exists for posterity: currently set_dec_flags(int value) enables support for legacy standards and disables warnings for them etc... Unfortunately it does this irrespective of the int value parameter. Since set_dec_flags(0) is called on initialization, the leg

Re: [PATCH 0/6] [i386] PR80969 Fix ICE with -mabi=ms -mavx512f

Well I just learned how to test 32-bit earlier and I've uncovered a problem when running 32-bit tests. Do you want me to commit the the two patches (squashed together) in the mean time? Thanks, Daniel

Re: [PATCH] libstdc++: Support std::is_aggregate on clang++ (was [cfe-dev] clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7)

On Mon, Jul 31, 2017 at 11:13 AM, Tim Song wrote: > > https://clang.llvm.org/docs/LanguageExtensions.html#checks-for-type-trait-primitives > seems to suggest using __has_extension instead. Hmm, that doesn't work. Oh well.

Re: [PATCH] enhance overflow and truncation detection in strncpy and strncat (PR 81117)

On 07/08/2017 02:45 PM, Martin Sebor wrote: > PR 81117 asks for improved detection of common misuses(*) of > strncpy and strncat. The attached patch is my solution. It > consists of three related sets of changes: > > 1) Adds a new option, -Wstringop-truncation, that diagnoses calls > to strncpy,

Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640)

On 07/31/2017 11:02 AM, Alexander Monakov wrote: > On Mon, 31 Jul 2017, Jeff Law wrote: In the middle end patch, do we need a barrier before the fence as well? The post-fence barrier prevents reordering the fence with anything which follows the fence. But do we have to also prevent

Re: [PATCH], PR target/81593, Optimize PowerPC vector sets coming from a vector extracts

On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Jul 27, 2017 at 07:21:14PM -0400, Michael Meissner wrote: > > This patches optimizes the PowerPC vector set operation for 64-bit doubles > > and > > longs where the elements in the vector set may have been extra

Re: [PATCH 4/6] lra-assigns.c: give up on qsort checking in assign_by_spills

On 07/15/2017 02:47 PM, Alexander Monakov wrote: > The reload_pseudo_compare_func comparator, when used from assign_by_spills, > can be non-transitive, indicating A < B < C < A if both A and C satisfy > !bitmap_bit_p (&non_reload_pseudos, rAC), but B does not. > > This function was originally a pr

Re: [PATCH], PR target/81593, Optimize PowerPC vector sets coming from a vector extracts

On Sun, Jul 30, 2017 at 09:00:58AM -0500, Bill Schmidt wrote: > >> (define_insn "vsx_concat_" > >> - [(set (match_operand:VSX_D 0 "gpc_reg_operand" "=,we") > >> + [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa,we") > >>(vec_concat:VSX_D > >> - (match_operand: 1 "gpc_reg_operand" "

Re: [PATCH], PR target/81593, Optimize PowerPC vector sets coming from a vector extracts

> On Jul 31, 2017, at 12:40 PM, Michael Meissner > wrote: > > On Sun, Jul 30, 2017 at 09:00:58AM -0500, Bill Schmidt wrote: (define_insn "vsx_concat_" - [(set (match_operand:VSX_D 0 "gpc_reg_operand" "=,we") + [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa,we")

Re: [PATCH 5/6] haifa-sched.c: give up qsort checking when autoprefetch heuristic is in use

On 07/15/2017 02:47 PM, Alexander Monakov wrote: > The autopref_rank_for_schedule sub-comparator and its subroutine > autopref_rank_data lack transitivity. Skip checking if they are in use. > > This heuristic is disabled by default everywhere except ARM and AArch64, > so on other targets this doe

Re: [PATCH] Fix libquadmath regression (bootstrap failure) on FreeBSD

On Wed, 19 Jul 2017, Jakub Jelinek wrote: > > And can you please push this > > to glibc as well (which I do not have access to)? > > glibc uses u_int32_t in all the places of *powl.c where libquadmath > uses uint32_t, and various other files, so I guess it is intentional. I'd consider it a reli

Re: [PATCH] Add -std=c++2a

On Thu, 20 Jul 2017, Andrew Sutton wrote: > This adds a new C++ dialect, enabled by -std=c++2a. I don't see documentation here. I'd expect additions to invoke.texi and standards.texi discussing the new option. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640)

On Mon, 31 Jul 2017, Jeff Law wrote: > > Please consider that expand_mem_thread_fence is used to place fences around > > seq-cst atomic loads&stores when the backend doesn't provide a direct > > pattern. > > With compiler barriers on both sides of the machine barrier, the generated > > sequence fo

Re: [PATCH 6/6] qsort comparator consistency checking

On 07/15/2017 02:47 PM, Alexander Monakov wrote: > This is the updated qsort comparator verifier. > > Since we have vec::qsort(cmp), the patch uses the macro argument counting > trick to redirect only the four-argument invocations of qsort to qsort_chk. > I realize that won't win much sympathies,

Re: [RFC] propagate malloc attribute in ipa-pure-const pass

On 23 May 2017 at 19:10, Prathamesh Kulkarni wrote: > On 19 May 2017 at 19:02, Jan Hubicka wrote: >>> >>> * LTO and memory management >>> This is a general question about LTO and memory management. >>> IIUC the following sequence takes place during normal LTO: >>> LGEN: generate_summary, write_su

Re: [PATCH 6/6] qsort comparator consistency checking

On Mon, 31 Jul 2017, Jeff Law wrote: > I must have missed something. Can't you just define > > qsort (BASE, NMEMB, SIZE, COMPARE) into > > qsort_chk (BASE, NMEMB, SIZE, COMPARE) > > That shouldn't affect the qsort from vec? Right? Or am I missing something If you do #define qsort(base, n

Re: [PATCH] Make mempcpy more optimal (PR middle-end/70140).

On 07/20/2017 12:59 AM, Martin Liška wrote: > Hello. > > Following patch does sharing of expansion for mem{p,}cpy and also strpcy > (with a known constant as source) > so that we use same type of expansion (direct insns emission, direct emission > with a loop instruction and > library call). As

Re: [PATCH 00/19] cleanup of memory stats prototypes

On 07/27/2017 02:43 AM, Richard Biener wrote: > On Thu, Jul 27, 2017 at 10:30 AM, wrote: >> From: Trevor Saunders >> >> The preC++ way of passing information about the call site of a function was >> to >> use a macro that passed __file__, __LINE__, and __FUNCTION__ to a function >> with >> the

Re: [1/2] PR 78736: New warning -Wenum-conversion

On 11 July 2017 at 17:59, Prathamesh Kulkarni wrote: > On 13 June 2017 at 01:47, Joseph Myers wrote: >> This is OK with one fix: >> >>> +C ObjC Var(warn_enum_conversion) Init(0) Warning LangEnabledBy(C Objc,Wall) >> >> I believe the LangEnabledBy arguments are case-sensitive, so you need to >> ha

[PATCH] Update myself in MAINTAINERS

A change of jobs requires a change of email. And I'm going to finally admit that I've not been active gcc development in the last year or two. I am far enough behind that I cannot globally review changes. That said, I do not plan to abandon Alpha just yet. r~ --- MAINTAINERS | 7 ++- 1 fil

[PATCH, Fortran] Support for legacy %FILL fields in STRUCTUREs

All, Attached is a patch which extends the DEC STRUCTURE support to include special fields named '%FILL'. These fields generate anonymous inaccessible components, commonly used in DEC FORTRAN to control alignment of fields within STRUCTUREs. The patch is fairly straightforward. The match is perfor

Re: [PATCH] enhance overflow and truncation detection in strncpy and strncat (PR 81117)

So I think the fixes exposed by the new warning are OK to go in as-is immediately if you wish to do so. Minor questions on the actual improved warnings inline. Sure, thanks. -static inline tree +static tree compute_objsize (tree dest, int ostype) { ... + type = TYPE_MAIN_VARIANT (type

Re: [PATCH, rs6000] Fix PR81622

> On Jul 31, 2017, at 11:27 AM, Jakub Jelinek wrote: > > On Mon, Jul 31, 2017 at 11:19:26AM -0500, Bill Schmidt wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622 reports an ICE-on-invalid >> for the vec_ld and vec_st built-in functions. This fires when the last >> argument of the bui

New French PO file for 'gcc' (version 7.1.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-7.1.0.fr.po', has just

Re: [PATCH, RFC] Proposed PowerPC IEEE 128-bit floating point changes

On Fri, 21 Jul 2017, Michael Meissner wrote: > The first change is to enable the C language to use _Float128 keyword (but not > __float128) without having to use the -mfloat128 option on power7-power9 > systems. My question is in the TR that introduced _Float128, is there any > expectation that o

Re: [PATCH 00/19] cleanup of memory stats prototypes

On 07/27/2017 02:30 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders The preC++ way of passing information about the call site of a function was to use a macro that passed __file__, __LINE__, and __FUNCTION__ to a function with the same name with _stat appended to it. The way this is

Re: [PATCH 00/19] cleanup of memory stats prototypes

On Mon, Jul 31, 2017 at 02:56:40PM -0600, Martin Sebor wrote: > On 07/27/2017 02:30 AM, tbsaunde+...@tbsaunde.org wrote: > > From: Trevor Saunders > > > > The preC++ way of passing information about the call site of a function was > > to > > use a macro that passed __file__, __LINE__, and __FUNC

Re: [RFC] Remaining references of Java

On Tue, 25 Jul 2017, Richard Biener wrote: > > 2) fold-const.c: > > > > 1882/* The following code implements the floating point to integer > > 1883 conversion rules required by the Java Language Specification, > > 1884 that IEEE NaNs are mapped to zero and values that overflo

Re: C PATCH to detect clashing attributes (PR c/81544)

On Tue, 25 Jul 2017, Marek Polacek wrote: > PR c/81544 complaints that we aren't detecting clashing noreturn / > warn_unused_result attributes so this patch adds that checking. Martin > plans to do more systematic checking in this area but meanwhile we > might want to go with this. > > Bootstrap

[PATCH] i386: Update naked-1.c for PIC

For ia32 targets, -fPIC may generate call __x86.get_pc_thunk.ax ... __x86.get_pc_thunk.ax: movl(%esp), %eax ret We should check "ret" only for non-PIC or non-ia32 targets. OK for trunk? H.J. --- * gcc.target/i386/naked-1.c: Check "ret" only for non-PI

Re: [PATCH 00/19] cleanup of memory stats prototypes

On 07/31/2017 03:34 PM, Trevor Saunders wrote: On Mon, Jul 31, 2017 at 02:56:40PM -0600, Martin Sebor wrote: On 07/27/2017 02:30 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders The preC++ way of passing information about the call site of a function was to use a macro that passed __

Re: [PATCH 4/N] Recover GOTO predictor.

This patch breaks bootstrap on AIX and probably is a hidden bug on all targets. With the patch, libbacktrace/xcoff.c fails to compile with the error: /nasfarm/edelsohn/src/src/libbacktrace/xcoff.c: In function 'xcoff_add': /nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:822:13: error: 'incl' may b

  1   2   >