> > I think keeping it untranslated is fine for now. Any translation
> > if really needed would be a separate feature.
>
> I mean, unless you make extra effort, it is translated.
> Even in your current version, try constexpr *foo () { return "nop"; }
> and you'll see that it actually results in "\
Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
Date: Tue, 9 Jan 2024 21:02:44 +0100
Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
From: Björn Schäpers
Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
In that case, you an call either GetModuleHandeExA or
GetModuleHandeExW, the diff
Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor:
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote:
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian L
On 3/6/24 3:27 AM, Kewen.Lin wrote:
> on 2024/3/4 02:55, jeevitha wrote:
>> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>>
>> When we expand the __builtin_vsx_splat_2di function, we were
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this gives vld1 the "pure"
attribute instead, and solve
Dear all,
as there has been some good progress in the handling of optional dummy
arguments, I looked again at this PR and a patch for it that I withdrew
as it turned out incomplete.
It turned out that it now needs only a minor adjustment for optional
dummy arguments of procedures with bind(c) at
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
Hi Mikael,
On 3/15/24 17:31, Mikael Morin wrote:
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler run
On Fri, Mar 15, 2024 at 06:57:18PM +0100, Martin Jambor wrote:
> --- a/gcc/ipa-param-manipulation.cc
> +++ b/gcc/ipa-param-manipulation.cc
> @@ -1525,6 +1525,22 @@ ipa_param_body_adjustments::common_initialization
> (tree old_fndecl,
>replacement with a constant (for split aggr
Hi,
when the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the
On Fri, Mar 15, 2024 at 10:20:06AM -0700, Andi Kleen wrote:
> > One issue is the character set question. The strings in inline asm right
> > now are untranslated, i.e. remain in SOURCE_CHARSET, usually UTF-8 (in
> > theory there is also UTF-EBCDIC support, but nobody knows if it actually
> > works
On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote:
> On 3/8/24 12:02, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Consider
> >
> >constexpr int VAL = 1;
> >struct foo {
> >template
> >void bar(type
Hi Mikael,
On 3/15/24 17:31, Mikael Morin wrote:
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler runtime error messages (also simpler to parse by a
Thanks Jakub.
> > +/* Parse a string literal or constant expression yielding a string.
> > + The constant expression uses extra parens to avoid ambiguity with "x"
> > (expr).
> > +
> > + asm-string-expr:
> > + string-literal
> > + ( constant-expr ) */
> > +
> > +static tree
> > +cp_pa
On Fri, 15 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> While for __mulbitint3 we actually don't negate anything and perform the
> multiplication in unsigned style always, for __divmodbitint4 if the operands
> aren't unsigned and are negative, we negate them first and then try to
> negate them as nee
On 15/03/2024 13:56, Tobias Burnus wrote:
Hi Andrew,
Andrew Stubbs wrote:
This is more-or-less what I was planning to do myself, but as I want
to include all the other features that get parametrized in gcn.cc,
gcn.h, gcn-hsa.h, gcn-opts.h, I hadn't got around to it yet.
Unfortunately, I think
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler runtime error messages (also simpler to parse by a human)
are superior to awkward solutions. This is
On Fri, 15 Mar 2024, Marek Polacek wrote:
> On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote:
> > On Tue, 5 Mar 2024, Marek Polacek wrote:
> >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > Here we ICE because we call register_local_spe
Hi!
As mentioned in the PR, the new testcase FAILs on sparc*-* due to
lack of support of misaligned store.
This patch restricts that to vect_hw_misalign targets.
Tested on x86_64-linux -m32/-m64, committed to trunk based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431#c21 comment.
2024-0
On Fri, 15 Mar 2024 at 12:15, Victor Do Nascimento
wrote:
>
> Given how, at present, the choice of using LSE128 atomic instructions
> by the toolchain is delegated to run-time selection in the form of
> Libatomic ifuncs, responsible for querying target support, the
> `+lse128' target architecture
On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote:
> On Tue, 5 Mar 2024, Marek Polacek wrote:
>
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Here we ICE because we call register_local_specialization while
> > local_specializations is null, so
>
Hello,
"Richard Earnshaw (lists)" writes:
> On 13/01/2024 20:46, Thiago Jung Bauermann wrote:
>> diff --git a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
>> b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
>> index 5b7774825442..da283a06a54d 100644
>> --- a/gcc/testsuite/gcc.targ
On Tue, 5 Mar 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Here we ICE because we call register_local_specialization while
> local_specializations is null, so
>
> local_specializations->put ();
>
> crashes on null this. It's null si
On Mar 13, 2024, at 15:19, Qing Zhao wrote:
On Mar 11, 2024, at 13:15, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/tes
Hi Andrew,
Andrew Stubbs wrote:
This is more-or-less what I was planning to do myself, but as I want
to include all the other features that get parametrized in gcn.cc,
gcn.h, gcn-hsa.h, gcn-opts.h, I hadn't got around to it yet.
Unfortunately, I think the gcn.opt and config.gcc will always nee
Fixes: acc38ff59976 ("MIPS: Add -m(no-)strict-align option")
gcc/ChangeLog:
* config/riscv/riscv.opt.urls: Regenerated.
* config/rs6000/sysv4.opt.urls: Likewise.
* config/xtensa/xtensa.opt.urls: Likewise.
---
gcc/config/riscv/riscv.opt.urls | 2 +-
gcc/config/rs6000/sys
> > + if (POINTER_TYPE_P (TREE_TYPE (t1)))
> > +{
> > + if (SSA_NAME_PTR_INFO (t1))
> > + {
> > + if (!SSA_NAME_PTR_INFO (t2)
> > + || SSA_NAME_PTR_INFO (t1)->align != SSA_NAME_PTR_INFO (t2)->align
> > + || SSA_NAME_PTR_INFO (t1)->misalign != SSA_NAME_PTR_INFO
> > (
On 15/03/2024 12:21, Tobias Burnus wrote:
Given the large number of AMD GPU ISAs and the number of files which
have to be adapted, I wonder whether it makes sense to consolidate this
a bit, especially in the light that we may want to support more in the
future.
Besides using some macros, I al
On Fri, Jun 04, 2021 at 06:02:27PM +, Andreas Krebbel via Gcc wrote:
> Hi,
>
> I wonder if we could replace the register asm construct for
> inline assemblies with something a bit nicer and more obvious.
> E.g. turning this (real world example from IBM Z kernel code):
>
> int diag8_response(i
On Fri, Mar 15, 2024 at 12:24 PM Andrew Stubbs wrote:
>
> On 15/03/2024 07:35, Richard Biener wrote:
> > On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
> >>
> >> On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
> >>>
> >>> Don't enable excess lanes when inverting vector bit-masks smalle
OK for trunk?
-- >8 --
The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
Refer to both forms by name, rather than using "the former" for one and
referring to the other by name.
gcc/ChangeLog:
* doc/invoke.texi (Diagnostic Message Formatting Options):
Replace hy
Given the large number of AMD GPU ISAs and the number of files which
have to be adapted, I wonder whether it makes sense to consolidate this
a bit, especially in the light that we may want to support more in the
future.
Besides using some macros, I also improved the diagnostic if the object
c
On 15/03/2024 07:35, Richard Biener wrote:
On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
Don't enable excess lanes when inverting vector bit-masks smaller than the
integer mode. This is yet another case of wrong-code due to mishand
Hi Chung-Lin!
I realized: please add "PR libgomp/92840" to the Git commit log, as your
changes are directly a continuation of my earlier changes.
On 2024-03-05T01:18:28+0900, Chung-Lin Tang wrote:
> On 2023/10/31 11:06 PM, Thomas Schwinge wrote:
>>> @@ -691,15 +694,27 @@ goacc_exit_datum_1 (str
Hi!
When backporting r14-9315 to 13 branch, I've noticed I've missed
one letter in a comment. And grepping for similar issues I found
one word with too many.
Committed to trunk as obvious.
2024-03-15 Jakub Jelinek
* lower-subreg.cc (resolve_simple_move): Fix comment typo,
be
Given how, at present, the choice of using LSE128 atomic instructions
by the toolchain is delegated to run-time selection in the form of
Libatomic ifuncs, responsible for querying target support, the
`+lse128' target architecture compile-time flag is absent from GCC.
This, however, contrasts with
Ping!
Kind regards,
Torbjörn
On 2024-03-08 10:14, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-22 09:51, Torbjorn SVENSSON wrote:
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:21, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport 3cbab07b08d2f3a3ed34b6ec12e67727c59d
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Given that this is a regression, is this okay for gcc 13 and mainline?
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup structure. That data structure
assumes that is c
On Thu, Jan 25, 2024 at 04:18:19AM -0800, Andi Kleen wrote:
> Some programing styles use a lot of inline assembler, and it is common
> to use very complex preprocessor macros to generate the assembler
> strings for the asm statements. In C++ there would be a typesafe alternative
> using templates a
Hi YunQiang Su,
On Fri, Mar 15, 2024 at 03:33:28PM +0800, YunQiang Su wrote:
> Great work. The CI works well now: it blames me ;)
> https://builder.sourceware.org/buildbot/#/builders/269/builds/3846
>
> When I add '-mstrict-align' option to MIPS,
> the riscv.opt.urls, sysv4.opt.urls, xtensa.opt.u
On 15/03/2024 03:45, Hongtao Liu wrote:
On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
Don't enable excess lanes when inverting vector bit-masks smaller than the
integer mode. This is yet another case of wrong-code due to mishandling
of oversized bitmasks.
This issue shows up in vect/
On Fri, Mar 15, 2024 at 9:50 AM Jakub Jelinek wrote:
>
> Hi!
>
> In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
> comparison against CONST_VECTOR. As the comments say:
> /* x <= cst can be handled as x < cst + 1 unless there is
> wrap around in cst + 1.
Hi!
On Thu, Mar 14, 2024 at 04:58:41PM +, Jonathan Wakely wrote:
> Add the [[nodiscard]] attribute to several functions in .
r14-9478 added [[nodiscard]] to various APIs including find_if
the pr104601.C testcase uses. As it is an optimization bug fix testcase,
haven't tried to adjust the te
On Fri, 15 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The x86-64 and aarch64 psABIs (and the unwritten ia64 psABI part) say that
> the padding bits of _BitInt are undefined, while the expansion internally
> typically assumes that non-mode precision integers are sign/zero extended
> and extends afte
Hi!
In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
comparison against CONST_VECTOR. As the comments say:
/* x <= cst can be handled as x < cst + 1 unless there is
wrap around in cst + 1. */
...
/* For LE punt if some element is sign
Hi!
The x86-64 and aarch64 psABIs (and the unwritten ia64 psABI part) say that
the padding bits of _BitInt are undefined, while the expansion internally
typically assumes that non-mode precision integers are sign/zero extended
and extends after operations. We handle that mismatch with EXTEND_BITI
Hi!
While for __mulbitint3 we actually don't negate anything and perform the
multiplication in unsigned style always, for __divmodbitint4 if the operands
aren't unsigned and are negative, we negate them first and then try to
negate them as needed at the end.
quotient is negated if just one of the
Committed below as obvious. The } got lost in my copy from the internal system.
Sorry for the inconvinience.
--
gcc/testsuite/ChangeLog:
PR testsuite/114343
* gcc.dg/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:
Added missing } in the dg-bogus comment.
Si
Added diagnostics for build_invoke.
Ok for 15?
-- >8 --
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
* semantics.cc (trait_expr_value
On Fri, Mar 15, 2024 at 6:20 AM Andi Kleen wrote:
>
> Andrew Pinski writes:
>
> > On Thu, Mar 14, 2024 at 9:36 PM Andi Kleen wrote:
> >>
> >>
> >> musttail support for C/C++
> >>
> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643867.html
> >>
> >>
> >> Support constexpr for asm stat
On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
>
> On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
> >
> > Don't enable excess lanes when inverting vector bit-masks smaller than the
> > integer mode. This is yet another case of wrong-code due to mishandling
> > of oversized bitmasks.
>
Great work. The CI works well now: it blames me ;)
https://builder.sourceware.org/buildbot/#/builders/269/builds/3846
When I add '-mstrict-align' option to MIPS,
the riscv.opt.urls, sysv4.opt.urls, xtensa.opt.urls are changed also.
(why they are effected?
So what's the best practice for this case
Consolidated most patches into one for easier review and added
documentation for all missing built-in traits.
Ok for trunk?
-- >8 --
This patch arranges pre-existing built-in traits alphabetically for
better codebase consistency and easier future integration of changes.
gcc/ChangeLog:
PR c++/87343
gcc/ChangeLog:
* doc/extend.texi (Expression-yielding Type Traits): New
subsection.
(Type-yielding Type Traits): Likewise.
(C++ Concepts): Move __is_same to ...
(Expression-yielding Type Traits): ... here.
(__has_unique_object_r
On Thu, 14 Mar 2024, Jan Hubicka wrote:
> > > We have wrong code with LTO, too.
> >
> > I know.
> >
> > > The problem is that IPA passes (and
> > > not only that, loop analysis too) does analysis at compile time (with
> > > value numbers in) and streams the info separately.
> >
> > And that is
54 matches
Mail list logo
