Hi,
this patch adds the IPA part of modref kill analysis. It just copies of
what local code did alrady. I did not manage to push out all patches
for modref I planned and I will wait for next stage1. This one however
I would like to push since it is quite simple and it makes no sense to
leave the
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> The problem here is with -mstrict-align, aarch64_expand_setmem needs
> to check the alginment of the mode to make sure we can use it for
> doing the stores.
>
> gcc/ChangeLog:
>
> PR target/103100
> * config/aarch64/aarch64.
Hi Uros,
on 2021/11/17 下午3:13, Uros Bizjak wrote:
> On Thu, Nov 11, 2021 at 12:25 PM Kewen Lin wrote:
>>
>> This patch is to fix some non-robust split conditions in some
>> define_insn_and_splits, to make each of them applied on top of
>> the corresponding condition for define_insn part, otherwis
On Wed, Nov 17, 2021 at 10:32 AM Jakub Jelinek wrote:
>
> Hi!
>
> If on &base->member the offset isn't constant or isn't zero and
> -fdelete-null-pointer-checks and not -fwrapv-pointer and base has a range
> that doesn't include NULL, we return the range of the base.
> Usually it isn't a big deal,
Oops, only just realised that I hadn't reviewed this.
Przemyslaw Wirkus writes:
> Hi,
> This patch is adding new V8DI mode which will be used with new Armv8.7-A
> LS64 extension intrinsics.
>
> Regtested on aarch64-elf and no issues.
>
> OK for master?
>
> gcc/ChangeLog:
>
> 2021-11-10 Przemysla
Hi!
On Tue, Nov 16, 2021 at 02:26:22PM -0600, Bill Schmidt wrote:
> Hi! I recently submitted [1] to make adjustments to test cases for the new
> builtins
> support, mostly due to error messages changing for consistency. Thanks for
> the
> previous review. I've reviewed the reasons for the cha
On Mon, Nov 08, 2021 at 08:50:41AM +0100, Gerald Pfeifer wrote:
> This is the first part I committed on Friday, the second will
> follow today.
Here is an alternative to the patch changing a file imported from
compiler-rt upstream, so that we don't need to cary a local patch for that
particular p
On 11/17/2021 2:16 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
if moving them from conditional contexts inside of a loop into unconditional
before the loop, but as the miscompilation of gimplify.c shows, we need to
treat p
On 16/11/2021 12:10, Richard Biener wrote:
On Fri, 12 Nov 2021, Andre Simoes Dias Vieira wrote:
On 12/11/2021 10:56, Richard Biener wrote:
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
Hi,
This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
optabs and mappings. It a
* Adhemerval Zanella via Libc-alpha:
> However the code is somewhat complex and I would like to have some feedback
> if gcc will be willing to accept this change (I assume it would require
> this code merge on glibc beforehand).
There's a long review queue on the GCC side due to the stage1 close.
On Wed, Nov 17, 2021 at 1:05 AM Uros Bizjak wrote:
>
> On Tue, Nov 16, 2021 at 7:20 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Add -mharden-sls= to mitigate against straight line speculation (SLS)
> > for function return and indirect branch by adding an INT3 instruction
> > after function return
Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to thunk
via r8-r15 registers when converting indirect call and jump to increase
the instruction length to 6, allowing the non-thunk form to be inlined.
gcc/
PR target/102952
* config/i386/i386.c (ix86_output_jmp_thu
On 11/17/21 6:44 AM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Nov 16, 2021 at 02:26:22PM -0600, Bill Schmidt wrote:
>> Hi! I recently submitted [1] to make adjustments to test cases for the new
>> builtins
>> support, mostly due to error messages changing for consistency. Thanks for
>> the
On Wed, Nov 17, 2021 at 1:10 AM Uros Bizjak wrote:
>
> On Tue, Nov 16, 2021 at 7:51 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to thunk
> > via r8-r15 registers when converting indirect call and jump to increase
> > the instruction
> -Original Message-
> From: Richard Sandiford
> Sent: 17 November 2021 10:08
> To: Przemyslaw Wirkus
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; Kyrylo Tkachov ;
> Marcus Shawcroft
> Subject: Re: [PATCH][GCC] aarch64: Add new vector mode V8DI
>
> Oops, only just realised tha
Hi Philipp:
Thanks for the patch, I like this approach, that can easily configure
different capabilities for each core :)
So there are only a few minor comments for this patch.
On Mon, Nov 15, 2021 at 5:49 AM Philipp Tomsich
wrote:
>
> From: Philipp Tomsich
>
> The Ventana VT1 core supports qu
Hi Philipp:
This patch set LGTM, feel free to commit once addressed those issues.
On Mon, Nov 15, 2021 at 5:48 AM Philipp Tomsich
wrote:
>
>
> This series provides support for the Ventana VT1 (a 4-way superscalar
> rv64gc_zba_zbb_zbc_zbs core) including support for the supported
> instruction fu
On Wed, Nov 17, 2021 at 2:46 PM H.J. Lu wrote:
>
> On Wed, Nov 17, 2021 at 1:05 AM Uros Bizjak wrote:
> >
> > On Tue, Nov 16, 2021 at 7:20 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > Add -mharden-sls= to mitigate against straight line speculation (SLS)
> > > for function return and indirec
Hi Philipp:
I would suggest add define_expand pattern for bswaphi2 rather than
changing expand_unop with following reasons:
- There is a comment above this change, and it also tried widen_bswap
after this if-block,
so I think this patch is kind of violating this comment.
/* HImode is speci
> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
> index c77b0322869..8480cf09294 100644
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -2131,6 +2131,14 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
> outer_code, int opno ATTRIBUTE_UN
>*total =
On Tue, Nov 16, 2021 at 05:32:00PM -0700, Martin Sebor via Gcc-patches wrote:
> -Warray-parameter and -Wvla-parameter assume that array bounds
> in function parameters are either constant integers or variable,
> but not something in between like a cast of a constant that's
> not recognized as an IN
Add -mharden-sls= to mitigate against straight line speculation (SLS)
for function return and indirect branch by adding an INT3 instruction
after function return and indirect branch.
gcc/
PR target/102952
* config/i386/i386-opts.h (harden_sls): New enum.
* config/i386/i386
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
> 4035e061706793849c68ae09bcb2e4b9580ab7b6..62adbc4cb6bbbe0c856f9fbe451aee08f2dea3b5
> 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -7345,6 +7345,14 @@ (define_insn "des
On Wed, Nov 17, 2021 at 6:08 AM Uros Bizjak wrote:
>
> On Wed, Nov 17, 2021 at 2:46 PM H.J. Lu wrote:
> >
> > On Wed, Nov 17, 2021 at 1:05 AM Uros Bizjak wrote:
> > >
> > > On Tue, Nov 16, 2021 at 7:20 PM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > Add -mharden-sls= to mitigate against
On Wed, Nov 17, 2021 at 4:35 PM H.J. Lu wrote:
>
> Add -mharden-sls= to mitigate against straight line speculation (SLS)
> for function return and indirect branch by adding an INT3 instruction
> after function return and indirect branch.
>
> gcc/
>
> PR target/102952
> * config/i38
On Wed, Nov 17, 2021 at 10:22:32AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Normal preprocessing, -fdirectives-only preprocessing before the Nathan's
> rewrite, and all other compilers I've tried on godbolt treat even \*/
> as end of a block comment, but the new -fdirectives-only handling doesn't.
>
Hi,
this patch series implements the re-work of the OpenACC "kernels"
implementation that has been announced at the GNU Tools Track of this
year's Linux Plumbers Conference; see
https://linuxplumbersconf.org/event/11/contributions/998/. The
central step is contained in the commit titled "openacc:
From: Sandra Loosemore
The Fortran front end presently linearizes accesses to
multi-dimensional arrays by combining the indices for the various
dimensions into a series of explicit multiplies and adds with
refactoring to allow CSE of invariant parts of the computation.
Unfortunately this represen
Extend dump output to make understanding why Graphite rejects to
include a loop in a SCoP easier (for GCC developers).
ChangeLog:
* graphite-scop-detection.c (scop_detection::can_represent_loop):
Output reason for failure to dump file.
(scop_detection::harmful_loop_in_regi
The OpenACC device lowering pass must run after the Graphite pass to
allow for the use of Graphite for automatic parallelization of kernels
regions in the future. Experimentation has shown that it is best,
performancewise, to run pass_oacc_device_lower together with the
related passes pass_oacc_loo
The SSA names for which this function gets used are always SCoP
parameters and hence "isl_id_for_parameter" is a better name. It also
explains the prefix "P_" for those names in the ISL representation.
gcc/ChangeLog:
* graphite-sese-to-poly.c (isl_id_for_ssa_name): Rename to ...
gcc/ChangeLog:
* graphite-sese-to-poly.c (build_poly_sr_1): Fix a typo and
a reference to a variable which does not exist.
* graphite-isl-ast-to-gimple.c (gsi_insert_earliest): Fix typo
in comment.
---
gcc/graphite-isl-ast-to-gimple.c | 2 +-
gcc/graphite-sese-
Move this function from tree-loop-distribution.c to tree-data-ref.c
and make it non-static to enable its use from other parts of GCC.
gcc/ChangeLog:
* tree-loop-distribution.c (data_ref_segment_size): Remove function.
(latch_dominated_by_data_ref): Likewise.
(compute_alias_
Graphite rejects a SCoP if it contains a pair of data references for
which it cannot determine statically if they may alias. This happens
very often, for instance in C code which does not use explicit
"restrict". This commit adds the possibility to analyze a SCoP
nevertheless and perform an alias
gcc/ChangeLog:
* graph.c (oacc_get_fn_attrib): New declaration.
(find_loop_location): New declaration.
(draw_cfg_nodes_for_loop): Print value of the
can_be_parallel flag at the top of loops in OpenACC
functions.
---
gcc/graph.c | 35
With the old "kernels" handling, unparallelized regions would
get executed with 1x1x1 partitioning even if the user provided
explicit num_gangs, num_workers clauses etc.
This commit restores this behavior by removing unused partitioning
after assigning the parallelism dimensions to loops.
gcc/Cha
Add some copies of tests to continue covering the old "parloops"-based
"kernels" implementation - until it gets removed from GCC - and
add further tests for the new Graphite-based implementation.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-fortran/parallel-loop-auto-reduction-2.f90:
Commit 89f4f339130c ("For 'OMP_CLAUSE' in 'dump_generic_node', dump
the whole OMP clause chain") changed the dumping behavior for
OMP_CLAUSEs. The old behavior is required for a follow-up
commit ("openacc: Add data optimization pass") that optimizes single
OMP_CLAUSEs.
gcc/ChangeLog:
* t
From: Andrew Stubbs
This commit adds the code generation for the runtime alias checks for
OpenACC loops that have been analyzed by Graphite. The runtime alias
check condition gets generated in Graphite. It is evaluated by the
code generated for the IFN_GOACC_LOOP internal function calls. If
ali
From: Andrew Stubbs
Address PR90591 "Avoid unnecessary data transfer out of OMP
construct", for simple (but common) cases.
This commit adds a pass that optimizes data mapping clauses.
Currently, it can optimize copy/map(tofrom) clauses involving scalars
to copyin/map(to) and further to "private"
This commit concerns loops in OpenACC "kernels" region that have been marked
up with an explicit "independent" clause by the user, but for which Graphite
found data dependences. A discussion on the private internal OpenACC mailing
list suggested that warning the user about the dependences woud be
The loop invariant motion pass correctly refuses to move statements
out of a loop if any other statement in the loop is unanalyzable. The
pass does not know how to handle the OpenACC internal function calls
which was not necessary until recently when the OpenACC device
lowering pass was moved to a
The additional dependences introduced by partial redundancy
elimination proper and by the code hoisting step of the pass very
often cause Graphite to fail on OpenACC functions. On the other hand,
the pass can also enable the analysis of OpenACC loops (cf. e.g. the
loop-auto-transfer-4.f90 testcase)
The default values of some parameters that restrict Graphite's
resource usage are too low for many OpenACC codes. Furthermore,
exceeding the limits does not alwas lead to user-visible diagnostic
messages.
This commit increases the parameter values on OpenACC functions. The
values were chosen to
The find_common_loop function is used in Graphite to obtain a common
super-loop of all loops inside a SCoP. The function is applied to the
loop of the destination block of the edge that leads into the SESE
region and the loop of the source block of the edge that exits the
region. The exit block i
It seems that the check that rejects loops without data references is
only included to avoid handling non-profitable loops. Including those
loops in Graphite's analysis enables more consistent diagnostic
messages in OpenACC "kernels" code and does not introduce any
testsuite regressions. If execu
On 11/16/21 7:05 PM, David Malcolm via Gcc-patches wrote:
This patch fixes -Wanalyzer-write-to-const so that it will complain
about attempts to write to functions, to labels.
It also "teaches" the analyzer about strchr, in that strchr can either
return a pointer into the input area (and thus -Wan
On Tue, Nov 16, 2021 at 11:12:35AM -0600, Bill Schmidt via Gcc-patches wrote:
> Hi! During a previous patch review, Segher asked that I provide better
> messages when builtins are unavailable because they require both a minimum
> CPU and the enablement of VSX instructions. This patch does just th
Jan's recent IPA work compromised two mips tests. This restores the
tests by disabling IPA analysis on the key function in both tests.
Committed to the trunk,
Jeffcommit c70546482388951b5c9c19cff002ee6ab920b7f5
Author: Jeff Law
Date: Wed Nov 17 11:55:50 2021 -0500
Fix two mips target
On 11/17/21 10:54 AM, Paul A. Clarke wrote:
> On Tue, Nov 16, 2021 at 11:12:35AM -0600, Bill Schmidt via Gcc-patches wrote:
>> Hi! During a previous patch review, Segher asked that I provide better
>> messages when builtins are unavailable because they require both a minimum
>> CPU and the enablem
(+ Ramana)
On Mon, 15 Nov 2021 at 19:04, Ard Biesheuvel wrote:
>
> Add support for accessing the stack canary value via the TLS register,
> so that multiple threads running in the same address space can use
> distinct canary values. This is intended for the Linux kernel running in
> SMP mode, whe
At present, for several reasons, it is not possible to switch
Darwin to use .cfi instructions for frame output.
When GCC uses .cfi_ instructions, the behaviour w.r.t frame
sections (for a target with unwind frames by defaults):
(no options ) .eh_frame
(-g ) .eh_frame
(-g -fno-unwind-tables -fno-a
Tested powerpc64le-linux, and briefly checkd on armv7hl-linux-gnueabi,
pushed to trunk.
The r179236 fix for std::type_info::operator== should also have been
applied to std::type_info::before. Otherwise two distinct types can
compare equivalent due to using a string comparison, when they should do
Tested powerpc64le-linux, pushed to trunk.
Clang diagnoses that the new constexpr std::string constructors are not
usable in constant expressions, because they start to write to members
of the union without setting an active member.
This adds a new helper function which returns the address of th
Tested powerpc64le-linux, pushed to trunk.
Several std::basic_string constructors dispatch to one of the
two-argument overloads of _M_construct, which then dispatches again to
_M_construct_aux to detect whether the arguments are iterators or not.
That then dispatches to one of _M_construct(size_t
Tested powerpc64le-linux, pushed to trunk.
Using placement-new isn't valid in constant expressions, so this
replaces it with std::construct_at (via the std::_Construct function
that is usable before C++20).
libstdc++-v3/ChangeLog:
* include/experimental/internet (address): Use std::_Con
On Wed, Nov 17, 2021 at 11:00:07AM -0600, Bill Schmidt via Gcc-patches wrote:
> On 11/17/21 10:54 AM, Paul A. Clarke wrote:
> > On Tue, Nov 16, 2021 at 11:12:35AM -0600, Bill Schmidt via Gcc-patches
> > wrote:
> >> Hi! During a previous patch review, Segher asked that I provide better
> >> messag
On 11/17/21 04:04, Matthias Kretz wrote:
On Wednesday, 17 November 2021 07:09:18 CET Jason Merrill wrote:
- if (CHECKING_P)
-SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, TREE_VEC_LENGTH (a));
+ SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, nondefault);
should have been
if (CHECKING_P || nondefault
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 pr
On 11/11/21 03:49, Matthias Kretz wrote:
On Wednesday, 8 September 2021 15:49:27 CET Matthias Kretz wrote:
On Wednesday, 8 September 2021 15:44:28 CEST Jason Merrill wrote:
On 9/8/21 5:37 AM, Matthias Kretz wrote:
On Tuesday, 7 September 2021 19:36:22 CEST Jason Merrill wrote:
case PAREN_EXPR
On 11/11/21 20:25, Patrick Palka wrote:
In the testcase below satisfaction misbehaves for f and g ultimately
because find_template_parameters fails to notice that the constraint
'val.x' depends on the template parameters of the class template.
In contrast, satisfaction works just fine for h.
The
On Wed, Nov 17, 2021 at 07:52:38AM -0600, Bill Schmidt wrote:
> >> - For int_128bit-runnable.c, I chose not to do gimple folding on the
> >> 128-bit
> >>comparison operations in the new implementation, because doing so
> >> results in
> >>bad code that splits things into two 64-bit value
On 11/17/21 11:31 AM, Jason Merrill wrote:
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement r
Introduce LEGACY_SSE_REGNO_P predicate to simplify a couple of places.
No functional changes.
2021-11-17 Uroš Bizjak
gcc/ChangeLog:
* config/i386/i386.h (LEGACY_SSE_REGNO_P): New predicate.
(SSE_REGNO_P): Use LEGACY_SSE_REGNO_P predicate.
* config/i386/i386.c (zero_all_vector_reg
[This is my first time trying my Rivos address on the lists, so sorry if
something goes off the rails.]
On Wed, 17 Nov 2021 06:05:04 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Hi Philipp:
Thanks for the patch, I like this approach, that can easily configure
different capabilities for each cor
On Wed, 17 Nov 2021 at 20:40, Palmer Dabbelt wrote:
> [This is my first time trying my Rivos address on the lists, so sorry if
> something goes off the rails.]
>
> On Wed, 17 Nov 2021 06:05:04 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> > Hi Philipp:
> >
> > Thanks for the patch, I like this ap
Before MPX was removed, "%!" was mapped to
case '!':
if (ix86_bnd_prefixed_insn_p (current_output_insn))
fputs ("bnd ", file);
return;
After CET was added and MPX was removed, "%!" was mapped to
case '!':
if (ix86_notrack_prefixed_insn_p (
On Wed, Nov 17, 2021 at 8:44 PM H.J. Lu wrote:
>
> Before MPX was removed, "%!" was mapped to
>
> case '!':
> if (ix86_bnd_prefixed_insn_p (current_output_insn))
> fputs ("bnd ", file);
> return;
>
> After CET was added and MPX was removed, "%!" was mapped t
Change indirect_thunks_used to HARD_REG_SET to avoid recalculations
of correct register numbers and allow usage of SET/TEST_HARD_REG_BIT
accessors.
2021-11-17 Uroš Bizjak
gcc/ChangeLog:
* config/i386/i386.c (indirect_thunks_used): Redefine as HARD_REG_SET.
(ix86_code_end): Use TEST_HA
On Wed, 17 Nov 2021, Jason Merrill wrote:
> On 11/11/21 20:25, Patrick Palka wrote:
> > In the testcase below satisfaction misbehaves for f and g ultimately
> > because find_template_parameters fails to notice that the constraint
> > 'val.x' depends on the template parameters of the class template
On Wed, Nov 17, 2021 at 11:45:02AM -0600, Paul A. Clarke wrote:
> I guess I'm being pedantic. "requires -mcpu=power8 and -mvsx" is not
> accurate from a user's point a view, as "-mcpu=power8" is sufficient,
> since "-mvsx" is enabled when "-mcpu=power8" is specified.
To be really pedantic, -mcpu=
On Wed, Nov 17, 2021 at 7:53 AM Uros Bizjak wrote:
>
> On Wed, Nov 17, 2021 at 4:35 PM H.J. Lu wrote:
> >
> > Add -mharden-sls= to mitigate against straight line speculation (SLS)
> > for function return and indirect branch by adding an INT3 instruction
> > after function return and indirect bran
On Wed, Nov 17, 2021 at 3:02 PM Segher Boessenkool
wrote:
>
> > It's not a strong objection, since specifying "-mno-vsx" should be
> > uncommon. (Right?) And, specifying "-mcpu=power8 -mvsx" is harmless.
>
> Maybe the warning could say "requires -mcpu=power8 (and -mvsx)"? Is
> that clearer, to
On Wed, Nov 17, 2021 at 9:02 PM H.J. Lu wrote:
>
> On Wed, Nov 17, 2021 at 7:53 AM Uros Bizjak wrote:
> >
> > On Wed, Nov 17, 2021 at 4:35 PM H.J. Lu wrote:
> > >
> > > Add -mharden-sls= to mitigate against straight line speculation (SLS)
> > > for function return and indirect branch by adding a
On Wed, Nov 17, 2021 at 02:00:02PM -0600, Segher Boessenkool wrote:
> On Wed, Nov 17, 2021 at 11:45:02AM -0600, Paul A. Clarke wrote:
> > I guess I'm being pedantic. "requires -mcpu=power8 and -mvsx" is not
> > accurate from a user's point a view, as "-mcpu=power8" is sufficient,
> > since "-mvsx"
On Tue, Nov 16, 2021 at 11:12:35AM -0600, Bill Schmidt wrote:
> Hi! During a previous patch review, Segher asked that I provide better
> messages when builtins are unavailable because they require both a minimum
> CPU and the enablement of VSX instructions. This patch does just that.
>
> Bootstr
Do you have testcases/reproducers demonstrating that the patch actually
fixes the issues you're describing?
Am 17.11.21 um 09:12 schrieb Bernhard Reutner-Fischer via Gcc-patches:
On Tue, 16 Nov 2021 21:46:32 +0100
Harald Anlauf via Fortran wrote:
Hi Bernhard,
I'm trying to understand your pa
On Wed, Nov 17, 2021 at 11:46 AM Uros Bizjak wrote:
>
> On Wed, Nov 17, 2021 at 8:44 PM H.J. Lu wrote:
> >
> > Before MPX was removed, "%!" was mapped to
> >
> > case '!':
> > if (ix86_bnd_prefixed_insn_p (current_output_insn))
> > fputs ("bnd ", file);
> >
On Wed, Nov 17, 2021 at 9:33 PM H.J. Lu wrote:
>
> On Wed, Nov 17, 2021 at 11:46 AM Uros Bizjak wrote:
> >
> > On Wed, Nov 17, 2021 at 8:44 PM H.J. Lu wrote:
> > >
> > > Before MPX was removed, "%!" was mapped to
> > >
> > > case '!':
> > > if (ix86_bnd_prefixed_insn_p (current
Hi! This patch is broken out of the previous patch for all the builtins test
suite adjustments. Here we have some slight changes in error messages due to
how the internals have changed between the old and new builtins methods.
For scalar-extract-exp-2.c we change:
error: '__builtin_vec_scalar_
This provides a spec to insert "-rpath DDD" for each DDD corresponding
to a compiler startfile directory. This allows a target to use @rpath
as the install path for libraries, and have the compiler provide the
necessary rpath to handle this.
gcc/ChangeLog:
* gcc.c (RUNPATH_OPTION): New.
We want to produce a situation where a default rpath can be added
to each executable (or dylib), but that can be overridden by any
specific rpath provided by the user.
gcc/ChangeLog:
* config.gcc: Include rpath.opt
* config/darwin-driver.c (darwin_driver_init): Detect cases
Allow the Ada runtimes to find GCC runtimes relative to their non-
standard install positions.
gcc/ada/
* gcc-interface/Makefile.in: Add @loader_path runpaths to the
libgnat and libgnarl shared library builds.
---
gcc/ada/gcc-interface/Makefile.in | 2 ++
1 file changed,
This is a fairly long explanation of the problems being addressed by
the patch set. Most of the changes are Darwin-specific - a change to
the libtool component allowing for this @rpath and some minor additions
to makefiles where libtool is not in use. At present, this seems pretty
specific to the
Recent Darwin versions place contraints on the use of run paths
specified in environment variables. This breaks some assumptions
in the GCC build.
This change allows the user to configure a Darwin build to use
'@rpath/libraryname.dylib' in library names and then to add an
embedded runpath to exec
Hi,
this patch fixes bug in streaming in modref access tree that now cause a failure
of gamess benchmark. The bug is quite old (present in GCC11 release) but it
needs quite interesting series of events to manifest. In particular
1) At lto time ISRA turns some parameters passed by reference to sca
Dear Fortranners,
as NULL() is not interoperable, we have to reject it.
Confirmed by NAG. Other compilers show "interesting behavior".
Obvious patch by Steve. Regtested on x86_64-pc-linux-gnu.
OK for mainline?
Thanks,
Harald
From 52a3ee53f0a12e897c4651fa8378e045653b9fd3 Mon Sep 17 00:00:00 2
On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote:
> Hi! This patch is broken out of the previous patch for all the builtins test
> suite adjustments. Here we have some slight changes in error messages due to
> how the internals have changed between the old and new builtins methods.
>
On Wed, Nov 17, 2021 at 12:09 PM Uros Bizjak wrote:
>
> On Wed, Nov 17, 2021 at 9:02 PM H.J. Lu wrote:
> >
> > On Wed, Nov 17, 2021 at 7:53 AM Uros Bizjak wrote:
> > >
> > > On Wed, Nov 17, 2021 at 4:35 PM H.J. Lu wrote:
> > > >
> > > > Add -mharden-sls= to mitigate against straight line specul
On Wed, 17 Nov 2021, Prathamesh Kulkarni via Gcc-patches wrote:
> More generally, would it be a good idea to provide attributes for
> mod/ref anaylsis ?
> So sth like:
> void foo(void) __attribute__((modifies(errno)));
> which would state that foo modifies errno, but neither reads nor
> modifies a
This flags rich_locations associated with -Wbidi-chars= so that
non-ASCII bytes will be escaped when printing the source lines
(using the diagnostics support I added in
r12-4825-gbd5e882cf6e0def3dd1bc106075d59a303fe0d1e).
In particular, this ensures that the printed source lines will
be pure ASCII
This patch converts the bidi::vec to use a struct so that we can
capture location_t values for the bidirectional control characters.
Before:
Wbidi-chars-1.c: In function ‘main’:
Wbidi-chars-1.c:6:43: warning: unpaired UTF-8 bidirectional control character
detected [-Wbidi-chars=]
6 |
On Wed, 17 Nov 2021, Iain Sandoe via Gcc-patches wrote:
> * libtool.m4: Add 'enable-darwin-at-runpath'. Act on the
> enable flag to alter Darwin libraries to use @rpath names.
To confirm: has this been sent to upstream libtool (which has recently
acquired a new maintainer, so hopef
On Wednesday, 17 November 2021 19:25:46 CET Jason Merrill wrote:
> On 11/17/21 04:04, Matthias Kretz wrote:
> > On Wednesday, 17 November 2021 07:09:18 CET Jason Merrill wrote:
> >>> - if (CHECKING_P)
> >>> -SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, TREE_VEC_LENGTH (a));
> >>> + SET_NON_DEFAULT
On Wed, Nov 17, 2021 at 05:45:15PM -0500, David Malcolm wrote:
> This patch converts the bidi::vec to use a struct so that we can
> capture location_t values for the bidirectional control characters.
Thanks for these improvements. I noticed a few nits, but nothing that
needs to be fixed immediate
On 11/17/21 3:32 PM, Segher Boessenkool wrote:
> On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote:
>> Hi! This patch is broken out of the previous patch for all the builtins test
>> suite adjustments. Here we have some slight changes in error messages due to
>> how the internals hav
> On 17 Nov 2021, at 22:50, Joseph Myers wrote:
>
> On Wed, 17 Nov 2021, Iain Sandoe via Gcc-patches wrote:
>
>> * libtool.m4: Add 'enable-darwin-at-runpath'. Act on the
>> enable flag to alter Darwin libraries to use @rpath names.
>
> To confirm: has this been sent to upstream l
From: Andrew Pinski
Currently we fold (type) X op CST into (type) (X op ((type-x) CST)) when the
conversion widens
but not when the conversion is a nop. For the same reason why we move the
widening conversion
(the possibility of removing an extra conversion), we should do the same if the
conve
Hi,
As asked for, this adds the documentation note in install.texi about the
upcoming bootstrap requirements.
Obviously this will be applied alongside the patch posted previously:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582917.html
Final batch of testing before proceeding has tak
On 11/17/21 12:21 PM, Martin Sebor wrote:
On 11/17/21 11:31 AM, Jason Merrill wrote:
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While r
1 - 100 of 122 matches
Mail list logo
