From: trcrsired
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
Add bits/c++config.h before headers in assert_fail
---
libstdc++-v3/src/c++11/assert_fail.cc | 11 +++
1 file changed, 7
Hi,
I have noticed that in gcc-13, test05 (in the 94749.cc testcase) is still
enabled for simulators, and I have noticed that because of test05, the
27_io/basic_istream/ignore/char/94749.cc execution test is not terminating on
our simulator for armv8.1-m.main+mve, even after 3 hours.
The
On Fri, Jun 21, 2024 at 1:11 PM Jeff Law wrote:
>
>
>
> On 6/17/24 3:53 AM, Richard Sandiford wrote:
> > This patch makes target-independent code use force_subreg instead
> > of simplify_gen_subreg in some places. The criteria were:
> >
> > (1) The code is obviously specific to expand (where new
From: trcrsired
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
---
libstdc++-v3/src/c++11/assert_fail.cc | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1556-gccbcde5ec0e481.
gcc/ChangeLog:
* diagnostic-format-json.cc
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1555-g4819dc7d4b84af.
gcc/ChangeLog:
* diagnostic-path.cc (diagnostic_event::meaning::dump_to_pp):
PR analyzer/115564 reports a missing warning from the analyzer
on this infinite loop at -O2 and above:
void test (unsigned b)
{
for (unsigned i = b; i >= 0; --i) {}
}
The issue is that there are no useful location_t values in the CFG
by the time the analyzer sees it: two basic blocks with
More minor fallout from the IOR->PLUS change a little while ago. This
time on xstormy16.
The pattern to swap nibbles actually tries to handle all the cases of
IOR, XOR and PLUS. But when we generate PLUS earlier in the pipeline,
the simplifications/canonicalizations are slightly different
Hi Hongtao,
I submitted a patch silencing -Wshift-overflow on a signed int
constant here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654016.html
You OK'd it here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654140.html
Are you able to commit it for me please? I do not
GCC maintainers:
version 4: Additional dg option updates per the feedback. Retested the patch
on Power 10, no regressions.
version 3: Updated per the feedback from Peter, Kewen and Segher. Note, Peter
suggested the -mdejagnu-cpu= value must be power7.
The test fails if -mdejagnu-cpu= is
On Tue, 22 Mar 2022, Pokechu22 via Gcc-patches wrote:
> ---
> htdocs/contribute.html | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Sorry this fell through the cracks on our end. I'll shortly push a change
to add the missing closing parenthesis.
All other changes have been
Hi Richard,
Thanks for the review and apologies for taking so long to get back to this.
This revision implements your suggestions from early May, as found at
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650405.html
This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
On 6/17/24 3:53 AM, Richard Sandiford wrote:
This patch makes target-independent code use force_subreg instead
of simplify_gen_subreg in some places. The criteria were:
(1) The code is obviously specific to expand (where new pseudos
can be created), or at least would be invalid to call
Andi Kleen writes:
> FWIW I suspect not handling lockfile errors could be a show stopper
> even for an initial implementation. It's not that uncommon that people
> press Ctrl-C. flock on systems that have it would be a safer
> alternative.
>
>> There are many things to do and I think it is
On Fri, Jun 21, 2024 at 06:59:05PM +0200, Michal Jireš wrote:
> > The lockfiles scare me a bit. What happens when they get lost, e.g.
> > due to a compiler crash? You may need some recovery for that.
> > Perhaps it would be better to make the files self checking, so that
> > partial files can be
FWIW I suspect not handling lockfile errors could be a show stopper
even for an initial implementation. It's not that uncommon that people
press Ctrl-C. flock on systems that have it would be a safer
alternative.
> There are many things to do and I think it is better to do that in trunk
>
GCC maintainers:
version 2, update the dg options per the feedback. Retested the patch on Power
10 with no regressions.
This patch updates the dg options.
The patch has been tested on Power 10 with no regression failures.
Please let me know if this patch is acceptable for mainline. Thanks.
Kewen:
On 6/21/24 03:37, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/20 00:18, Carl Love wrote:
>> GCC maintainers:
>>
>> The dg options for this test should be the same as for altivec-2-runnable.c.
>> This patch updates the dg options to match
>> the settings in altivec-2-runnable.c.
>>
>> The
GCC maintainers:
Per the discussion of the dg header changes for test files altivec-1-runnable.c
and altivec-2-runnable.c it was decided it would be best to change the names of
the two tests to better align them with the tests that they are better aligned
with.
This patch is dependent on the
Kewen:
On 6/21/24 03:36, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/20 00:13, Carl Love wrote:
>> GCC maintainers:
>>
>> version 2: Updated per the feedback from Peter, Kewen and Segher. Note,
>> Peter suggested the -mdejagnu-cpu= value must be power7.
>> The test fails if -mdejagnu-cpu= is
On 6/20/24 7:45 PM, Andi Kleen wrote:
There are much faster/optimized modern hashes for good collision detection over
MD5 especially when it's not needed to be cryptographically secure. Pick
something from smhasher.
Also perhaps the check sum should be cached in the file? I assume it's
cheap
Hi Feng,
Pre-commit has flagged a build-failure for patch 2/3:
https://github.com/ewlu/gcc-precommit-ci/issues/1786#issuecomment-2181962244
When applied to 9a76db24e04 i386: Allow all register_operand SUBREGs in
x86_ternlog_idx.
Re-confirmed locally with 5320bcbd342 xstormy16: Fix
This series (and the patch it depends on) have been pushed to trunk now.
On Fri, 21 Jun 2024 at 10:31, Jonathan Wakely wrote:
>
> Oops, this patch series actually depends on
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html which
> was posted separately, but needs to be applied
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:28, Jonathan Wakely wrote:
>
> I think the new conditions are correct. They're certainly an improvment
> on just checking __is_scalar without considering what we're assigning it
> to.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> As noted in the PR, the
On 21/06/2024 16:30, Tobias Burnus wrote:
[I messed up copying from the build system, picking up an old version.
Changes to v1 (bottom of the diff): fopen is no longer required.]
Tobias Burnus wrote:
mkoffload's generated .c file looks much nicer with '#embed'.
This patch depends on Jakub's
On Fri, 21 Jun 2024 at 16:07, Matthias Kretz wrote:
>
>
> * Running a test compiled with AVX512 instructions requires
> avx512f_runtime not just avx512f.
>
> * The 'reduce2' test violated an invariant of fixed_size_simd_mask and
> thus failed on all targets without 16-Byte vector builtins enabled
[I messed up copying from the build system, picking up an old version.
Changes to v1 (bottom of the diff): fopen is no longer required.]
Tobias Burnus wrote:
mkoffload's generated .c file looks much nicer with '#embed'.
This patch depends on Jakub's #embed patch at
On 6/19/24 9:43 PM, Christoph Müllner wrote:
Hi Jeff,
the test should probably also be skipped on -Oz:
=== gcc: Unexpected fails for rv64imafdc lp64d medlow ===
FAIL: gcc.target/riscv/zbs-ext-2.c -Oz scan-assembler-times andi\t 1
FAIL: gcc.target/riscv/zbs-ext-2.c -Oz
mkoffload's generated .c file looks much nicer with '#embed'.
This patch depends on Jakub's #embed patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
It might be a tiny bit faster than currently (or not); however,
once #embed has a large-file mode, it should also speed up
* Running a test compiled with AVX512 instructions requires
avx512f_runtime not just avx512f.
* The 'reduce2' test violated an invariant of fixed_size_simd_mask and
thus failed on all targets without 16-Byte vector builtins enabled (in
bits/simd.h).
Signed-off-by: Matthias Kretz
On 6/20/24 7:34 AM, Richard Sandiford wrote:
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
The pass currently has a single objective: remove definitions by
substituting into all uses. The
Presently, the code fragment:
int x[5];
void
d(int a, int b, int c) {
for (int i = 0; i < 5; i++)
x[i] = (a != b) ? c : a;
}
causes an ICE when compiled with -O2 -march=rv32i_zicond:
test.c: In function 'd':
test.c: error: unrecognizable insn:
11 | }
| ^
(insn 8 5 9 2 (set
Thanks Richard for suggestion, tried the (convert? with below gimple stmt but
got a miss def ice.
To double confirm, the *type_out should be the vector type of lhs, and we only
need to build
one cvt stmt from itype to otype here. Or just return the call directly and set
the type_out to the
On 6/20/24 7:34 AM, Richard Sandiford wrote:
rtl-ssa has routines for scanning forwards or backwards for something
under the control of an exclusion set. These searches are currently
used for two main things:
- to work out where an instruction can be moved within its EBB
- to work out
On 6/20/24 7:34 AM, Richard Sandiford wrote:
The iq2000 test and branch instructions had patterns like:
[(set (pc)
(if_then_else
(eq (and:SI (match_operand:SI 0 "register_operand" "r")
(match_operand:SI 1 "power_of_2_operand" "I"))
On 6/20/24 7:34 AM, Richard Sandiford wrote:
All uses of xs_hi_nonmemory_operand allow constraint "i",
which means that they allow consts, symbol_refs and label_refs.
The definition of xs_hi_nonmemory_operand accounted for consts,
but not for symbol_refs and label_refs.
gcc/
*
On 6/20/24 7:34 AM, Richard Sandiford wrote:
No-op moves are given the code NOOP_MOVE_INSN_CODE if we plan
to delete them later. Such insns shouldn't be costed, partly
because they're going to disappear, and partly because targets
won't recognise the insn code.
gcc/
*
Richard Biener writes:
> On Thu, 20 Jun 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Mon, 17 Jun 2024, Richard Sandiford wrote:
>> >
>> >> Richard Biener writes:
>> >> > On Fri, 14 Jun 2024, Richard Biener wrote:
>> >> >
>> >> >> On Fri, 14 Jun 2024, Richard Sandiford
> >
> > And FAOD I think a stub check has to remain even after the removal and
> > just cause `configure' to bail out if an unsupported obsolete version of
> > GAS has been identified.
> >
Ohh, I think that we shouldn't remove it now, as I have figure out
the PCREL patch,
and I am still waiting
Maciej W. Rozycki 于2024年6月21日周五 22:00写道：
>
> On Fri, 21 Jun 2024, Maciej W. Rozycki wrote:
>
> > > Yeah, agreed FWIW. This was necessary while the feature was relatively
> > > new, and while we still supported IRIX as, but I can't see any reasonable
> > > justification for using such an ancient
Maciej W. Rozycki 于2024年6月21日周五 20:55写道：
>
> On Fri, 21 Jun 2024, Richard Sandiford wrote:
>
> > > We check gcc_cv_as_mips_explicit_relocs if
> > > gcc_cv_as_mips_explicit_relocs_pcrel
> > > only, while gcc_cv_as_mips_explicit_relocs is used by later code.
> > >
> > > Maybe, it is time for use
On Fri, 21 Jun 2024, Maciej W. Rozycki wrote:
> > Yeah, agreed FWIW. This was necessary while the feature was relatively
> > new, and while we still supported IRIX as, but I can't see any reasonable
> > justification for using such an ancient binutils with modern GCC.
> >
> > Getting rid of
Evgeny Karpov writes:
> Monday, June 10, 2024 7:03 PM
> Richard Sandiford wrote:
>
>> Thanks for the update. Parts 1-5 look good to me. Some minor comments
>> below about part 6:
>>
>> If the TARGET_DLLIMPORT_DECL_ATTRIBUTES condition can be dropped, the
>> series is OK from my POV with that
On Fri, 21 Jun 2024 at 12:14, Richard Earnshaw (lists)
wrote:
>
> On 21/06/2024 08:57, Alexandre Oliva wrote:
> > On Jun 20, 2024, Christophe Lyon wrote:
> >
> >> Maybe using
> >> if ((unsigned)b[i] >= BITS) \
> >> would be clearer?
> >
> > Heh. Why make it simpler if we can make it unreadable,
Hi all,
it turned out that 'declare target' with 'link' clause was broken in multiple
ways.
The main fix is the attached patch, i.e. namely pushing the variables already to
the offload-vars list already in the FE.
When implementing it, I noticed:
* C has a similar issue when using nested
This patch adds
--param=vrp-block-limit=N
When the basic block counter for a function exceeded 'N' , VRP is
invoked with the new fast_vrp algorithm instead. This algorithm uses a
lot less memory and processing power, although it does get a few less
things.
Primary motivation is cases
This patch changes the algorithm for fast VRP. When looking at PR
114855, although VRP is not the main culrpit, it is taking about 600
seconds out of the 10,000.. far more than it should. That test case has
about 400,000 basic blocks, and when we get into that size, some of the
tables and
I found that I was frequently writing the same hunk of code which checks
the result of set_range_info() and and prints the global range to the
dump_file when it is updated.
This routine only returns true if the value provided improves the
range. Ie, 'old_value' intersect 'new_value' !=
With the earlier rework of VRP which removed the array_bounds pass, it
is now possible to invoke a different VRP for any pass. This patch adds
the ability to call fast_vrp with the final_pass flag set, and remove
invoke the remove_unreachable object to remove __builtin_unreachable
calls if it
This patch extends the dg directive verify-sarif-file so that if
the "jsonschema" tool is available, it will be used to validate the
generated .sarif file.
Tested with jsonschema 3.2 with Python 3.8
With the previous patch, all files generated by the DejaGnu testsuite
validate.
There were no
When adding validation of .sarif files against the schema
(PR testsuite/109360) I discovered various issues where we were
generating invalid .sarif files.
Specifically, in
c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c
the relatedLocations for the "note" diagnostics were
On Fri, 21 Jun 2024, Richard Sandiford wrote:
> > We check gcc_cv_as_mips_explicit_relocs if
> > gcc_cv_as_mips_explicit_relocs_pcrel
> > only, while gcc_cv_as_mips_explicit_relocs is used by later code.
> >
> > Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> > as
Hi!
Here is an incremental patch which adds support for string concatenation
in the parsing of gnu::base64 #embed parameter and emits it as well
in -E -fdirectives-only preprocessing, e.g.
cat embed-do.c; ./cc1 -quiet -E -fdirectives-only embed-do.c -nostdinc
#embed
On Fri, 21 Jun 2024, YunQiang Su wrote:
> > Then GCC emits the wrong trap instruction, wherever it comes from and
> > whatever has caused it. The correct ones for integer division by zero
>
> Thanks so much. It is not the bug of Linux kernel or GCC.
> It is a bug of me ;) and qemu.
>
> Qemu
For outer loop vectorization of a data reference in the inner loop
we have to look at both steps to see if they preserve alignment.
What is special for this testcase is that the outer loop step is
one element but the inner loop step four and that we now use SLP
and the vectorization factor is
LGTM, thanks :)
On Fri, Jun 21, 2024 at 7:33 PM Craig Blackmore <
craig.blackm...@embecosm.com> wrote:
> These tests check the sched2 dump, so skip them for optimization levels
> that do not enable sched2.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/mcpu-6.c: Skip for -O0, -O1,
These tests check the sched2 dump, so skip them for optimization levels
that do not enable sched2.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mcpu-6.c: Skip for -O0, -O1, -Og.
* gcc.target/riscv/mcpu-7.c: Likewise.
---
gcc/testsuite/gcc.target/riscv/mcpu-6.c | 1 +
> Michal Jires writes:
>
> No performance data?
Michal has bachelor thesis on the topic which has some statistics
https://dspace.cuni.cz/handle/20.500.11956/183051?locale-attribute=en
>
> > +
> > +static const md5_checksum_t INVALID_CHECKSUM = {
> > + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Hi Haochen,
on 2024/5/24 14:02, HAO CHEN GUI wrote:
> Hi,
> This patch implemented optab_isinf for SFDF and IEEE128 by test
> data class instructions.
>
> Compared with previous version, the main change is to narrow
> down the predict for float operand according to review's advice.
>
Hi Carl,
on 2024/6/20 00:18, Carl Love wrote:
> GCC maintainers:
>
> The dg options for this test should be the same as for altivec-2-runnable.c.
> This patch updates the dg options to match
> the settings in altivec-2-runnable.c.
>
> The patch has been tested on Power 10 with no regression
Hi Jeff,
on 2024/6/13 10:19, Jiufu Guo wrote:
> Hi,
>
> Sometimes, a complicated constant is built via 3(or more)
> instructions. Generally speaking, it would not be as fast
> as loading it from the constant pool (as the discussions in
> PR63281):
> "ld" is one instruction. If consider
Hi Carl,
on 2024/6/20 00:13, Carl Love wrote:
> GCC maintainers:
>
> version 2: Updated per the feedback from Peter, Kewen and Segher. Note,
> Peter suggested the -mdejagnu-cpu= value must be power7.
> The test fails if -mdejagnu-cpu= is set to power7, needs to be power8. Patch
> has been
Hi Arthur,
on 2024/6/21 18:17, Arthur Cohen wrote:
> Hi,
>
> Sorry about the delay in my answer! The patch looks good to me :) Will you
> push it as part of your patchset?
>
Thanks for the review! Since this one doesn't necessarily depend on
"09/52 Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
Hi,
Sorry about the delay in my answer! The patch looks good to me :) Will
you push it as part of your patchset?
Kindly,
Arthur
On 6/3/24 05:00, Kewen Lin wrote:
Joseph pointed out "floating types should have their mode,
not a poorly defined precision value" in the discussion[1],
as he and
On 21/06/2024 08:57, Alexandre Oliva wrote:
> On Jun 20, 2024, Christophe Lyon wrote:
>
>> Maybe using
>> if ((unsigned)b[i] >= BITS) \
>> would be clearer?
>
> Heh. Why make it simpler if we can make it unreadable, right? :-D
>
> Thanks, here's another version I've just retested on
On Thu, 20 Jun 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 17 Jun 2024, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Fri, 14 Jun 2024, Richard Biener wrote:
> >> >
> >> >> On Fri, 14 Jun 2024, Richard Sandiford wrote:
> >> >>
> >> >> > Richard
Oops, this patch series actually depends on
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html which
was posted separately, but needs to be applied before 4/4 in this
series.
On Thu, 20 Jun 2024 at 16:35, Jonathan Wakely wrote:
>
> We still have __is_arithmetic in after this,
> but
On Fri, Jun 21, 2024 at 10:50 AM Li, Pan2 wrote:
>
> Thanks Richard for comments.
>
> > to match this by changing it to
>
> > /* Unsigned saturation sub, case 2 (branch with ge):
> >SAT_U_SUB = X >= Y ? X - Y : 0. */
> > (match (unsigned_integer_sat_sub @0 @1)
> > (cond^ (ge @0 @1) (convert?
On Fri, Jun 21, 2024 at 10:21 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > [...]
> > I wonder if you can amend doc/passes.texi, specifically noting differences
> > between fwprop, combine and late-combine?
>
> Ooh, we have a doc/passes.texi? :) Somehow missed that.
Yeah, I also
Pushed to trunk now. I might backport this later too.
On Thu, 20 Jun 2024 at 16:39, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> LWG 3305 was approved earlier this year in Tokyo. We need to give an
> error if using std::any_cast, but std::any_cast is valid
> (but always
Tested x86_64-linux. Pushed to trunk. Probably worth backporting.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (uninitialized_default_construct)
(uninitialized_default_construct_n, uninitialized_value_construct)
(uninitialized_value_construct_n):
I see, it's operator== overloaded.
LGTM.
juzhe.zh...@rivai.ai
From: wangf...@eswincomputing.com
Date: 2024-06-21 17:03
To: juzhe.zhong; gcc-patches
CC: kito.cheng; jinma.contrib
Subject: Re: Re: [PATCH 2/3] RISC-V: Add Zvfbfmin and Zvfbfwma intrinsic
On 2024-06-21 12:24 juzhe.zhong wrote:
Pusahed to trunk now.
On Thu, 20 Jun 2024 at 16:41, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This member function was previously deprecated, but that was reverted by
> P2875R4, approved earlier this year in Tokyo. Since it's not going to be
> deprecated in C++26, and so
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> These were deprecated in C++17 and std::wstring_convert is planned for
> removal in C++26.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/locale_conv.h (wstring_convert):
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/backward/backward_warning.h: Adjust comments to
> suggest as another alternative to .
> * include/backward/strstream
YunQiang Su writes:
> We check gcc_cv_as_mips_explicit_relocs if
> gcc_cv_as_mips_explicit_relocs_pcrel
> only, while gcc_cv_as_mips_explicit_relocs is used by later code.
>
> Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> as it has been in Binutils for more than
Pushed to trunk now.
On Wed, 19 Jun 2024 at 17:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Not pushed yet. backports will be needed too.
>
> -- >8 --
>
> Due to PR c++/85723 the std::is_trivial trait is true for types with a
> deleted default constructor, so the use of std::is_trivial in
Pushed to trunk now. Backport to gcc-14 needed too.
On Thu, 20 Jun 2024 at 16:27, Jonathan Wakely wrote:
>
> This unfortunately means we can never increase __cpp_lib_chrono again
> for the old string ABI, but I don't see any alternative (except
> supporting chrono::tzdb for the old string, which
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a warning from one of the test allocators:
warning: base class 'class std::allocator<__gnu_test::copy_tracker>' should be
explicitly initialized in the copy constructor [-Wextra]
libstdc++-v3/ChangeLog:
*
"Maciej W. Rozycki" writes:
> Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
> with a register, because the value of -1 is actually a valid reference
> to register 0 in the case where it has not been assigned a quantity.
>
> Using -1 makes `REG_QTY (REGNO
Include the invalid path in the error message.
gcc/ada/
* make.adb (Scan_Make_Arg): Adjust error message.
* gnatls.adb (Search_RTS): Likewise.
* switch-b.adb (Scan_Debug_Switches): Likewise.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/gnatls.adb |
From: Eric Botcazou
It occurs when the body of a protected subprogram is processed, because the
references to the components of the type have not been properly expanded.
gcc/ada/
* gcc-interface/trans.cc (Subprogram_Body_to_gnu): Also return early
for a protected subprogram in
From: Javier Miranda
When the interpolated expression is a call to an ambiguous call
the frontend does not reject it; erroneously accepts the call
and generates code that calls to one of them.
gcc/ada/
* sem_ch2.adb (Analyze_Interpolated_String_Literal): Reject
ambiguous
From: Eric Botcazou
We set DECL_BIT_FIELD optimistically during the translation of record types
and clear it afterward if needed, but fail to clear other attributes in the
latter case, which fools the logic of the Address Sanitizer.
gcc/ada/
* gcc-interface/utils.cc
From: Eric Botcazou
This is the minimal fix to avoid the crash.
gcc/ada/
* bcheck.adb (Check_Consistency_Of_Sdep): Guard against path to ALI
file not found.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/bcheck.adb | 10 +++---
1 file changed, 7
On 2024-06-21 12:24 juzhe.zhong wrote:
>
>+ if (*group.shape == shapes::loadstore
>+ || *group.shape == shapes::indexed_loadstore
>+ || *group.shape == shapes::vundefined
>+ || *group.shape == shapes::misc
>+ || *group.shape == shapes::vset
>+ || *group.shape ==
From: Javier Miranda
When a non-overridable aspect is explicitly specified for a
non-tagged derived type, the compiler blows up processing an
object declaration of an object of such type.
gcc/ada/
* sem_ch13.adb (Analyze_One_Aspect): Fix code locating the entity
of the parent
From: Eric Botcazou
The Address Sanitizer considers that the padding at the end of a justified
modular type may be accessed through the object, but it is never accessed
and therefore can always be reused.
gcc/ada/
* gcc-interface/decl.cc (gnat_to_gnu_entity) : Set
the
From: Eric Botcazou
The processing of primitive operations is now always uniform for tagged and
untagged types, but the code contains left-overs from the time where it was
specific to tagged types, in particular for the handling of subtypes.
gcc/ada/
* einfo.ads
From: Ronan Desplanques
gcc/ada/
* sem_util.adb (Examine_Array_Bounds): Add missing return
statements. Fix criterion for a string literal being empty.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_util.adb | 4 +++-
1 file changed, 3 insertions(+), 1
From: Eric Botcazou
This implements modulo reduction for nonbinary modular multiplication with
small moduli by means of the standard division-free algorithm also used in
the optimizer, but with fewer constraints and therefore better results.
For the sake of consistency, it is also used for the
From: Doug Rupp
The conditional installation resulted in a semantic change, and
although it is likely what is ultimately wanted (since HW interrupts
are being reworked on VxWorks). However it must be done in concert
with other modifications for the new formulation of HW interrupts and
not in
From: Eric Botcazou
This occurs when the bounds of the array component depend on a discriminant
and the component reference is not nested, that is to say the component is
not (referenced as) a subcomponent of a larger record.
In this case, Analyze_Selected_Component does not build the actual
From: Bob Duff
The only substantive change is to remove Activation_Chain_Entity
from N_Generic_Package_Declaration. The comment in sinfo.ads suggesting
this change was written in 1993!
Various pieces of missing documentation are added to Sinfo and Einfo.
Also other minor cleanups.
gcc/ada/
From: Eric Botcazou
The Do_Range_Check flag is properly set on the Expression of the EWA node
built for the declare expression, so this instructs Generate_Index_Checks
to look into this Expression.
gcc/ada/
* checks.adb (Generate_Index_Checks): Add specific treatment for
index
From: Javier Miranda
When a package has the declaration of a derived tagged
type T with private null extension that inherits a public
function F with controlling result, and a derivation of T
is declared in the public part of another package, overriding
function F may be rejected by the
From: Eric Botcazou
The assertion fails because the Original_Node of the expression has no Etype
since its an unanalyzed identifier.
gcc/ada/
* accessibility.adb (Accessibility_Level): Apply the processing to
Expr when its Original_Node is an unanalyzed identifier.
Tested on
From: Steve Baird
In some cases, a predefined operator (e.g., the "+" operator for an
integer type) is incorrectly treated as being directly visible when
it is not. This can lead to both accepting operator uses that should
be rejected and also to incorrectly rejecting legal constructs as
From: Eric Botcazou
This adds the missing guard to prevent the reduction from being used when
the target does not provide or cannot synthesize a high-part multiply.
gcc/ada/
* gcc-interface/trans.cc (gnat_to_gnu) : Fix formatting.
* gcc-interface/utils2.cc: Include
From: Eric Botcazou
The problem is that the handling of the interaction between packing and
aliased/atomic/independent components of an array type is tied to that of
the interaction between a component clause and aliased/atomic/independent
components, although the semantics are different:
1 - 100 of 119 matches
Mail list logo
