On Tue, Jan 24, 2023 at 10:54 PM Siddhesh Poyarekar wrote:
>
> Use the offset in TREE_OPERAND(component_ref, 2) when available instead
> of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF.
>
> OK for gcc 13 and gcc 12?
>
> Co-authored-by: Jakub Jelinek
>
> gcc/ChangeLog:
>
>
Hi Suwa-san,
On Mon, Jan 23, 2023 at 7:43 PM Takayuki 'January June' Suwa
wrote:
>
> Register-register move instructions that can be easily seen as
> unnecessary by the human eye may remain in the compiled result.
> For example:
>
> /* example */
> double test(double a, double b) {
> return __b
Tested x86_64-linux. Pushed to trunk.
-- >8 --
On some systems /etc/localtime is a tzfile, not a symlink to one. We
cannot use it to determine the current time zone in that case. See if
/etc/sysconfig/clock sets the variable DEFAULT_TIMEZONE instead.
libstdc++-v3/ChangeLog:
PR libstdc++
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In order for std::make_from_tuple to work with tuple-like types, the
overloads of std::get for those types must have been declared before the
definition of std::make_from_tuple. That means we need to include the
definition of std::ranges::subrange in
Hi!
Before the P1169R4 changes, operator () of a lambda was
always a method, so it was fine to pass method_p = 1 unconditionally,
but it isn't always the case, so this patch adds a check for whether
it is a method or nor.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2023-
On Mon, Jan 23, 2023 at 10:26:14PM -0500, Jason Merrill via Gcc-patches wrote:
> * g++.dg/init/new51.C: New test.
The test fails on targets where size_t is not unsigned long
due to extra diagnostics.
As the testcase is tested in C++98 too, I'm not using decltype (sizeof 0)
but __SIZE_TYPE__
Ping.
On Fri, Jan 13, 2023 at 06:22:38PM -0500, Marek Polacek wrote:
> On Sat, Dec 03, 2022 at 02:58:16PM -0500, Jason Merrill wrote:
> > On 12/2/22 18:58, Marek Polacek wrote:
> > > On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote:
> > > > On 11/18/22 18:52, Marek Polacek wrote:
> >
On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
> On 1/19/23 21:03, Marek Polacek wrote:
> > On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:
> > > On 1/18/23 20:13, Marek Polacek wrote:
> > > > On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:
> > > > > On
Hi Suwa-san,
On Mon, Jan 23, 2023 at 7:43 PM Takayuki 'January June' Suwa
wrote:
>
> In the case of the CALL0 ABI, values that must be retained before and
> after function calls are placed in the callee-saved registers (A12
> through A15) and referenced later. However, it is often the case that
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Since r11-2095 we pass flags to cp_lexer_get_preprocessor_token, and
cp_lexer_new_main passes C_LEX_STRING_NO_JOIN when lexing most of the
translation unit, but doesn't do that for the very first token; as a
result, if the first token is a s
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the new
lamba op(). This is not what we want for a C++23 static op(), but since we
also use that METHOD_TYPE to communicate the closure type down to
tsubst_function_decl, l
On Tue, Jan 24, 2023 at 04:54:00PM -0500, Siddhesh Poyarekar wrote:
> Use the offset in TREE_OPERAND(component_ref, 2) when available instead
> of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF.
>
> OK for gcc 13 and gcc 12?
Ok for trunk, I'd wait a week or two with the backp
Use the offset in TREE_OPERAND(component_ref, 2) when available instead
of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF.
OK for gcc 13 and gcc 12?
Co-authored-by: Jakub Jelinek
gcc/ChangeLog:
PR tree-optimization/108522
* tree-object-size.cc (compute_obje
Dear all,
when checking expressions for array sections, we need to ensure
that these use only type INTEGER. However, it does not make sense
to generate an internal error when encountering wrong types,
but rather take the ordinary route of error recovery.
The initial fix was provided by Steve.
W
On Thu, Jan 19, 2023 at 7:33 PM Takayuki 'January June' Suwa
wrote:
>
> In the previously posted patch
> "xtensa: Make complex hard register clobber elimination more robust and
> accurate",
> the check code for insns that refer to the [DS]Cmode hard register before
> it is overwritten after it is
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 265a749f290f7c6adc9a3aaa9c585b498a8a38ea
Author: Vladimir N. Makarov
Date: Tue Jan 24 16:10:59 2023 -0500
LRA: Alwa
Am 24.01.2023 um 17:52 schrieb Eli Zaretskii:
From: Ian Lance Taylor
Date: Tue, 24 Jan 2023 06:35:21 -0800
Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
On Windows it seems that MAX_PATH is not
a true limit, as an extended length path may be up to 32767 bytes.
The limit of 3
Dear all,
we ICE'd in the simplification of the transformational intrinsic
ANY when the passed ARRAY argument had an invalid declaration.
The reason was a reference to array->shape which was NULL.
Obvious solution: then just don't attempt to simplify.
Regtested on x86_64-pc-linux-gnu and pushed
On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
wrote:
>
> > From: Ian Lance Taylor
> > Date: Tue, 24 Jan 2023 09:58:10 -0800
> > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >
> > I'd rather that the patch look like the appended. Can someone with a
> > Windows
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 09:58:10 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> I'd rather that the patch look like the appended. Can someone with a
> Windows system test to see what that builds and passes the tests?
ENOPATCH
On Tue, Jan 24, 2023 at 8:53 AM Eli Zaretskii via Gcc-patches
wrote:
>
> > From: Ian Lance Taylor
> > Date: Tue, 24 Jan 2023 06:35:21 -0800
> > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >
> > > > On Windows it seems that MAX_PATH is not
> > > > a true limit, as an extended
"Andre Vieira (lists)" writes:
> Hi,
>
> This patch adds aarch64 to the list of vect_long_long targets.
> Regression tested on aarch64-none-linux-gnu.
>
> OK for trunk?
>
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp (check_effective_target_vect_long_long): Add
> aarch64 to
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 06:35:21 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> > > On Windows it seems that MAX_PATH is not
> > > a true limit, as an extended length path may be up to 32767 bytes.
> >
> > The limit of 32767 characters (not by
Hi,
This patch adds aarch64 to the list of vect_long_long targets.
Regression tested on aarch64-none-linux-gnu.
OK for trunk?
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_long_long): Add
aarch64 to list of targets supporting long long vector
The SYSROOT_SUFFIX_SPEC works even when multilib is disabled.
So when build no-multilib glibc toolchain and the options are
not same as MULTILIB_DEFAULTS, the sysroot will specify wrong
because the libc will not be installed as such.
This bug causes glibc regression test error:
https://sourceware
On 1/24/23 09:47, Stefan Schulze Frielinghaus wrote:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy. The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
> https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
On 1/24/23 05:05, Jakub Jelinek wrote:
On Mon, Jan 23, 2023 at 12:44:48PM -0500, Andrew MacLeod wrote:
@@ -784,17 +794,28 @@ value_relation::negate ()
bool
value_relation::intersect (const value_relation &p)
{
- // Save previous value
- relation_kind old = related;
+ relation_kind k;
I stumbled over a new FAIL (regression) in sollve_vv today, which was due to an
odd corner case (see commit log for a description).
The mentioned in-scan error is tested for in gomp/loop-2.f90 ("'inscan'
REDUCTION
clause on construct other than DO, SIMD, DO SIMD, PARALLEL DO, PARALLEL DO
SIMD")
We should not insert an empty value to the container.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR ipa/108509
gcc/ChangeLog:
* cgraphunit.cc (walk_polymorphic_call_targets): Insert
ony non-null values.
> -Original Message-
> From: Andre Vieira (lists)
> Sent: Tuesday, January 24, 2023 2:40 PM
> To: 'gcc-patches@gcc.gnu.org'
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: Re: [PATCH] arm: Make MVE masked stores read memory operand
> [PR 108177]
>
> ping. (reattaching patch in th
ping. (reattaching patch in the hopes patchwork picks it up).
On 13/01/2023 16:05, Andre Simoes Dias Vieira via Gcc-patches wrote:
Hi,
This patch adds the memory operand of MVE masked stores as input operands to
mimic the 'partial' writes, to prevent erroneous write-after-write
optimizations as
On Tue, Jan 24, 2023 at 5:11 AM Eli Zaretskii via Gcc-patches
wrote:
>
> > Date: Mon, 23 Jan 2023 15:00:56 -0800
> > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> > From: Ian Lance Taylor via Gcc
> >
> > > +#ifdef HAVE_WINDOWS_H
> > > +
> > > +static char *
> > > +windows_get_executable_path (c
Hi,
This patch fixes the way we synthesize MVE predicate immediates and
fixes some other inconsistencies around predicates. For instance this
patch fixes the modes used in the vctp intrinsics, to couple them with
predicate modes with the appropriate lane numbers. For this V2QI is
added to rep
Hi,
This patch teaches GCC that zero-extending a MVE predicate from 16-bits
to 32-bits and then only using 16-bits is a no-op.
It does so in two steps:
- it lets gcc know that it can access any MVE predicate mode using any
other MVE predicate mode without needing to copy it, using the
TARGET_
I meant bootstrapped on aarch64-none-linux-gnu and not none-eabi.
On 24/01/2023 13:40, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
The ACLE defines mve_pred16_t as an unsigned short. This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.
Bootstrapped on
Hi,
The ACLE defines mve_pred16_t as an unsigned short. This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.
Bootstrapped on aarch64-none-eabi and regression tested on arm-none-eabi
and armeb-none-eabi for armv8.1-m.main+mve.fp.
OK for trunk?
gcc/ChangeL
PING^4
On 1/13/23 10:09, Martin Liška wrote:
> PING^3
>
> On 12/22/22 13:15, Martin Liška wrote:
>> PING^2
>>
>> On 12/9/22 09:27, Martin Liška wrote:
>>> PING^1
>>>
>>> On 12/2/22 12:27, Martin Liška wrote:
If -w is used, warn_odr properly sets *warned = false and
so it should be prese
PING^1
On 1/10/23 16:10, Martin Liška wrote:
> On 1/6/23 14:21, David Malcolm wrote:
>> On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>>> tests.
>>
>> Thanks for the patch.
>>
>> I noticed that you marked PR 108307 as a d
Hi all,
This patch series aims to fix two or three (depends on how you look at
it) regressions that came about in gcc 11. The first and third patch
address wrong-codegen regressions and the second a performance
regression. Patch two makes a change to the mid-end so I can understand
if there a
> Date: Mon, 23 Jan 2023 15:00:56 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Ian Lance Taylor via Gcc
>
> > +#ifdef HAVE_WINDOWS_H
> > +
> > +static char *
> > +windows_get_executable_path (char *buf, backtrace_error_callback
> > error_callback,
> > +
On Tue, Jan 24, 2023 at 01:37:07PM +0100, Richard Biener wrote:
> CFG cleanup computes dominators before the loop over blocks looking
> for merging opportunities. That computes also the fast-query DFS
> numbers but that's a bit pointless since any CFG cleanup will invalidate
> them immediately (th
CFG cleanup computes dominators before the loop over blocks looking
for merging opportunities. That computes also the fast-query DFS
numbers but that's a bit pointless since any CFG cleanup will invalidate
them immediately (they are re-computed before fixing up loops).
The following avoids this an
Thank you for the comments and suggestions.
I have changed the patch.
Unfortunately in case of rx target I could not make
scan-assembler-symbol-section to match. I believe it is because the
.section and .global entries order is reversed in this target.
Patch in inlined below. looking forward to
Excerpts from Stefan Schulze Frielinghaus's message of Januar 24, 2023 9:47 am:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy. The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
> https://github.com/dlang/dlang.org/commit/3b50a4c3faf01
On Tue, Jan 24, 2023 at 10:37:43AM +, Jonathan Wakely wrote:
> Changing CC to gcc-patches instead of gcc-bugs ...
The fix is obvious, so I've committed it. Thanks.
> On 24/01/23 04:14 +, Eric Biggers wrote:
> > Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2.
> >
On 24/01/2023 09:55, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
The patch fixes the build issue for arm-none-eabi target configured with
--with-multilib-list=aprofile,rmprofile, in which case the header file
arm/arm-mlib.h is being included more than once and the toolchain build
is fa
Changing CC to gcc-patches instead of gcc-bugs ...
On 24/01/23 04:14 +, Eric Biggers wrote:
Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2.
This bug caused the dump file produced by -fdump-ipa-inline-details to
not correctly show the difference in target options when
On Mon, Jan 23, 2023 at 12:44:48PM -0500, Andrew MacLeod wrote:
> @@ -784,17 +794,28 @@ value_relation::negate ()
> bool
> value_relation::intersect (const value_relation &p)
> {
> - // Save previous value
> - relation_kind old = related;
> + relation_kind k;
>
>if (p.op1 () == op1 () &
> -Original Message-
> From: Srinath Parvathaneni
> Sent: Tuesday, January 24, 2023 9:55 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Kyrylo Tkachov
> Subject: [PATCH][GCC] arm: Fix inclusion of arm-mlib.h header more than
> once (pr108505).
>
> Hello,
>
> The pat
Hello,
The patch fixes the build issue for arm-none-eabi target configured with
--with-multilib-list=aprofile,rmprofile, in which case the header file
arm/arm-mlib.h is being included more than once and the toolchain build
is failing (PR108505).
Regression tested on arm-none-eabi target and found
Hi!
On 2023-01-20T22:16:00+0100, I wrote:
> On 2023-01-20T22:04:02+0100, I wrote:
>> We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx
>> offloading, which means building a normal (non-'LIBGFOR_MINIMAL')
>> configuration of libgfortran.
>
> This is achieved by 'nvptx, libgfortr
On Mon, Jan 23, 2023 at 12:44:42PM -0500, Andrew MacLeod wrote:
> In order to fix 108447, this patch changes the calls to relation_union and
> relation_intersection to instead utilize the value_relation class, and make
> the calls through that instead.
>
> value_relation manages the operands of a
Dimitar Dimitrov writes:
> The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target,
> exposing a wrong code generation bug in the PRU backend. The "clz"
> pattern did not produce correct output for QI and HI input operand
> modes. SI mode is ok.
>
> The "clz" pattern is expanded to
Hi!
On 2022-12-20T09:03:51+0100, I wrote:
> Minor change in the attached
> "nvptx: Support global constructors/destructors via 'collect2'": for
> 'atexit', add '#include ' to 'libgcc/config/nvptx/crt0.c'.
Turns out, it's not that easy. ;-) Pushed to devel/omp/gcc-12 branch
commit d90a8a5685c8bd3
On Tue, Jan 24, 2023 at 12:22 AM Andrew MacLeod via Gcc-patches
wrote:
>
> get_shift_range was incorrectly communicating that it couldn't calculate
> a range when the shift value was out of range.
>
> Fix this and always return a range of [0, 0] instead of varying when the
> shift value is out of
In the context of D the interpretation of S390, S390X, and SystemZ is a
bit fuzzy. The wording S390X was wrongly deprecated in favour of
SystemZ by commit
https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
Thus, SystemZ is used for 64-bit targets, now, and S390 for
On Mon, Jan 23, 2023 at 6:44 PM Andrew MacLeod wrote:
>
> This patch adds VREL_OTHER to represent another relation we do not
> understand. It is used to represent the class fo relations arising from
> floating point that are currently not represented. IN GCC 14 we will
> determine exactly how to
On Mon, Jan 23, 2023 at 6:44 PM Andrew MacLeod wrote:
>
> In order to fix 108447, this patch changes the calls to relation_union
> and relation_intersection to instead utilize the value_relation class,
> and make the calls through that instead.
>
> value_relation manages the operands of a relation
58 matches
Mail list logo