Hi!
The -gsplit-dwarf changes came a few months after .debug_macro
and the r0-120109 changes just changed the 2nd operand of
DW_MACRO_GNU_{define,undef}_indirect from the usual .debug_str
section offset argument to leb128 index into .debug_str_offsets
without changing the opcodes.
DWARF5 standard
Hi!
The Wstringop-overflow-25.c testcase doesn't emit one of the expected
warnings on targets that don't do short curcuiting due to target costs
(or e.g. with --param=logical-op-non-short-circuit=0 on all targets).
The problem is that only reassoc2 optimizes:
_49 ={v} unsigned_value_source;
i
On Tue, 2 Mar 2021, Jakub Jelinek wrote:
> Hi!
>
> The Wstringop-overflow-25.c testcase doesn't emit one of the expected
> warnings on targets that don't do short curcuiting due to target costs
> (or e.g. with --param=logical-op-non-short-circuit=0 on all targets).
>
> The problem is that only r
Hi Matthias:
Sure, backported to gcc 10 branch, let's wait 10.3 :)
On Mon, Mar 1, 2021 at 4:17 PM Matthias Klose wrote:
>
> On 7/8/20 9:59 PM, Jim Wilson wrote:
> > On Tue, Jul 7, 2020 at 2:52 AM Kito Cheng wrote:
> >> gcc/ChangeLog:
> >> * gcc/config/riscv/riscv.md (): New.
> >>
gcc/testsuite/ChangeLog:
* gcc.target/s390/mul-signed-overflow-1.c: Run only on z14.
* gcc.target/s390/mul-signed-overflow-2.c: Run only on z14.
---
gcc/testsuite/gcc.target/s390/mul-signed-overflow-1.c | 2 +-
gcc/testsuite/gcc.target/s390/mul-signed-overflow-2.c | 2 +-
2 files
On 3/1/21 8:58 PM, Jason Merrill wrote:
On 3/1/21 11:59 AM, Martin Liška wrote:
On 3/1/21 5:36 PM, Jason Merrill wrote:
On 3/1/21 7:43 AM, Martin Liška wrote:
On 2/22/21 11:53 PM, Jason Merrill wrote:
The problem seems to be with the handling of local decls. If
DECL_LOCAL_DECL_P, you need t
The issue is reported by Clang:
warning: private field 'm_engine' is not used [-Wunused-private-field]
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (diagnostic_manager::emit_saved_diagnostics):
Do not pass engine.
---
gcc/analyzer/diagnostic-manager.cc | 6 +-
1 file cha
On Fri, Jan 22, 2021 at 12:39 AM Martin Sebor via Gcc-patches
wrote:
>
> The hack I put in compute_objsize() last January for pr93200 isn't
> quite correct. It happened to suppress the false positive there
> but, due to what looks like a thinko on my part, not in some other
> test cases involving
On Mon, Mar 1, 2021 at 7:32 PM Martin Sebor via Gcc-patches
wrote:
>
> The documentation change made for pr83023 - branch probabilities
> pessimize malloc, introduced an ambiguity into the description of
> attribute malloc pointed out in pr99295.
>
> The change suggests that GCC assumes that most
Prepare GCC for a future architecture extension.
gcc/ChangeLog:
* common/config/s390/s390-common.c (processor_flags_table): New entry.
* config.gcc: Enable arch14 for --with-arch and --with-tune.
* config/s390/driver-native.c (s390_host_detect_local_cpu): Pick
arch
This adds support for 5 new builtins.
gcc/ChangeLog:
* config/s390/s390-builtin-types.def (BT_FN_V4SF_V8HI_UINT): New
builtin signature.
(BT_FN_V8HI_V8HI_UINT): Likewise.
(BT_FN_V8HI_V4SF_V4SF_UINT): Likewise.
* config/s390/s390-builtins.def (B_NNPA): New m
On Feb 26, 2021, Segher Boessenkool wrote:
> On Fri, Feb 26, 2021 at 12:31:16PM -0500, David Edelsohn wrote:
>> On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva wrote:
>> >
>> > This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
>> > tests. Tested on x86_64-linux-gnu, and on the
This series contains updated parts of the patch series that was previously
sent upstream in November 2019:
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534547.html
The purpose of the series is to enable multiple workers for OpenACC
(workers being one of the dimensions of parallelism
Enabling worker-partitioning support in the middle end (for AMD GCN)
reveals several bugs in existing tests relating to async usage.
This patch fixes those up.
Tested with offloading to AMD GCN. OK for stage 1? (Or now?)
Julian
2021-03-02 Julian Brown
libgomp/
* testsuite/libgomp.oac
A version of this patch was previously posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534553.html
This patch implements worker-partitioning support in the middle end,
by rewriting gimple. The OpenACC execution model requires that code
can run in either "worker single" mode
This patch enables worker-partitioning support via gimple rewriting for
AMD GCN. Older (and currently unused) parts of this support are already
present in the AMD GCN backend: those vestigial parts are enabled or
updated, as appropriate.
I can probably self-approve this -- I will commit if/when th
A version of this patch was previously posted for mainline here:
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534552.html
Reference-type private variables or reference-type variables used as
reduction targets do not work well with the scheme to implement worker
partitioning on AMD GC
On Sun, Feb 14, 2021 at 11:27 AM Stefan Schulze Frielinghaus
wrote:
>
> On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> > On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> > >
> > > This patch adds support for recognizing loops which mimic t
Previous patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564976.html
was reverted by Catherine when I was away, due to regressions in mapping
array members. The fix appears to be a re-placement of
finish_non_static_data_member()
inside handle_omp_array_sections().
Tested and comm
On Fri, 2021-02-19 at 18:04 +0100, Mark Wielaard wrote:
> * gcc-11/changes.html (General Improvements): Add a section on
> the DWARF version 5 default.
Ping. OK to commit?
> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index 6a47b0b8..9734eee8 100644
> --- a/
Alex,
dejagnu should not report that sqrt_insn is available on PowerPC in
confirmations when it is not. The correct fix and the one suggested
by Richard and Segher is to test for the availability of sqrt, not to
assume that it exists in PowerPC.
The test should not explicitly add -mpowerpc-gpopt
On Tue, 2021-03-02 at 11:38 +0100, Martin Liška wrote:
> The issue is reported by Clang:
>
> warning: private field 'm_engine' is not used [-Wunused-private-
> field]
Thanks; FWIW I think I removed the usage in
a505fad4dd4d93b6d642995d7df320aa40949568.
LGTM
Dave
On 3/2/21 2:38 PM, David Malcolm wrote:
On Tue, 2021-03-02 at 11:38 +0100, Martin Liška wrote:
The issue is reported by Clang:
warning: private field 'm_engine' is not used [-Wunused-private-
field]
Thanks; FWIW I think I removed the usage in
a505fad4dd4d93b6d642995d7df320aa40949568.
Good!
Alexandre Oliva writes:
> On Feb 26, 2021, Segher Boessenkool wrote:
>
>> On Fri, Feb 26, 2021 at 12:31:16PM -0500, David Edelsohn wrote:
>>> On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva wrote:
>>> >
>>> > This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
>>> > tests. Teste
On 3/1/21 6:11 PM, Martin Sebor wrote:
On 2/24/21 5:35 PM, Jason Merrill wrote:
On 2/23/21 6:07 PM, Martin Sebor wrote:
On 2/23/21 2:52 PM, Jason Merrill wrote:
On 2/23/21 11:02 AM, Martin Sebor wrote:
[CC Jason for any further comments/clarification]
On 2/9/21 10:49 AM, Martin Sebor wrote:
On Tue, Mar 2, 2021 at 8:48 AM Richard Sandiford
wrote:
>
> Alexandre Oliva writes:
> > On Feb 26, 2021, Segher Boessenkool wrote:
> >
> >> On Fri, Feb 26, 2021 at 12:31:16PM -0500, David Edelsohn wrote:
> >>> On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva
> >>> wrote:
> >>> >
> >>> > This p
This patch fixes an OpenMP performance issue on NVPTX.
The problem is that it deallocates the stack memory when it shouldn't,
forcing the GOMP_OFFLOAD_run function to allocate the stack space again,
before every kernel launch.
The memory is only meant to be deallocated when a data allocation
On 3/2/21 5:56 AM, Mark Wielaard wrote:
> On Fri, 2021-02-19 at 18:04 +0100, Mark Wielaard wrote:
>> * gcc-11/changes.html (General Improvements): Add a section on
>> the DWARF version 5 default.
> Ping. OK to commit?
OK. Sorry for the delay.
jeff
On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
> Ping?
>
> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
> wrote:
>>
>> Ping?
>> I guess that's obvious enough?
>>
>> On Wed, 27 Jan 2021 at 10:03, Christophe Lyon
>> wrote:
>>>
>>> Depending on how the toolchain is configured or how t
On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
> On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
>> Ping?
>>
>> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
>> wrote:
>>>
>>> Ping?
>>> I guess that's obvious enough?
>>>
>>> On Wed, 27 Jan 2021 at 10:03, Christophe Lyon
>
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:58 PM, Patrick Palka wrote:
> > This patch mostly performs some straightforward refactoring:
> >
> >- Renamed satisfy_constraint to satisfy_normalized_constraints
> >- Renamed the three-parameter version of satisfy_constraint_expres
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:59 PM, Patrick Palka wrote:
> > This folds the diagnose_requires_expr routines into the corresponding
> > tsubst_requires_expr ones. This is achieved by making the latter
> > routines take a sat_info instead of a subst_info, and assigning t
On 3/2/21 2:06 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The -gsplit-dwarf changes came a few months after .debug_macro
> and the r0-120109 changes just changed the 2nd operand of
> DW_MACRO_GNU_{define,undef}_indirect from the usual .debug_str
> section offset argument to leb128 index
On 3/1/21 1:39 AM, Richard Biener wrote:
> The default diagnostic tree printer relies on dump_generic_node which
> for some reason manages to clobber the diagnostic pretty-printer state
> so we see garbled diagnostics like
>
> /home/rguenther/src/trunk/gcc/calls.c: In function 'expand_call':
> D
This is a regression present on the mainline and 10 branch, where we fail
to make the bounds explicit for the return value of a function returning
an unconstrained array of a limited record type.
Tested on x86-64/Linux, applied on mainline and 10 branch.
2021-03-02 Eric Botcazou
PR a
On 3/2/21 5:34 AM, Martin Liška wrote:
On 3/1/21 8:58 PM, Jason Merrill wrote:
On 3/1/21 11:59 AM, Martin Liška wrote:
On 3/1/21 5:36 PM, Jason Merrill wrote:
On 3/1/21 7:43 AM, Martin Liška wrote:
On 2/22/21 11:53 PM, Jason Merrill wrote:
The problem seems to be with the handling of local de
On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
wrote:
>
> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
> > On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
> >> Ping?
> >>
> >> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
> >> wrote:
> >>>
> >>> Ping?
> >>> I guess that
On 02/03/2021 18:10, Christophe Lyon wrote:
> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
> wrote:
>>
>> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
>>> On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
Ping?
On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> On 02/03/2021 18:10, Christophe Lyon wrote:
>> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
>> wrote:
>>>
>>> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote
On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
wrote:
>
> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> > On 02/03/2021 18:10, Christophe Lyon wrote:
> >> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
> >> wrote:
> >>>
> >>> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wr
On Tue, Mar 02, 2021 at 08:13:51AM -0300, Alexandre Oliva wrote:
> On Feb 26, 2021, Segher Boessenkool wrote:
> > You should essentially never use -mpowerpc-gpopt, but instead use a
> > -mcpu= that has it. You also of course whould not do that in run tests
> > if the cpu does not support those in
On Tue, 2021-03-02 at 07:09 +, brian.sobulefsky wrote:
> Hi,
>
> It may not be worth altering at this point, but it seems like it
> would leave less
> bugs open if all the constraints go in as "closed" ranges and all
> evals are
> translated to closed intervals. So, if (idx > 0) and if (idx >=
On 3/2/21 3:39 AM, Richard Biener wrote:
On Fri, Jan 22, 2021 at 12:39 AM Martin Sebor via Gcc-patches
wrote:
The hack I put in compute_objsize() last January for pr93200 isn't
quite correct. It happened to suppress the false positive there
but, due to what looks like a thinko on my part, not
On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
On 3/1/21 1:39 AM, Richard Biener wrote:
The default diagnostic tree printer relies on dump_generic_node which
for some reason manages to clobber the diagnostic pretty-printer state
so we see garbled diagnostics like
/home/rguenther/src/trunk
In PR 99276 a translator points out malformed warning message newly
introduced into GCC 11. In r11-7460 I have committed the attached
patch to remove the stray text.
Martin
commit e7ca37649e4f322e7512c6d11813992c61b0a4b3
Author: Martin Sebor
Date: Tue Mar 2 13:37:01 2021 -0700
PR middle-
PR c/99323 describes an ICE due to a failed assertion deep inside the
fix-it printing machinery, where the fix-it hints on one line have not
been properly sorted in layout's constructor.
The underlying issue occurs when multiple fix-it hints affect a line
wider that LINE_MAP_MAX_COLUMN_NUMBER, whe
On Mon, Mar 01, 2021 at 05:15:44PM -0600, Segher Boessenkool wrote:
> On Mon, Mar 01, 2021 at 12:18:52PM -0500, Michael Meissner wrote:
> > The _sprintfkf.c file was including stdio.h to get the definition of
> > sprintf.
>
> (declaration of)
>
> > This patch modifies this so that stdio.h is not
On 3/1/21 5:11 PM, Anthony Sharp wrote:
Hi all,
Here is the patch as promised. Regression tested on the c++ side and
everything seems okay. Compiles fine.
Sounds good, though strip_using_decl (parent_field) may be overloaded if
the using-decl brings in multiple functions with that nam
This libbacktrace patch passes -1 to the error callback function for
unknown DWARF versions. This makes users of libbacktrace treat DWARF
versions that libbacktrace does not support as though no debug
information were available. This fixes PR 98818. Bootstrapped and
ran libbacktrace tests on x86
On Mon, Mar 01, 2021 at 09:29:19PM -0500, Jason Merrill via Gcc-patches wrote:
> On 3/1/21 7:59 PM, Marek Polacek wrote:
> > On Mon, Mar 01, 2021 at 03:08:58PM -0500, Jason Merrill wrote:
> > > On 3/1/21 2:54 PM, Marek Polacek wrote:
> > > > On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill v
On Tue, Mar 02, 2021 at 04:25:33PM -0500, Michael Meissner wrote:
> On Mon, Mar 01, 2021 at 05:15:44PM -0600, Segher Boessenkool wrote:
> > On Mon, Mar 01, 2021 at 12:18:52PM -0500, Michael Meissner wrote:
> > > The _sprintfkf.c file was including stdio.h to get the definition of
> > > sprintf.
>
This patch by Michael Matloob fixes the Go frontend to permit
//go:embed comments in files that do
import _ "embed"
The embed spec allows for //go:embed to be used in files that
underscore-import package "embed". This is useful for embeds to
[]byte and string vars because the embed.FS type ma
Ping3
On 2/18/21 2:31 PM, Pat Haugen via Gcc-patches wrote:
> Ping2.
>
> On 1/26/21 11:30 AM, Pat Haugen via Gcc-patches wrote:
>> Ping.
>>
>> On 11/13/20 4:04 PM, Pat Haugen via Gcc-patches wrote:
>>> Add Power10 scheduling description.
>>>
>>> This patch adds the Power10 scheduling description.
On 2/26/21 8:24 AM, Mikael Pettersson via Gcc-patches wrote:
> On Fri, Feb 5, 2021 at 2:59 PM Arnaud Charlet wrote:
We'd rather not have PR references in the source files, so please remove it
(it will be there as part of the commit log and git annotate).
OK with the comment
On 2/26/21 5:02 AM, Julian Brown wrote:
> It's possible for an aggregate to be declared in a non-default address
> space, but the tree pretty-printer doesn't currently show that address
> space in dumps, which can be confusing. This patch adds printing of
> "" markers for aggregates in non-defa
Ping3
On 2/18/21 2:30 PM, Pat Haugen via Gcc-patches wrote:
> Ping2
>
> On 1/26/21 11:27 AM, Pat Haugen via Gcc-patches wrote:
>> Ping
>>
>> On 12/8/20 3:46 PM, Pat Haugen via Gcc-patches wrote:
>>> Update size attribute for Power10.
>>>
>>>
>>> This patch was broken out from my larger patch to u
On 2/24/21 11:59 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The r10-2806 change regressed following testcases, instead of doing
> int -> unsigned long sign-extension once and then add 8, 16, ... 56 to it
> for each of the memory access, it adds 8, 16, ... 56 in int mode and then
> sign e
On 2/24/21 10:11 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> The outputs.exp tests check what temporary files are created
> and left behind with e.g. -save-temps.
>
> Additional files are created in presence of @file option.
> Adding an -I or -L option causes *another* temporary file to
> ap
On 2/24/21 10:17 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> The gcc.misc-tests/outputs.exp tests can take some effort to
> digest.
>
> Navigating and debugging causes for failing tests here isn't
> helped by the existence of tests with duplicate names.
> Let's stop that from happening. Thi
Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. Ok for master?
Commit efb6bc55a93a ("fwprop: Allow (subreg (mem)) simplifications")
introduced a check that was supposed to look at the propagated def's
number of uses. It uses insn_info::num_uses (
On 2/24/21 5:08 PM, Jason Merrill wrote:
> On 2/16/21 1:52 PM, Jeff Law wrote:
>>
>>
>> On 2/11/21 10:18 PM, Jason Merrill via Gcc-patches wrote:
>>> The patch for PR92372 made us start warning about a flatten
>>> attribute on an
>>> alias. But in the case of C++ 'tor base/complete variants, th
> From: Jeff Law
> Date: Tue, 2 Mar 2021 23:39:27 +0100
> received-spf: None (smtp1.axis.com: no sender authenticity information
> available from domain of postmas...@mail-il1-f172.google.com) identity=helo;
> client-ip=209.85.166.172; receiver=smtp1.axis.com;
> envelope-from="jeffreya...@g
On 3/2/21 11:25 AM, Patrick Palka wrote:
On Mon, 1 Mar 2021, Jason Merrill wrote:
On 2/28/21 12:58 PM, Patrick Palka wrote:
This patch mostly performs some straightforward refactoring:
- Renamed satisfy_constraint to satisfy_normalized_constraints
- Renamed the three-parameter version
mul-signed-overflow-*.c execution tests fail on z13, because they
contain z14-specific instructions. Fix by requiring s390_z14_hw
target.
gcc/testsuite/ChangeLog:
* gcc.target/s390/mul-signed-overflow-1.c: Run only on z14+.
* gcc.target/s390/mul-signed-overflow-2.c: Likewise.
---
On 2/27/21 3:21 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As mentioned in the PR, riscv* only supports .uleb128 with constant
> arguments, doesn't support difference of two labels because of aggressive
> linker relaxations. But I bet various other targets, especially those not
> using
On 3/2/21 11:45 AM, Patrick Palka wrote:
On Mon, 1 Mar 2021, Jason Merrill wrote:
On 2/28/21 12:59 PM, Patrick Palka wrote:
This folds the diagnose_requires_expr routines into the corresponding
tsubst_requires_expr ones. This is achieved by making the latter
routines take a sat_info instead o
Hi!
build_va_arg calls the middle-end mark_addressable, which e.g. requires that
cfun is non-NULL. The following patch calls instead
c_common_mark_addressable_vec
which is the c-family variant similarly to the FE c_mark_addressable and
cxx_mark_addressable, except that it doesn't error on addres
Hi!
P0145R3 added
"However, the operands are sequenced in the order prescribed for the built-in
operator" rule for overloaded operator calls when using the operator syntax.
op_is_ordered follows that, but added just the overloaded operators
added in that paper. &&, || and comma operators had rule
On 2/18/21 3:30 PM, Martin Sebor via Gcc-patches wrote:
> The "writing one too many bytes" form of -Wstringop-overflow is
> designed to trigger for strcpy(d, s) calls into allocated destinations
> whose size is the result of (or depends on) strlen(s). But the warning
> is in code that's also ca
I have been kicking these sorts of ideas around ever since I came to understand
that
the second "UNKNOWN" in the for loop that originally started this was due to
the state
merge as we loop. For now, and I don't mean this disrespectfully because it is
very
hard to get right, the whole issue of me
On 2/17/21 5:02 AM, Richard Sandiford wrote:
> Xi Ruoyao via Gcc-patches writes:
>> I can't understand the comment either. To me it looks like it's
>> possible to
>> remove this "if (MSA_SUPPORTED_P (mode)) return 0;"
> I think the point is that the MSA loads and stores only have a
Hi!
As the testcase shows, the
(define_peephole2
[(set (match_operand 0 "sse_reg_operand")
(match_operand 1 "sse_reg_operand"))
(set (match_dup 0)
(match_operator 3 "commutative_operator"
[(match_dup 0)
(match_operand 2 "memory_operand")]))]
peephole2 can
On 2/16/21 1:13 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> fixup_partitions sometimes changes some basic blocks from hot partition to
> cold partition, in particular if after unreachable block removal or other
> optimizations a hot partition block is dominated by cold partition block(s).
This patch adds missing periods to the symbol name for TLS helper functions.
Bootstrapped on powerpc-ibm-aix7.2.2.0.
Thanks, David
* config/rs6000/rs6000.md (tls_get_tpointer_internal): Prepend
period to symbol name.
(tls_get_addr_internal): Same.
diff --
Hello,
I would like to ping the following patch:
Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562898.html
It is needed for the following regression fix:
IBM Z: Fix usage of "f" constraint with long doubles
https://gcc.gnu.org/pipe
On Tue, Nov 17, 2020 at 10:31:42PM -0600, will schmidt wrote:
> > 2020-11-13 Pat Haugen
> >
> > gcc/
> > * config/rs6000/rs6000.c (struct processor_costs): New.
>
> Should that add/reference the "power10_cost" structure itself?
Yup.
> +;; Copyright (C) 2020-2020 Free Software Foundation,
On Wed, Nov 18, 2020 at 03:10:21PM -0600, Pat Haugen wrote:
> On 11/17/20 10:31 PM, will schmidt wrote:
> >> +(define_cpu_unit "fp_div0_power10,fp_div1_power10,fp_div2_power10,
> >> +fp_div3_power10" "power10div")
> >
> > The spacing catches my eye, I'd want to add spaces around those
On Wed, 3 Mar 2021, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> build_va_arg calls the middle-end mark_addressable, which e.g. requires that
> cfun is non-NULL. The following patch calls instead
> c_common_mark_addressable_vec
> which is the c-family variant similarly to the FE c_mark_addres
On 2021/2/25 14:33, Xionghu Luo via Gcc-patches wrote:
>
>
> On 2021/2/25 00:57, Segher Boessenkool wrote:
>> Hi!
>>
>> On Wed, Feb 24, 2021 at 09:06:24AM +0800, Xionghu Luo wrote:
>>> vec_insert defines the element argument type to be signed int by ELFv2
>>> ABI, When expanding a vector with a
Hi!
On Fri, Nov 13, 2020 at 04:04:30PM -0600, Pat Haugen wrote:
> gcc/
> * config/rs6000/rs6000.c (struct processor_costs): New.
Will already commented on this; please consider his comments :-)
> (rs6000_option_override_internal): Set Power10 costs.
> (rs6000_issue_rate): Set P
On Tue, 2021-03-02 at 23:14 +, brian.sobulefsky wrote:
> I have been kicking these sorts of ideas around ever since I came to
> understand that
> the second "UNKNOWN" in the for loop that originally started this was
> due to the state
> merge as we loop. For now, and I don't mean this disrespec
On 3/2/21 6:40 PM, David Malcolm via Gcc-patches wrote:
>
>> My devil's advocate position would be if the analyzer raises
>> exception on
>> any possible overflow, will that overwhelm the user with false
>> positives?
> Presumably by "raise exception" you mean "issue a diagnostic and stop
> anal
This libbacktrace patch stops special casing file 0. It's no longer
necessary as for DWARF 5 support we now set up filename 0 in all
cases. Bootstrapped and ran libbacktrace and Go tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
* dwarf.c (read_line_program): Don't special case file 0
Wow! I wasn't expecting that to work. Obviously we know that there is currently
no handler for binop_svalue in the constraints so I would have to watch it run
with
state merging disabled to see how it is managing the unroll. The fact that
merging
breaks it is indicative of what we are saying tho
Agreed too. Generic "error on overflow" is not an answer, and ignoring overflow
is not an answer either because flagging faulty memory allocations is an
important feature.
Brian
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Tuesday, March 2, 2021 6:09 PM, Jeff Law wrot
On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
> mul-signed-overflow-*.c execution tests fail on z13, because they
> contain z14-specific instructions. Fix by requiring s390_z14_hw
> target.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/mul-signed-overflow-1.c: Run only on z14+.
>
On Wed, Mar 3, 2021 at 12:29 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the testcase shows, the
> (define_peephole2
> [(set (match_operand 0 "sse_reg_operand")
> (match_operand 1 "sse_reg_operand"))
>(set (match_dup 0)
> (match_operator 3 "commutative_operator"
> [(matc
On Tue, 2 Mar 2021, Martin Sebor wrote:
> On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> >
> >
> > On 3/1/21 1:39 AM, Richard Biener wrote:
> >> The default diagnostic tree printer relies on dump_generic_node which
> >> for some reason manages to clobber the diagnostic pretty-printer state
88 matches
Mail list logo
