From: Piotr Trojanek
Removed code was dead because it could only be executed when
Back_End_Inlining is True and that flag is always false in
GNATprove_Mode.
gcc/ada/
* inline.adb (Cannot_Inline): Cleanup use of 'Length; remove
dead code.
Tested on x86_64-pc-linux-gnu, committed
From: Tucker Taft
Check_Scil failed due to not handling a type that came from a package that was
mentioned in a limited-with clause. Also, an aggregate with an uninitialized
component was not being pretty-printed properly.
gcc/ada/
* pprint.adb (List_Name): Check for "Box_Present" when
From: Eric Botcazou
The problem is that the freeze node for the class-wide subtype built for the
expression of the allocator escapes from the dependent expression instead of
being stored in its list of actions.
gcc/ada/
* freeze.adb (Freeze_Expression.Has_Decl_In_List): Deal specificall
From: Piotr Trojanek
Inlining of subprogram calls happens in routine Expand_Inlined_Call
which calls Establish_Actual_Mapping_For_Inlined_Call. Both routines
had detection of recursive calls. The detection in the second routine
was dead code.
gcc/ada/
* inline.adb (Establish_Actual_Mapp
From: Eric Botcazou
This declares an explicit temporary for the fields of the fat pointer type
in gnat_to_gnu_entity and removes the GNU_ prefix of the parameters of the
relate_alias_sets routine for the sake of brevity. No functional changes.
gcc/ada/
* gcc-interface/decl.cc (gnat_to_
From: Piotr Trojanek
Previously if a subprogram call could not be inlined in GNATprove mode,
then all subsequent calls to the same subprogram were not inlined
either (because a failed attempt to inline clears flag Is_Inlined_Always
and we tested this flag when attempting to inline subsequent call
From: Eric Botcazou
The compiler has not generated direct attachments for a long time.
gcc/ada/
* rtsfind.ads (RE_Id): Remove RE_Attach.
(RE_Unit_Table): Likewise.
* libgnat/s-finmas.ads (Attach): Delete.
* libgnat/s-finmas.adb (Attach): Likewise.
Tested on x86_
From: Bob Duff
It is legal to pass a private type, or a type with a component whose
type is private, as a generic actual type if the formal is a generic
formal incomplete type. This patch fixes a bug in which the compiler
would give an error in some such cases.
Also misc cleanup.
gcc/ada/
From: Viljar Indus
In some extended code we generate comparisons between
the Addresses of some variables. This causes those
variables to be considered modified. Whereas in this
particular scenario the variables are just referenced.
gcc/ada/
* sem_attr.adb: avoid marking a use of the Add
From: Eric Botcazou
This occurs because the access element type is not its own TYPE_CANONICAL,
which creates a discrepancy between the aliasing support code, which deals
with types directly, and the middle-end which looks at TYPE_CANONICAL only.
gcc/ada/
* gcc-interface/decl.cc (gnat_to
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, January 9, 2024 12:26 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH]middle-end: Fix dominators updates when peeling with
> multiple exits [PR113144]
>
> On Tue, 9 Ja
From: Piotr Trojanek
Add description of a recently added SPARK contract.
gcc/ada/
* doc/gnat_rm/implementation_defined_aspects.rst,
doc/gnat_rm/implementation_defined_pragmas.rst: Add sections for
Always_Terminates.
* gnat-style.texi: Regenerate.
* gnat_r
On Tue, 9 Jan 2024, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, January 9, 2024 12:26 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH]middle-end: Fix dominators updates when
On Tue, 9 Jan 2024, Richard Biener wrote:
> On Tue, 9 Jan 2024, Tamar Christina wrote:
>
> >
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Tuesday, January 9, 2024 12:26 PM
> > > To: Tamar Christina
> > > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
>
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, January 9, 2024 1:51 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH]middle-end: Fix dominators updates when peeling with
> multiple exits [PR113144]
>
> On Tue, 9 Jan 20
Feng Xue OS via Gcc-patches writes:
> This patch extends option -mbranch-protection=bti with an optional argument
> as bti[+all] to force compiler to unconditionally insert bti for all
> functions. Because a direct function call at the stage of compiling might be
> rewritten to an indirect call w
On Tue, 9 Jan 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, January 9, 2024 1:51 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH]middle-end: Fix dominators updates when peelin
On Tue, Jan 09, 2024 at 09:52:17AM +0100, Jakub Jelinek wrote:
> Hi!
>
> The copy attributes is allowed on decls as well as types and even has
> checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics
> unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only work
Andrea Corallo writes:
> Feng Xue OS via Gcc-patches writes:
>
>> This patch extends option -mbranch-protection=bti with an optional argument
>> as bti[+all] to force compiler to unconditionally insert bti for all
>> functions. Because a direct function call at the stage of compiling might be
>>
On 1/7/24 16:07, 钟居哲 wrote:
Since in the previous review from Robin, he have ever asked me change
std::max into MAX,
I thought the policy is preferring MAX instead of std::max.
I change the codes to make them consistent but it seems I am wrong.
So is it reasonable that I change all RVV-rela
On 1/7/24 17:06, Maciej W. Rozycki wrote:
Complement commit c1e8cb3d9f94 ("RISC-V: Rework branch costing model for
if-conversion") and also handle extraneous sign extend operations that
are sometimes produced by `noce_try_cmove_arith' instead of zero extend
operations, making branch costing co
On 2023-12-18 09:35, Siddhesh Poyarekar wrote:
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant, the absence of ha
> Am 09.01.2024 um 16:13 schrieb Siddhesh Poyarekar :
>
> On 2023-12-18 09:35, Siddhesh Poyarekar wrote:
>> The "exploitable vulnerability" may lead to a misunderstanding that missed
>> hardening issues are considered vulnerabilities, just that they're not
>> exploitable. This is not true,
Hi,
In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes
attached to callee saves (in aarch64_save_callee_saves). That patch changed
the ldp/stp representation to use unspecs instead of PARALLEL moves. This meant
that we needed to attach CFI notes to all frame-related p
On Thu, 2023-12-21 at 08:42 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds support for the -fsigned-char flag.
Thanks. The patch looks correct to me.
> I'm not sure how to test it since I stumbled upon this bug when I
> found
> this other bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
On Tue, Jan 9, 2024 at 4:13 AM Richard Biener wrote:
>
> On Tue, 9 Jan 2024, Tamar Christina wrote:
>
> > > > -
> > > > - gimple_seq_add_seq (&stmts, tem);
> > > > -
> > > > - scalar_res = gimple_build (&stmts, CFN_EXTRACT_LAST, scalar_type,
> > > > - mask, vec_l
Richard Biener writes:
> On Tue, 9 Jan 2024, Tamar Christina wrote:
>
>> > > -
>> > > - gimple_seq_add_seq (&stmts, tem);
>> > > -
>> > > - scalar_res = gimple_build (&stmts, CFN_EXTRACT_LAST, scalar_type,
>> > > - mask, vec_lhs_phi);
>> > > +scal
Hmm I'm confused as to why It didn't break mine.. just did one again.. anyway
I'll remove the unused variable.
> -Original Message-
> From: Rainer Orth
> Sent: Tuesday, January 9, 2024 4:06 PM
> To: Richard Biener
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
> ; j...@ventanamicro
On Tue, Jan 9, 2024 at 8:10 AM Tamar Christina wrote:
>
> Hmm I'm confused as to why It didn't break mine.. just did one again.. anyway
> I'll remove the unused variable.
Can you also make vectorizable_live_operation_1 static?
> > -Original Message-
> > From: Rainer Orth
> > Sent: Tues
The tests still fail.
gcc: Unexpected fails for rv64gc lp64d medlow
FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O0 (test for
excess errors)
FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O1 (test for
excess errors)
FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O
Hi All,
It looks like the previous patch had an unused variable.
It's odd that my bootstrap didn't catch it (I'm assuming
-Werror is still on for O3 bootstraps) but this fixes it.
Committed to fix bootstrap.
Thanks,
Tamar
gcc/ChangeLog:
* tree-vect-loop.cc (vectorizable_live_operation_
On Fri, 2023-12-22 at 10:25 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds the support of the sizeof operator.
> I was wondering if this new API entrypoint should take a location as
> a
> parameter. What do you think?
I'd prefer it if it did (even if it's currently ignored internally),
but i
On Fri, 2023-12-22 at 09:39 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds missing builtins needed by optimizations.
> Thanks for the review.
The patch looks good to me.
Thanks!
Dave
When -fsanitize=hwaddress is used, libhwasan will try to enable LAM_U57
in the startup code. Update the target check to enable hwaddress tests
if LAM_U57 is enabled. Also compile hwaddress tests with -mlam=u57 on
x86-64 since hwasan requires LAM_U57 on x86-64.
* lib/hwasan-dg.exp (check_
Ups - now attached. Thanks Martin!
Martin Jambor wrote:
On Mon, Jan 08 2024, Tobias Burnus wrote:
The attached patch
there was no patch attached to your message.
Martin
does a tiny updated to the OpenMP features (AMD GCN
now also has an optimized memcpy_rect not only nvptx), but the main
c
This patch removes suffixes from section names during LTO linking.
These suffixes were originally added for ld -r to work (PR lto/44992).
They were added to all LTO object files, but are only useful before WPA.
After that they waste space, and if kept random, make LTO caching impossible.
Bootstra
Hi,
> You do not implement GCOV_LINKED_WITH_LOCKING patch, does locking work
> with mingw? Or we only build gcc with cygwin emulation layer these days?
I tried to test _locking implementation with both mingw and msys2, in both
cases fcntl was present and _locking was not. Admittedly I was unable t
Richard Sandiford debugged a failure on the mn103 port with his
late-combine patches down to the subdi3 pattern not specifying the isa
on alternatives which required newer variants of the chip family.
This patch adds the missing isa attribute and the port now works with
his late-combine patc
So I consider this port dead as it semi-randomly fails in reload due to
unrelated changes earlier in the gimple and RTL pipelines. Regardless
Richard S's late-combine work did show a very obvious error in the port
that we should go ahead and fix as long as the port is in-tree.
The epiphany
Tested aarch64-linux. Pushed to trunk.
-- >8 --
I don't remember exactly why I made these bits of code reserve space in
a COW string and append to it, rather than just use the string returned
from std::format (which will undergo copy elision). The _Str_sink type
used by std::format means the stri
xstormy16 has failed since the c99 transition due to a missing prototype
for __clzhi2 in the implementation of storm16_count_loaading_zeros.
This fixes the missing prototype. Pushed to the trunk.
jeffcommit 9f7afa99c67f039e43019ebd08d14a7f01e2d89c
Author: Jeff Law
Date: Tue Jan 9 10:21:28 2
On 1/8/24 03:45, Richard Biener wrote:
On Tue, Jan 2, 2024 at 2:37 PM wrote:
From: Pan Li
According to the sematics of no-signed-zeros option, the backend
like RISC-V should treat the minus zero -0.0f as plus zero 0.0f.
Consider below example with option -fno-signed-zeros.
void
test (fl
On 1/8/24 16:04, 钟居哲 wrote:
This patch looks ok from myside.
Likewise.
So I think the only question for this specific patch is whether or not
it makes sense to include it now or wait for more of the thead bits to
get to acceptance.
I tend to think it should wait since I don't think it ha
On 11/17/23 00:33, Jin Ma wrote:
The XTheadInt ISA extension provides acceleration interruption
instructions as defined in T-Head-specific:
* th.ipush
* th.ipop
Ref:
https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
gcc/ChangeLog:
On 1/9/24 01:52, Jakub Jelinek wrote:
Hi!
The copy attributes is allowed on decls as well as types and even has
checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics
unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works
if it applies to a decl.
Th
On 1/8/24 06:47, Kito Cheng wrote:
Do you know how to build a ISA string with following extension?
- g
- c
- zba
- zbs
- svnapot
- zve64d
- zvl128b
Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I
believe it's impossible for most people, even I work for RISC-V so ma
On 1/8/24 06:14, Mary Bennett wrote:
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Hele
On 1/5/24 09:28, Richard Sandiford wrote:
function.cc emits a NOTE_FUNCTION_BEG after all arguments have
been copied to pseudos. It then records this note in parm_birth_insn.
Various other pieces of code use this insn as a convenient place to
insert things at the start of the function.
Howev
On 1/3/24 16:39, Richard Sandiford wrote:
YunQiang Su writes:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(i
On 1/2/24 12:41, Ilya Leoshkevich wrote:
GCC can emit code between the function label and the .LASANPC label,
making the latter unaligned. Some architectures cannot load unaligned
labels directly and require literal pool entries, which is inefficient.
Move the invocation of asan_function_sta
On 1/5/24 15:01, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
Here during default template argument substitution we wrongly consider
the (substituted) default arguments v and vt as value-dependent[1]
which ultimately leads to dedu
Hello.
I forgot to add the target maintainers to the CC. My apologies for that.
Furthermore, I am adding also relevant changes in `libgcc/config/aarch64/lse.S`
file to the patch. Originally we wanted to submit those changes separately but
after the feedback from Andrew Pinski, it makes sense to
On Tue, 2024-01-09 at 11:55 -0700, Jeff Law wrote:
>
>
> On 1/2/24 12:41, Ilya Leoshkevich wrote:
> > GCC can emit code between the function label and the .LASANPC
> > label,
> > making the latter unaligned. Some architectures cannot load
> > unaligned
> > labels directly and require literal poo
On 1/6/24 01:59, Jakub Jelinek wrote:
Hi!
The following testcase ICEs (on ARM/RISCV with certain options), because niters
analysis
computes number of latch executions for the loop as
(short unsigned int) (a.0_1 + 255) + 1 > 256 ? ~(short unsigned int) (a.0_1 +
255) : 0
where a.0_1 is unsign
gcc: gcc.dg/vect/vect-outer-4a-big-array.c -flto -ffat-lto-objects: error
executing dg-final: unknown effective target keyword `loongarch*-*-*'
gcc: gcc.dg/vect/vect-outer-4a-big-array.c: error executing dg-final: unknown
effective target keyword `loongarch*-*-*'
gcc: gcc.dg/vect/vect-outer-4a.c
On Wed, 2023-11-15 at 17:53 +0100, Guillaume Gomez wrote:
> Hi,
>
> This patch adds the (incomplete) support for function and variable
> attributes. The added attributes are the ones we're using in
> rustc_codegen_gcc but all the groundwork is done to add more (and we
> will very likely add more a
Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
Date: Sun, 7 Jan 2024 17:07:06 +0100
Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
From: Björn Schäpers
That was about GetModuleHandle, not about GetModuleHandleEx. For the
latter, all Windows versions that support it also support
Hi,
this is not really a regression but the patch was written last week and is
quite straightforward, so hopefully can nevertheless be OK. It implements the
support of DW_AT_endianity for enumeration types because they are scalar and,
therefore, reverse Scalar_Storage_Order is supported for th
Alex Coplan writes:
> Hi,
>
> In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes
> attached to callee saves (in aarch64_save_callee_saves). That patch changed
> the ldp/stp representation to use unspecs instead of PARALLEL moves. This
> meant
> that we needed to atta
Hi Richard,
>> +#define MAX_SET_SIZE(speed) (speed ? 256 : 96)
>
> Since this isn't (AFAIK) a standard macro, there doesn't seem to be
> any need to put it in the header file. It could just go at the head
> of aarch64.cc instead.
Sure, I've moved it in v4.
>> + if (len <= 24 || (aarch64_tune_p
On 1/6/24 19:00, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working but I have not
included it in this version of the patch. I was not happy with the
amount of work I had done on it. I will try to get it finished befo
On Tuesday, January 9th, 2024 at 1:58 PM, Jason Merrill
wrote:
>
>
> On 1/6/24 19:00, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > I'm considering this finished, I have CWG2586 working but I have not
> > included it in this version of the patch.
Tighten the regex to find the start of the .dynsym symtab in the readelf
output to avoid matching the section symbol in the normal symtab.
libstdc++-v3:
* scripts/extract_symvers.in: Require final colon to only match
.dsynsym in the header of the dynamic symtab.
---
libstdc++-v3/s
On 1/9/24 15:58, Jason Merrill wrote:
On 1/6/24 19:00, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working but I have not
included it in this version of the patch. I was not happy with the
amount of work I had done on
Does anybody see any problem with making this change, so that we avoid
the problem described in the PR?
-- >8 --
As described in PR libstdc++/113258 there are old versions of tcmalloc
which replace malloc and related APIs, but do not repalce aligned_alloc
because it didn't exist at the time they
On Tue, 9 Jan 2024 at 21:47, Andreas Schwab wrote:
>
> Tighten the regex to find the start of the .dynsym symtab in the readelf
> output to avoid matching the section symbol in the normal symtab.
OK, thanks.
>
> libstdc++-v3:
> * scripts/extract_symvers.in: Require final colon to only ma
On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill
wrote:
>
>
> On 1/9/24 15:58, Jason Merrill wrote:
>
> > On 1/6/24 19:00, waffl3x wrote:
> >
> > > Bootstrapped and tested on x86_64-linux with no regressions.
> > >
> > > I'm considering this finished, I have CWG2586 working bu
Yes. I aggree with you that we should wait until all theadvector are acccepted.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-01-10 01:49
To: 钟居哲; cooper.joshua; gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; Christoph Müllner; jinma;
Cooper Qu
Subject: Re: [PATCH
On 1/5/24 4:18 PM, Michael Meissner wrote:
> @@ -14504,13 +14504,17 @@ print_operand (FILE *file, rtx x, int code)
> print_operand (file, x, 0);
>return;
>
> +case 'S':
> case 'x':
> - /* X is a FPR or Altivec register used in a VSX context. */
> + /* X is a FPR
On 1/9/24 17:34, waffl3x wrote:
On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill
wrote:
On 1/9/24 15:58, Jason Merrill wrote:
On 1/6/24 19:00, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working but I have
Hi Julian!
On 2024-01-07T16:04:37+0100, Tobias Burnus wrote:
> Am 05.01.24 um 13:23 schrieb Julian Brown:
>> Here's a rebased/retested version [...]
> LGTM - [...]
Got pushed as commit r14-7033-g1413af02d62182bc1e19698aaa4dae406f8f13bf
"OpenMP: lvalue parsing for map/to/from clauses (C++)".
So
On Linux/x86_64,
1413af02d62182bc1e19698aaa4dae406f8f13bf is the first bad commit
commit 1413af02d62182bc1e19698aaa4dae406f8f13bf
Author: Julian Brown
Date: Mon Sep 12 17:11:29 2022 +
OpenMP: lvalue parsing for map/to/from clauses (C++)
caused
FAIL: g++.dg/gomp/array-section-1.C -st
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix some copy & pasted logic in __is_extended_pictographic. This
function should yield false for the values before the first edge, not
true. Also add a missing boundary condition check in __incb_property.
Also Fix an off-by-one error in _Utf_iterato
101 - 173 of 173 matches
Mail list logo
