New Chinese (simplified) PO file for 'gcc' (version 14.2.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Chinese (simplified) team of translators. The file is available at: https://translationproject.org/latest/gcc/zh_CN.po (This file, 'gcc-14.2.0.zh_CN.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: gcc mode switching issue (was Re: RISC-V round_away () handling of non canonical rounding modes)
On Sat, 18 Jan 2025 06:57:22 PST (-0800), jeffreya...@gmail.com wrote:
On 1/16/25 7:31 PM, Li, Pan2 wrote:
It is 627.cam4_s or 527.cam4_r? I can help to reproduce this from k1 board.
I'd also suggest checking the test/train inputs before going to ref.
Ya, and thanks for the help. For anyone else watching, the rest is over here:
https://inbox.sourceware.org/libc-alpha/78a20579-2d29-4b3b-af94-434dde755...@rivosinc.com/
(inbox.sourceware.org doesn't seem to handle threading across lists) --
it certainly looked like a glibc issue at first, so it ended up over
there.
On a sort of related note: last night/this morning I realized that if
calling into glibc with RMM set is UB, then aren't we going to open
ourselves up issues like getting a signal in the middle of an inlined
__builtin_{l,}round() expansion? Maybe fast-math/sigals are far enough
down the rabbit hole nobody cares, though?
jeff
Re: [patch,wwwdocs] Fix typo in gcc-15/changes
On Sat, 18 Jan 2025, Georg-Johann Lay wrote: > Seems in the "extended asm" there is a typo: > > "constraints have been for defining" gives me a syntax error. > The patch also improves punctuation. Looks good to me, thank you! Gerald
[pushed] doc: Move modula2.org link to https
With my changes end of last year I missed this one for modula2.org. That
should be it for now.
Pushed.
Gerald
gcc:
* doc/gm2.texi (Type compatibility): Move modula2.org link
to https.
---
gcc/doc/gm2.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/gm2.texi b/gcc/doc/gm2.texi
index 0bace308d11..5af8b228831 100644
--- a/gcc/doc/gm2.texi
+++ b/gcc/doc/gm2.texi
@@ -1913,7 +1913,7 @@ Expression compatibility is a symmetric relation.
For example two sub expressions of @code{INTEGER} and @code{CARDINAL}
are not expression compatible
-(@uref{http://freepages.modula2.org/report4/modula-2.html} and ISO
+(@uref{https://freepages.modula2.org/report4/modula-2.html} and ISO
Modula-2).
In GNU Modula-2 this rule is also extended across all fixed sized data
--
2.47.1
Re: [PATCH] c++/modules: Propagate FNDECL_USED_AUTO alongside deduced return types [PR118049]
On Fri, Jan 17, 2025 at 11:35:19AM -0500, Patrick Palka wrote:
> On Fri, 17 Jan 2025, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > In the linked testcase, we're erroring because the declared return types
> > of the functions do not appear to match. This is because when merging
> > the deduced return types for 'foo' in 'auto-5_b.C', we overwrote the
> > return type for the declaration with the deduced return type from
> > 'auto-5_a.C' but neglected to track that we were originally declared
> > with 'auto'.
>
> Is this a regression caused by the PR114795 fix? Maybe we should
> backport this.
>
I don't think it's a regression, rather just a case that was missed by
the original fix; the testcase doesn't work without PR114795 fix either.
That said backporting could be reasonable as I feel this is a pretty
safe change.
> >
> > As a drive-by improvement to QOI, also add checks for if the deduced
> > return types do not match; this is currently useful because we do not
> > check the equivalence of the bodies of functions yet.
> >
> > PR c++/118049
> >
> > gcc/cp/ChangeLog:
> >
> > * module.cc (trees_in::is_matching_decl): Propagate
> > FNDECL_USED_AUTO as well.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/modules/auto-5_a.C: New test.
> > * g++.dg/modules/auto-5_b.C: New test.
> > * g++.dg/modules/auto-5_c.C: New test.
> > * g++.dg/modules/auto-6_a.H: New test.
> > * g++.dg/modules/auto-6_b.C: New test.
> >
> > Signed-off-by: Nathaniel Shead
> > ---
> > gcc/cp/module.cc| 5 +
> > gcc/testsuite/g++.dg/modules/auto-5_a.C | 10 ++
> > gcc/testsuite/g++.dg/modules/auto-5_b.C | 14 ++
> > gcc/testsuite/g++.dg/modules/auto-5_c.C | 4
> > gcc/testsuite/g++.dg/modules/auto-6_a.H | 5 +
> > gcc/testsuite/g++.dg/modules/auto-6_b.C | 6 ++
> > 6 files changed, 44 insertions(+)
> > create mode 100644 gcc/testsuite/g++.dg/modules/auto-5_a.C
> > create mode 100644 gcc/testsuite/g++.dg/modules/auto-5_b.C
> > create mode 100644 gcc/testsuite/g++.dg/modules/auto-5_c.C
> > create mode 100644 gcc/testsuite/g++.dg/modules/auto-6_a.H
> > create mode 100644 gcc/testsuite/g++.dg/modules/auto-6_b.C
> >
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index 61116fe7669..6fe64bb538c 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -11902,8 +11902,13 @@ trees_in::is_matching_decl (tree existing, tree
> > decl, bool is_typedef)
> > {
> > dump (dumper::MERGE)
> > && dump ("Propagating deduced return type to %N", existing);
> > + FNDECL_USED_AUTO (e_inner) = true;
> > + DECL_SAVED_AUTO_RETURN_TYPE (existing) = TREE_TYPE (e_type);
> > TREE_TYPE (existing) = change_return_type (TREE_TYPE (d_type),
> > e_type);
> > }
> > + else if (type_uses_auto (d_ret)
> > + && !same_type_p (TREE_TYPE (d_type), TREE_TYPE (e_type)))
> > + goto mismatch;
> > }
> >else if (is_typedef)
> > {
> > diff --git a/gcc/testsuite/g++.dg/modules/auto-5_a.C
> > b/gcc/testsuite/g++.dg/modules/auto-5_a.C
> > new file mode 100644
> > index 000..fcab6f301e1
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/modules/auto-5_a.C
> > @@ -0,0 +1,10 @@
> > +// PR c++/118049
> > +// { dg-additional-options "-fmodules -Wno-global-module" }
> > +// { dg-module-cmi A }
> > +
> > +module;
> > +template struct S {
> > + auto foo() {}
> > +};
> > +export module A;
> > +template struct S;
> > diff --git a/gcc/testsuite/g++.dg/modules/auto-5_b.C
> > b/gcc/testsuite/g++.dg/modules/auto-5_b.C
> > new file mode 100644
> > index 000..f75ed2d0f0c
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/modules/auto-5_b.C
> > @@ -0,0 +1,14 @@
> > +// PR c++/118049
> > +// { dg-additional-options "-fmodules -Wno-global-module" }
> > +// { dg-module-cmi B }
> > +
> > +module;
> > +template struct S {
> > + auto foo() {}
> > +};
> > +template struct S;
> > +export module B;
> > +import A;
> > +template void x() {
> > + S{}.foo();
> > +}
> > diff --git a/gcc/testsuite/g++.dg/modules/auto-5_c.C
> > b/gcc/testsuite/g++.dg/modules/auto-5_c.C
> > new file mode 100644
> > index 000..f351c2b1ae4
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/modules/auto-5_c.C
> > @@ -0,0 +1,4 @@
> > +// PR c++/118049
> > +// { dg-additional-options "-fmodules -fno-module-lazy
> > -fdump-lang-module-alias" }
> > +
> > +import B;
> > diff --git a/gcc/testsuite/g++.dg/modules/auto-6_a.H
> > b/gcc/testsuite/g++.dg/modules/auto-6_a.H
> > new file mode 100644
> > index 000..3ad08ab81ce
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/modules/auto-6_a.H
> > @@ -0,0 +1,5 @@
> > +// { dg-additional-options "-fmodule-header" }
> > +
> > +inline auto foo() {
> > + return 1;
> > +}
> > diff --git a/gcc/testsuite/g++.dg/modules/auto-6_b.C
> > b/gcc/testsuite/g++.dg/modules/auto-6_b.C
> > new file mode 100644
> >
[pushed] doc: Adjust link to OpenMP specifications
Let's hope this remains stable for a bit...
Gerald
gcc:
* doc/extend.texi (OpenMP): Adjust link to specifications.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index dd9a8d2f8ba..b0bb0d47230 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -29395,7 +29395,7 @@ architectures, including Unix and Microsoft Windows
platforms.
It consists of a set of compiler directives, library routines,
and environment variables that influence run-time behavior.
-GCC implements all of the @uref{https://openmp.org/specifications/,
+GCC implements all of the @uref{https://www.openmp.org/specifications/,
OpenMP Application Program Interface v4.5}, and many features from later
versions of the OpenMP specification.
@xref{OpenMP Implementation Status,,,libgomp,
--
2.47.1
[PATCH] Describe inline assembler parsing
From: Andi Kleen
Correct the description of inline assembler to say that gcc does
limited assembler parsing to estimate the length of inline assembler
statements, and document that certain assembler primitives can confuse
it.
gcc/ChangeLog:
* doc/extend.texi: Document assembler parsing heuristics.
---
gcc/doc/extend.texi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b0bb0d47230..4c7c9120863 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10911,9 +10911,16 @@ of an asm}).
@item AssemblerInstructions
This is a literal string that specifies the assembler code. The string can
contain any instructions recognized by the assembler, including directives.
-GCC does not parse the assembler instructions themselves and
+
+GCC only does minimal parsing of the assembler instructions to determine
+how many there are for an conservative estimate of the maximum size of
+the assembler statement for some optimizations, but otherwise
does not know what they mean or even whether they are valid assembler input.
+Assembler primitives that change the number of instructions like @code{.rept}
or
+expanding @code{.macro} macros might confuse these heuristics and should
+be avoided inside functions. For top level assembler they are generally fine.
+
You may place multiple assembler instructions together in a single @code{asm}
string, separated by the characters normally used in assembly code for the
system. A combination that works in most places is a newline to break the
--
2.47.1
Re: [PATCH] Describe inline assembler parsing
On Sat, Jan 18, 2025, 10:46 PM Andi Kleen wrote:
> From: Andi Kleen
>
> Correct the description of inline assembler to say that gcc does
> limited assembler parsing to estimate the length of inline assembler
> statements, and document that certain assembler primitives can confuse
> it.
>
> gcc/ChangeLog:
>
> * doc/extend.texi: Document assembler parsing heuristics.
> ---
> gcc/doc/extend.texi | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index b0bb0d47230..4c7c9120863 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -10911,9 +10911,16 @@ of an asm}).
> @item AssemblerInstructions
> This is a literal string that specifies the assembler code. The string
> can
> contain any instructions recognized by the assembler, including
> directives.
> -GCC does not parse the assembler instructions themselves and
> +
> +GCC only does minimal parsing of the assembler instructions to determine
> +how many there are for an conservative estimate of the maximum size of
> +the assembler statement for some optimizations, but otherwise
> does not know what they mean or even whether they are valid assembler
> input.
This is already described in details in size of an asm section:
https://gcc.gnu.org/onlinedocs/gcc/Size-of-an-asm.html
Maybe just a link to that section is needed here.
>
> +Assembler primitives that change the number of instructions like
> @code{.rept} or
> +expanding @code{.macro} macros might confuse these heuristics and should
> +be avoided inside functions. For top level assembler they are generally
> fine.
> +
> You may place multiple assembler instructions together in a single
> @code{asm}
> string, separated by the characters normally used in assembly code for the
> system. A combination that works in most places is a newline to break the
> --
> 2.47.1
>
>
[PATCH v2 1/2] LoongArch: Simplify using bstr{ins, pick} instructions for and
For bstrins, we can merge it into and3 instead of having a
separate define_insn.
For bstrpick, we can use the constraints to ensure the first source
register and the destination register are the same hardware register,
instead of emitting a move manually.
This will simplify the next commit where we'll reassociate bitwise
and left shift for better code generation.
gcc/ChangeLog:
* config/loongarch/constraints.md (Yy): New define_constriant.
* config/loongarch/loongarch.cc (loongarch_print_operand):
For "%M", output the index of bits to be used with
bstrins/bstrpick.
* config/loongarch/predicates.md (ins_zero_bitmask_operand):
Exclude low_bitmask_operand as for low_bitmask_operand it's
always better to use bstrpick instead of bstrins.
(and_operand): New define_predicate.
* config/loongarch/loongarch.md (any_or): New
define_code_iterator.
(bitwise_operand): New define_code_attr.
(*3): New define_insn.
(*and3): New define_insn.
(3): New define_expand.
(and3_extended): Remove, replaced by the 3rd alternative
of *and3.
(bstrins__for_mask): Remove, replaced by the 4th
alternative of *and3.
(*si3_internal): Remove, already covered by
the *3 and *and3 templates.
---
gcc/config/loongarch/constraints.md | 4 ++
gcc/config/loongarch/loongarch.cc | 12 +
gcc/config/loongarch/loongarch.md | 77 +++--
gcc/config/loongarch/predicates.md | 8 ++-
4 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/gcc/config/loongarch/constraints.md
b/gcc/config/loongarch/constraints.md
index 547d9161445..a7c31c2c4e0 100644
--- a/gcc/config/loongarch/constraints.md
+++ b/gcc/config/loongarch/constraints.md
@@ -292,6 +292,10 @@ (define_constraint "Yx"
"@internal"
(match_operand 0 "low_bitmask_operand"))
+(define_constraint "Yy"
+ "@internal"
+ (match_operand 0 "ins_zero_bitmask_operand"))
+
(define_constraint "YI"
"@internal
A replicated vector const in which the replicated value is in the range
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 3a8e1297bd3..1004b65a1ee 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -6142,6 +6142,8 @@ loongarch_print_operand_reloc (FILE *file, rtx op, bool
hi64_part,
'i' Print i if the operand is not a register.
'L' Print the low-part relocation associated with OP.
'm' Print one less than CONST_INT OP in decimal.
+ 'M' Print the indices of the lowest enabled bit and the highest
+ enabled bit in a mask (for bstr* instructions).
'N' Print the inverse of the integer branch condition for comparison OP.
'Q' Print R_LARCH_RELAX for TLS IE.
'r' Print address 12-31bit relocation associated with OP.
@@ -6268,6 +6270,16 @@ loongarch_print_operand (FILE *file, rtx op, int letter)
output_operand_lossage ("invalid use of '%%%c'", letter);
break;
+case 'M':
+ if (CONST_INT_P (op))
+ {
+ HOST_WIDE_INT mask = INTVAL (op);
+ fprintf (file, "%d,%d", floor_log2 (mask), ctz_hwi (mask));
+ }
+ else
+ output_operand_lossage ("invalid use of '%%%c'", letter);
+ break;
+
case 'N':
loongarch_print_int_branch_condition (file, reverse_condition (code),
letter);
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 1b46e8e4af0..995df1b8875 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -485,7 +485,11 @@ (define_code_iterator any_shift [ashift ashiftrt lshiftrt])
;; This code iterator allows the three bitwise instructions to be generated
;; from the same template.
(define_code_iterator any_bitwise [and ior xor])
+(define_code_iterator any_or [ior xor])
(define_code_iterator neg_bitwise [and ior])
+(define_code_attr bitwise_operand [(and "and_operand")
+ (ior "uns_arith_operand")
+ (xor "uns_arith_operand")])
;; This code iterator allows unsigned and signed division to be generated
;; from the same template.
@@ -1537,23 +1541,37 @@ (define_insn "neg2"
;;
;;
-(define_insn "3"
- [(set (match_operand:X 0 "register_operand" "=r,r")
- (any_bitwise:X (match_operand:X 1 "register_operand" "%r,r")
- (match_operand:X 2 "uns_arith_operand" "r,K")))]
+(define_insn "*3"
+ [(set (match_operand:GPR 0 "register_operand" "=r,r")
+ (any_or:GPR (match_operand:GPR 1 "register_operand" "%r,r")
+ (match_operand:GPR 2 "uns_arith_operand" "r,K")))]
""
"%i2\t%0,%1,%2"
[(set_attr "type" "logical")
(set_attr "mode" "")])
-(define_insn "*si3_internal"
- [(set (match_operand:SI 0 "register_operand" "=r,r")
- (any_bitwise:SI (match_operand:SI 1
Re: [PATCH v3 0/4] Hard Register Constraints
On 1/16/25 1:32 AM, Stefan Schulze Frielinghaus wrote: Conceptually I see the value in being able to being able to specify a specific register in an asm. The single register class constraints found on x86 have effectively given that port that capability, but others which truly general purpose registers files don't have a good way to do this stuff. I think we should look to try and move this forward early in the gcc-16 cycle. You're definitely going to need to update the manual for the new capability. I added some documentation to gcc/doc/extend.texi. Is there some other place I should document this? Not sure how I missed it -- I mostly wanted to walk through the docs once now to make sure I understood the basic premise of the change as well as any already identified problem areas. Do we detect conflicts between a hard register constraint and another constraint which requires a singleton class? That's going to be an error I suspect, but curious if it's handled. That is a good point. Currently I suspect no. I will have a look. Thanks. It's not the most important thing on our plate, but given the way x86 is structured we probably need to do something sensible here. I also worry a bit about non-singleton classes that the target may have added to CLASS_LIKELY_SPILLED_P, though unlike the singleton case, there's at least a chance these will work, albeit potentially generating poor code when an object needs spilling. I also don't think it's terribly common to add non-singleton classes to that set. I'm sure someone will try to implement ABI semantics for asms with calls at some point on top of this infrastructure. It seems to be a persistent thing developers want to do with asms. It always ends in a bit of fireworks either running out of registers in the asm itself or generating crappy code because of all the hard register usages. Not something you need to fix, more a rant about what's likely to happen in the future ;-) Jeff
Re: Ping [PATCH v3 0/3] Match: support additional cases of unsigned scalar arithmetic
On 12/17/24 5:00 AM, Akram Ahmad wrote: Pinging While this was submitted before the stage1 deadline, it seems to have fallen through the cracks on the review side. It's unfortunate, but I'd tend to think it ought to be deferred at this point until the gcc-16 cycle. However, I won't object if Richi or Jakub wants to move it forward now rather than waiting. jeff
Re: [PATCH v3 1/2] RISC-V: Allocate the initial register in the expand phase for the vl of XTheadVector
On 1/17/25 7:37 AM, Jin Ma wrote: Since the parameter vl of XTheadVector does not support immediate numbers, we need to put it in the register in advance. That generates the initial code correctly. PR 116593 gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (function_expander::add_input_operand): Put immediate for vl to GPR for XTheadVector. Generally both patches look reasonable to me and the change is less invasive than going via spec_restriction. How was this tested? The Rivos CI has already picked it up but please still always specify. Thanks. I'm not sure what you mean, but I'll do my best to understand. If you're referring to how to test the logic of this code to ensure it works as intended, it can be quite challenging to explain. Testing this particular code is not straightforward. Even without any specific processing, the predicate "vector_length_operand" still constrains the XTheadVector, and the immediate value for VL will be stored in the register. In this sense, the code itself may seem redundant. I suspect Robin is referring to running the GCC testsuite for regressions. That is standard practice for any patch. Essentially build & run make check before and after your patch and verify there are no new failures. Ideally you'd also verify that your testcase is fixed :-) If you're writing a patch that touches target independent parts of the compiler, then the bar is even higher. You need to bootstrap & regression test such patches on one of the primary platforms such as x86_64, aarch64. Jeff
[PATCH] c++, v2: Handle RAW_DATA_CST in make_tree_vector_from_ctor [PR118528]
On Fri, Jan 17, 2025 at 07:00:33PM -0500, Jason Merrill wrote:
> > --- gcc/c-family/c-common.cc.jj 2025-01-02 11:47:29.803228077 +0100
> > +++ gcc/c-family/c-common.cc2025-01-17 13:32:53.512294482 +0100
> > @@ -9016,9 +9016,26 @@ vec *
> > make_tree_vector_from_ctor (tree ctor)
> > {
> > vec *ret = make_tree_vector ();
> > + unsigned nelts = CONSTRUCTOR_NELTS (ctor);
> > vec_safe_reserve (ret, CONSTRUCTOR_NELTS (ctor));
> > for (unsigned i = 0; i < CONSTRUCTOR_NELTS (ctor); ++i)
> > -ret->quick_push (CONSTRUCTOR_ELT (ctor, i)->value);
> > +if (TREE_CODE (CONSTRUCTOR_ELT (ctor, i)->value) == RAW_DATA_CST)
> > + {
> > + tree raw_data = CONSTRUCTOR_ELT (ctor, i)->value;
> > + nelts += RAW_DATA_LENGTH (raw_data);
> > + vec_safe_reserve (ret, nelts);
>
> I notice that the second argument to vec_safe_reserve is the number of empty
> spaces to provide, rather than the new desired capacity. So this will
> allocate space for an additional copy of the whole constructor.
You're right.
> I guess you want to say reserve (ret, nelts - vec_safe_length (res))? It's
> weird that there isn't a more convenient way to express that.
I think vec_safe_reserve (ret, nelts - ret->length ()); is enough, the first
vec_safe_reserve already necessarily make ret non-NULL because if it would
not have reserved anything (nelts == 0), then there would be no ctor
elements to walk.
> Note that this behavior differs from the C++ standard library, where reserve
> indeed specifies the new capacity. This seems likely to cause a lot of
> confusion (and over-allocation) going forward. And indeed looking through
> exising uses turns up at least two that seem to assume the standard library
> semantics (as well as others that assume the actual semantics).
Which ones did you find?
To me cp/name-lookup,cc (name_lookup::preserve_state)
unsigned length = vec_safe_length (previous->scopes);
vec_safe_reserve (previous->scopes, length * 2);
looks possibly unintended, as it quick_pushes at most length further
elements.
I've so far skimmed just vec_safe_reserve uses in {c-family,c,cp}
subdirectories, there are 26 further vec_safe_reserve and around 500
.reserve or ->reserve cases. Most of the vec_safe_reserve and reserve
calls are on empty vectors so it really doesn't matter which one is which.
So, I wonder if at least during the conversion it wouldn't be best to have
all 3 namings, reserve, reserve_space and reserve_capacity, where the first
one would at runtime assert that length () is 0.
> I wonder about renaming the existing reserve to reserve_space and adding a
> reserve_capacity?
Would it be ok to first handle these PRs (fixed patch below) and go through
the renaming and checking incrementally?
There was another thinko in the patch, nelts += RAW_DATA_LENGTH (raw_data);
would mean again reserving too much, it needs to be nelts += RAW_DATA_LENGTH
(raw_data) - 1, as we don't push the RAW_DATA_CST itself which was already
accounted for, but replace it with RAW_DATA_LENGTH pushes.
So far tested on
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++
RUNTESTFLAGS="dg.exp='embed* class-deduction-aggr*.C explicit*.C pr11853[24]*'"
ok if it passes full bootstrap+regtest?
2025-01-18 Jakub Jelinek
PR c++/118528
* c-common.cc (make_tree_vector_from_ctor): Expand RAW_DATA_CST
elements from the CONSTRUCTOR to individual INTEGER_CSTs.
* g++.dg/cpp/embed-21.C: New test.
* g++.dg/cpp2a/class-deduction-aggr16.C: New test.
--- gcc/c-family/c-common.cc.jj 2025-01-02 11:47:29.803228077 +0100
+++ gcc/c-family/c-common.cc2025-01-17 13:32:53.512294482 +0100
@@ -9016,9 +9016,26 @@ vec *
make_tree_vector_from_ctor (tree ctor)
{
vec *ret = make_tree_vector ();
+ unsigned nelts = CONSTRUCTOR_NELTS (ctor);
vec_safe_reserve (ret, CONSTRUCTOR_NELTS (ctor));
for (unsigned i = 0; i < CONSTRUCTOR_NELTS (ctor); ++i)
-ret->quick_push (CONSTRUCTOR_ELT (ctor, i)->value);
+if (TREE_CODE (CONSTRUCTOR_ELT (ctor, i)->value) == RAW_DATA_CST)
+ {
+ tree raw_data = CONSTRUCTOR_ELT (ctor, i)->value;
+ nelts += RAW_DATA_LENGTH (raw_data) - 1;
+ vec_safe_reserve (ret, nelts - ret->length ());
+ if (TYPE_PRECISION (TREE_TYPE (raw_data)) > CHAR_BIT
+ || TYPE_UNSIGNED (TREE_TYPE (raw_data)))
+ for (unsigned j = 0; j < (unsigned) RAW_DATA_LENGTH (raw_data); ++j)
+ ret->quick_push (build_int_cst (TREE_TYPE (raw_data),
+ RAW_DATA_UCHAR_ELT (raw_data, j)));
+ else
+ for (unsigned j = 0; j < (unsigned) RAW_DATA_LENGTH (raw_data); ++j)
+ ret->quick_push (build_int_cst (TREE_TYPE (raw_data),
+ RAW_DATA_SCHAR_ELT (raw_data, j)));
+ }
+else
+ ret->quick_push (CONSTRUCTOR_ELT (ctor, i)->value);
return ret;
}
--- gcc/testsuite/g++.dg/cpp/embed-21.C.jj 2025-01-17 12:18:00.571912195
+0
[PATCH] c++, v2: Handle RAW_DATA_CST in add_list_candidates [PR118532]
On Fri, Jan 17, 2025 at 09:11:15PM +0100, Jakub Jelinek wrote:
> This is the second bug discovered today with the
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
> hack but then turned into proper testcases where embed-2[23].C FAILed
> since introduction of optimized #embed support and the others when
> optimizing large C++ initializers using RAW_DATA_CST.
>
> The add_list_candidates problem is the same as with
> make_tree_vector_from_ctor, unfortunately it can't call that
> function because it can have those additional artificial arguments
> that need to be pushed earlier.
> When working on the patch, I've also noticed an error where we didn't
> know how to dump RAW_DATA_CST, so I've added support for that too.
Here is updated patch similarly to the PR118528 changes.
Tested so far with
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++
RUNTESTFLAGS="dg.exp='embed* class-deduction-aggr*.C explicit*.C pr11853[24]*'"
2025-01-18 Jakub Jelinek
PR c++/118532
* call.cc (add_list_candidates): Handle RAW_DATA_CST among init_list
elts.
* error.cc (dump_expr_init_vec): Handle RAW_DATA_CST among v elts.
* g++.dg/cpp/embed-22.C: New test.
* g++.dg/cpp/embed-23.C: New test.
* g++.dg/cpp0x/pr118532.C: New test.
* g++.dg/cpp2a/explicit20.C: New test.
--- gcc/cp/call.cc.jj 2025-01-15 18:24:36.135503866 +0100
+++ gcc/cp/call.cc 2025-01-17 14:42:38.201643385 +0100
@@ -4258,11 +4258,30 @@ add_list_candidates (tree fns, tree firs
/* Expand the CONSTRUCTOR into a new argument vec. */
vec *new_args;
- vec_alloc (new_args, nart + CONSTRUCTOR_NELTS (init_list));
+ unsigned nelts = nart + CONSTRUCTOR_NELTS (init_list);
+ vec_alloc (new_args, nelts);
for (unsigned i = 0; i < nart; ++i)
new_args->quick_push ((*args)[i]);
for (unsigned i = 0; i < CONSTRUCTOR_NELTS (init_list); ++i)
-new_args->quick_push (CONSTRUCTOR_ELT (init_list, i)->value);
+if (TREE_CODE (CONSTRUCTOR_ELT (init_list, i)->value) == RAW_DATA_CST)
+ {
+ tree raw_data = CONSTRUCTOR_ELT (init_list, i)->value;
+ nelts += RAW_DATA_LENGTH (raw_data) - 1;
+ vec_safe_reserve (new_args, nelts - new_args->length ());
+ if (TYPE_PRECISION (TREE_TYPE (raw_data)) > CHAR_BIT
+ || TYPE_UNSIGNED (TREE_TYPE (raw_data)))
+ for (unsigned j = 0; j < (unsigned) RAW_DATA_LENGTH (raw_data); ++j)
+ new_args->quick_push (build_int_cst (TREE_TYPE (raw_data),
+RAW_DATA_UCHAR_ELT (raw_data,
+j)));
+ else
+ for (unsigned j = 0; j < (unsigned) RAW_DATA_LENGTH (raw_data); ++j)
+ new_args->quick_push (build_int_cst (TREE_TYPE (raw_data),
+RAW_DATA_SCHAR_ELT (raw_data,
+j)));
+ }
+else
+ new_args->quick_push (CONSTRUCTOR_ELT (init_list, i)->value);
/* We aren't looking for list-ctors anymore. */
flags &= ~LOOKUP_LIST_ONLY;
--- gcc/cp/error.cc.jj 2025-01-10 10:26:37.390685341 +0100
+++ gcc/cp/error.cc 2025-01-17 16:20:44.089508010 +0100
@@ -2289,7 +2289,26 @@ dump_expr_init_vec (cxx_pretty_printer *
FOR_EACH_CONSTRUCTOR_VALUE (v, idx, value)
{
- dump_expr (pp, value, flags | TFF_EXPR_IN_PARENS);
+ if (TREE_CODE (value) == RAW_DATA_CST)
+ for (unsigned i = 0; i < (unsigned) RAW_DATA_LENGTH (value); ++i)
+ {
+ if (TYPE_UNSIGNED (TREE_TYPE (value))
+ || TYPE_PRECISION (TREE_TYPE (value)) > CHAR_BIT)
+ pp_decimal_int (pp, RAW_DATA_UCHAR_ELT (value, i));
+ else
+ pp_decimal_int (pp, RAW_DATA_SCHAR_ELT (value, i));
+ if (i == RAW_DATA_LENGTH (value) - 1U)
+ break;
+ else if (i == 9 && RAW_DATA_LENGTH (value) > 20)
+ {
+ pp_string (pp, ", ..., ");
+ i = RAW_DATA_LENGTH (value) - 11;
+ }
+ else
+ pp_separate_with_comma (pp);
+ }
+ else
+ dump_expr (pp, value, flags | TFF_EXPR_IN_PARENS);
if (idx != v->length () - 1)
pp_separate_with_comma (pp);
}
--- gcc/testsuite/g++.dg/cpp/embed-22.C.jj 2025-01-17 17:06:54.731279618
+0100
+++ gcc/testsuite/g++.dg/cpp/embed-22.C 2025-01-17 16:56:02.499282953 +0100
@@ -0,0 +1,24 @@
+// PR c++/118532
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct S {
+ S (int, int, int);
+#define I8 int, int, int, int, int, int, int, int
+#define I64 I8, I8, I8, I8, I8, I8, I8, I8
+ S (I64, I64, I64, I64, I8);
+};
+
+void
+foo (S &)
+{
+}
+
+int
+main ()
+{
+ S s = {
+#embed __FILE__ limit (264)
+ };
+ foo (s);
+}
--- gcc/testsuite/g++.dg/cpp/embed-23.C.jj 2025-01-17 17:02:17.333105186
+0100
+++ gcc/testsuite/g++.dg/cpp/embed-23.C 2025-01-17 17:02:32
Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures
Am Freitag, dem 17.01.2025 um 15:34 -0800 schrieb Bill Wendling:
> On Fri, Jan 17, 2025 at 3:14 PM Joseph Myers wrote:
> >
> > On Fri, 17 Jan 2025, Qing Zhao wrote:
> >
> > > struct fc_bulk {
> > > ...
> > > struct fs_bulk fs_bulk;
> > > struct fc fcs[] __counted_by(fs_bulk.len);
> > > };
> > >
> > > i.e, the “counted_by” field is in the inner structure of the current
> > > structure of the FAM.
> > > With the current syntax, it’s not easy to extend to support this.
> > >
> > > But with the designator syntax, it might be much easier to be extended to
> > > support this.
> > >
> > > So, Kees and Bill, what’s your opinion on this? I think that it’s better
> > > to have a consistent interface between GCC
> > > and Clang.
> > >
> > > Joseph, what’s your opinion on this new syntax? Shall we support the
> > > designator syntax for counted_by attribute?
> >
> > Designator syntax seems reasonable.
> >
> > I think basic C language design principles here include:
> >
> > * It should be unambiguous in a given context what name space an
> > identifier is to be looked up in. (So you can have designator syntax
> > where the identifier is always looked up as a member of the relevant
> > struct, or use a plain identifier where the semantics are defined that
> > way. But what would be a bad idea would be any attempt to automagically
> > guess whether something that looks like an expression should be
> > interpreted as an expression or with identifiers instead looked up as
> > structure members. If you allow fs_bulk.len above, there should be no
> > possibility of fs_bulk being an ordinary identifier (global variable etc.)
> > - the name lookup rules should mean it's always only looked up as a member
> > of the current structure.)
> >
> > * Don't introduce something "like expression but with different name
> > lookup rules". Designators aren't expressions and have limited syntax.
> > It would be a bad idea to try to e.g. have something allowing arithmetic
> > on designators. For example, don't allow __counted_by(.len1 + .len2)
> > where len1 and len2 are both members, as that's inventing a complete new
> > expression-like-but-not-expression syntactic construct.
> >
> I re-opened the discussion on the LLVM discourse page. There wasn't a
> lot of pushback when it was first brought up, so I suspect that people
> will be generally amenable to it.
>
> https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/131?u=gwelymernans
Thank you!
Martin
[PATCH v2 2/2] LoongArch: Improve reassociation for bitwise operation and left shift [PR 115921]
For things like
(x | 0x101) << 11
It's obvious to write:
ori $r4,$r4,257
slli.d $r4,$r4,11
But we are actually generating something insane:
lu12i.w $r12,524288>>12 # 0x8
ori $r12,$r12,2048
slli.d $r4,$r4,11
or $r4,$r4,$r12
jr $r1
It's because the target-independent canonicalization was written before
we have all the RISC targets where loading an immediate may need
multiple instructions. So for these targets we need to handle this in
the target code.
We do the reassociation on our own (i.e. reverting the
target-independent reassociation) if "(reg [&|^] mask) << shamt" does
not need to load mask into an register, and either:
- (mask << shamt) needs to be loaded into an register, or
- shamt is a const_immalsl_operand, so the outer shift may be further
combined with an add.
gcc/ChangeLog:
PR target/115921
* config/loongarch/loongarch-protos.h
(loongarch_reassoc_shift_bitwise): New function prototype.
* config/loongarch/loongarch.cc
(loongarch_reassoc_shift_bitwise): Implement.
* config/loongarch/loongarch.md
(*alslsi3_extend_subreg): New define_insn_and_split.
(_shift_reverse): New
define_insn_and_split.
(_alsl_reversesi_extended): New
define_insn_and_split.
(zero_extend_ashift): Remove as it's just a special case of
and_shift_reversedi, and it does not make too much sense to
write "alsl.d rd,rs,r0,shamt" instead of "slli.d rd,rs,shamt".
(bstrpick_alsl_paired): Remove as it is already done by
splitting and_shift_reversedi into and + ashift first, then
late combining the ashift and a further add.
gcc/testsuite/ChangeLog:
PR target/115921
* gcc.target/loongarch/bstrpick_alsl_paired.c (scan-rtl-dump):
Scan for and_shift_reversedi instead of the removed
bstrpick_alsl_paired.
* gcc.target/loongarch/bitwise-shift-reassoc.c: New test.
---
v1 -> v2:
- Use simplify_const_binary_operation for shifting CONST_INT rtx,
instead of self-invented code invoking unspecified behavior
- Add a test case outputting bstrins.d + alsl.d
Bootstrapped and regtested on loongarch64-linux-gnu, ok for trunk?
gcc/config/loongarch/loongarch-protos.h | 2 +
gcc/config/loongarch/loongarch.cc | 35 +
gcc/config/loongarch/loongarch.md | 136 +-
.../loongarch/bitwise-shift-reassoc.c | 98 +
.../loongarch/bstrpick_alsl_paired.c | 2 +-
5 files changed, 239 insertions(+), 34 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/bitwise-shift-reassoc.c
diff --git a/gcc/config/loongarch/loongarch-protos.h
b/gcc/config/loongarch/loongarch-protos.h
index 6601f767dab..33fcb5ee87f 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -85,6 +85,8 @@ extern bool loongarch_split_move_p (rtx, rtx);
extern void loongarch_split_move (rtx, rtx);
extern bool loongarch_addu16i_imm12_operand_p (HOST_WIDE_INT, machine_mode);
extern void loongarch_split_plus_constant (rtx *, machine_mode);
+extern rtx loongarch_reassoc_shift_bitwise (bool is_and, rtx shamt,
+ rtx mask, machine_mode mode);
extern void loongarch_split_vector_move (rtx, rtx);
extern const char *loongarch_output_move (rtx *);
#ifdef RTX_CODE
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 1004b65a1ee..51f72390256 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -4530,6 +4530,41 @@ loongarch_split_plus_constant (rtx *op, machine_mode
mode)
op[2] = gen_int_mode (v, mode);
}
+/* Test if reassociate (a << shamt) [&|^] mask to
+ (a [&|^] (mask >> shamt)) << shamt is possible and beneficial.
+ If true, return (mask >> shamt). Return NULL_RTX otherwise. */
+
+rtx
+loongarch_reassoc_shift_bitwise (bool is_and, rtx shamt, rtx mask,
+machine_mode mode)
+{
+ gcc_checking_assert (CONST_INT_P (shamt));
+ gcc_checking_assert (CONST_INT_P (mask));
+ gcc_checking_assert (mode == SImode || mode == DImode);
+
+ if (ctz_hwi (INTVAL (mask)) < INTVAL (shamt))
+return NULL_RTX;
+
+ rtx new_mask = simplify_const_binary_operation (LSHIFTRT, mode, mask,
+ shamt);
+ if (const_uns_arith_operand (new_mask, mode))
+return new_mask;
+
+ if (!is_and)
+return NULL_RTX;
+
+ if (low_bitmask_operand (new_mask, mode))
+return new_mask;
+
+ /* Do an arithmetic shift for checking ins_zero_bitmask_operand:
+ ashiftrt (0x, 2) is 0x6000 which is an
+ ins_zero_bitmask_operand, but lshiftrt will produce
+ 0x3fff6000. */
+ new_mask = simplify_const_binary_operation (ASHIFTRT, mode, mask,
+
Re: [PATCH] RISC-V: Disable fusing vsetvl instructions by VSETVL_VTYPE_CHANGE_ONLY for XTheadVector.
On 1/17/25 5:09 AM, Robin Dapp wrote: In RVV 1.0, the instruction "vsetvli zero,zero,*" indicates that the available vector length (avl) does not change. However, in XTheadVector, this same instruction signifies that the avl should take the maximum value. Consequently, when fusing vsetvl instructions, the optimization labeled "VSETVL_VTYPE_CHANGE_ONLY" is disabled for XTheadVector. LGTM. It's not marked as a regression, but the code correctness aspects here are such that I think this should go in regardless of stage. Pushed to the trunk. jeff
Re: gcc mode switching issue (was Re: RISC-V round_away () handling of non canonical rounding modes)
On 1/16/25 7:31 PM, Li, Pan2 wrote: It is 627.cam4_s or 527.cam4_r? I can help to reproduce this from k1 board. I'd also suggest checking the test/train inputs before going to ref. jeff
Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures
On Fri, Jan 17, 2025 at 01:27:41PM -0800, Bill Wendling wrote:
> On Fri, Jan 17, 2025 at 8:02 AM Qing Zhao wrote:
> > Joseph, Kees and Bill,
> >
> > I need your input on this.
> > > On Jan 17, 2025, at 10:12, Martin Uecker wrote:
> > >
> > > Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao:
> > >>
> > > ..
> > >>
> > >> Although in the previous discussion, I agreed with Martin that we should
> > >> use the
> > >> designator syntax (i.e, counted_by (.n) instead of counted_by (n)) for
> > >> the
> > >> counted_by attribute for pointer fields, after more consideration and
> > >> discussion
> > >> with Bill Wendling (who is working on the same work for CLANG), we
> > >> decided to
> > >> keep the current syntax of FAM for pointer fields. And leave the new
> > >> syntax (.n)
> > >> and more complicate expressions to a later work.
> > >>
> > > I think this would be a mistake. Once you have established the confusing
> > > syntax,
> > > it will not easily go away anymore. So I think you should use the
> > > unambiguous
> > > and future-prove syntax right away. Support for more complicated
> > > expressions
> > > could be left for later, of course.
> >
> > Personally I agree with you. -:)
> >
> > Actually we might need to use such syntax in the very beginning when adding
> > counted_by of FAM.
> > As I know, linux kernel community asked for the following new feature for
> > counted_by of FAM:
> >
> > struct fs_bulk {
> > ...
> > int len;
> > ...
> > }
> >
> > struct fc_bulk {
> > ...
> > struct fs_bulk fs_bulk;
> > struct fc fcs[] __counted_by(fs_bulk.len);
> > };
> >
> > i.e, the “counted_by” field is in the inner structure of the current
> > structure of the FAM.
> > With the current syntax, it’s not easy to extend to support this.
> >
> > But with the designator syntax, it might be much easier to be extended to
> > support this.
> >
> > So, Kees and Bill, what’s your opinion on this? I think that it’s better to
> > have a consistent interface between GCC
> > and Clang.
> >
> > Joseph, what’s your opinion on this new syntax? Shall we support the
> > designator syntax for counted_by attribute?
> >
> I've been thinking more about what we discussed regarding this and I
> have to agree with Martin that putting off using the new syntax for
> both FAMs and pointers will make things worse in the long run. We'll
> already have to deprecate the current syntax in compilers for code
> using the current syntax, but it may not be too late. Linux is pretty
> much the main user of this feature, and we have pretty good control
> over how it's used there.
While it'll take a bit longer, I am convinced as well. It will let us do
things we keep tripping over (like fs_bulk.len example above).
> The one wrinkle is that Apple allows for full expressions, not just a
> field designator---and they're currently using full expressions.
> AFAIK, that code is internal to Apple, but they want to externalize
> it. So we'll eventually have to come up with some sort of plan for how
> to deal with it probably sooner rather than later. I'll open up a
> discussion with them about it.
Gaining access to global variables is another gap Linux has -- e.g. we
have arrays that are sized by the global number-of-cpus variable. :)
--
Kees Cook
Re: [PATCH] RISC-V: Disable RV64-only crc testcases for RV32
On 1/14/25 12:57 AM, Bohan Lei wrote: These testcases require RV64 targets. They fail when -march=rv32* is specified while using an riscv64* compiler. gcc/testsuite/ChangeLog: * gcc.target/riscv/crc-21-rv64-zbc.c: Disallow rv32 targets. * gcc.target/riscv/crc-21-rv64-zbkc.c: Ditto. Thanks. I've pushed this to the trunk. jeff
[to-be-committed][RISC-V][PR target/116308] Fix generation of initial RTL for atomics
While this wasn't originally marked as a regression, it almost certainly
is given that older versions of GCC would have used libatomic and would
not have ICE'd on this code.
Basically this is another case where we directly used
simplify_gen_subreg when we should have used gen_lowpart.
When I fixed a similar bug a while back I noted the code in question as
needing another looksie. I think at that time my brain saw the mixed
modes (SI & QI) and locked up. But the QI stuff is just the shift
count, not some deeper issue. So fixing is trivial.
We just replace the simplify_gen_subreg with a gen_lowpart and get on
with our lives.
Tested on rv64 and rv32 in my tester. Waiting on pre-commit testing for
final verdict.
jeffgcc/
* config/riscv/riscv.cc (riscv_lshift_subword): Use gen_lowpart
rather than simplify_gen_subreg.
testsuite/
gcc.target/;riscv/pr116308.c: New test.
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 9a1db2d2b38..f5e672bb7f5 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -11963,9 +11963,7 @@ riscv_lshift_subword (machine_mode mode, rtx value, rtx
shift,
rtx *shifted_value)
{
rtx value_reg = gen_reg_rtx (SImode);
- emit_move_insn (value_reg, simplify_gen_subreg (SImode, value,
- mode, 0));
-
+ emit_move_insn (value_reg, gen_lowpart (SImode, value));
emit_move_insn (*shifted_value, gen_rtx_ASHIFT (SImode, value_reg,
gen_lowpart (QImode, shift)));
}
diff --git a/gcc/testsuite/gcc.target/riscv/pr116308.c
b/gcc/testsuite/gcc.target/riscv/pr116308.c
new file mode 100644
index 000..241df14bd92
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr116308.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -march=rv64gc -mabi=lp64d" { target rv64 } } */
+/* { dg-options "-Ofast -march=rv32gc -mabi=ilp32" { target rv32 } } */
+
+_Float16 test__Float16_post_inc()
+{
+_Atomic _Float16 n;
+return n++;
+}
https://www.mail-archive.com/
Hello Dear, I hope all is well with you, I need to post my article on your Website= https://www.mail-archive.com/ Can you tell me the price of Guest Post Link Insertion? I am waiting for your good response, Kinds & Regards.
Re: Ping^3 [PATCH] get source line for diagnostic from preprocessed file / PR preprocessor/79106
On 1/3/25 7:27 AM, Bader, Lucas wrote: Hello and Happy New Year, as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79106 is still open, I wanted to again bump this patch I provided a while back. It was earmarked for gcc-11 in https://gcc.gnu.org/pipermail/gcc-patches/2020-January/539201.html but did not make it into the release. Original submission: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg01113.html Please let me know if something is missing. Martin S. is no longer active in GCC development and stuff like input locations tends to fall more towards David M's space. David M probably needs to chime in here (on cc). Jeff
[wwwdocs,applied] More v15 avr news
Applied the patch below that adds more v15 avr news.
Johann
--
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 82a86488..16d20554 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -362,6 +362,28 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
href="https://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html#index-_005f_005fbuiltin_005favr_005fmask1";
>built-in function. It can be used to compute some bit
masks when
code like 1 << offset is not fast
enough.
+ Support has been added for a new 24-bit
+href="https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR-Named-Address-Spaces-1";
+ >named address space __flashx.
+It is similar to the __memx address space introduced
in v4.7,
+but reading is a bit more efficient since it only supports reading from
+program memory. Objects in the __flashx address space are
+located in the .progmemx.data section.
+ Apart from the built-in types __int24 and
+__int24 supported since v4.7, support has been added
for the
+signed __int24 and unsigned __int24
types.
+ Code generation for the 32-bit integer shifts with constant
+offset has been improved. The code size may slightly increase even
+when optimizing for code size with -Os.
+ New target specific optimizations passes have been added.
+They run after register allocation and can be controlled by the new
+command-line options
+href="https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-mfuse-move";
+ >-mfuse-move,
+href="https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-msplit-ldst";
+ >-msplit-ldst and
+href="https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-msplit-bit-shift";
+ >-msplit-bit-shift.
IA-32/x86-64
[PATCH] testsuite: Fixes for test case pr117546.c
This test fails on AVR.
Debugging the test on x86 host, I noticed that u in function s sometimes
has value 16128. The "t <= 3 * u" expression in the same function
results in signed integer overflow for targets with sizeof(int)=16.
Fix by requiring int32 effective target.
Also add return statement for the main function.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr117546.c: Require effective target int32.
(main): Add return statement.
Ok for trunk?
Cc: Sam James
Signed-off-by: Dimitar Dimitrov
---
gcc/testsuite/gcc.dg/torture/pr117546.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/torture/pr117546.c
b/gcc/testsuite/gcc.dg/torture/pr117546.c
index 21e2aef18b9..b60f877a906 100644
--- a/gcc/testsuite/gcc.dg/torture/pr117546.c
+++ b/gcc/testsuite/gcc.dg/torture/pr117546.c
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { target int32 } } */
typedef struct {
int a;
@@ -81,4 +81,6 @@ int main() {
l.glyf.coords[4] = (e){2, 206};
l.glyf.coords[6] = (e){0, 308, 5};
w(&l);
+
+ return 0;
}
--
2.47.1
Re: [PATCH] testsuite: Fixes for test case pr117546.c
Dimitar Dimitrov writes:
> This test fails on AVR.
>
> Debugging the test on x86 host, I noticed that u in function s sometimes
> has value 16128. The "t <= 3 * u" expression in the same function
> results in signed integer overflow for targets with sizeof(int)=16.
>
> Fix by requiring int32 effective target.
Ah, thanks, I should've clocked that, especially because I'd played with
the values quite a bit.
>
> Also add return statement for the main function.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/torture/pr117546.c: Require effective target int32.
> (main): Add return statement.
>
> Ok for trunk?
>
> Cc: Sam James
> Signed-off-by: Dimitar Dimitrov
> ---
I think it can go in as obvious. Thanks for the fixup.
> gcc/testsuite/gcc.dg/torture/pr117546.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr117546.c
> b/gcc/testsuite/gcc.dg/torture/pr117546.c
> index 21e2aef18b9..b60f877a906 100644
> --- a/gcc/testsuite/gcc.dg/torture/pr117546.c
> +++ b/gcc/testsuite/gcc.dg/torture/pr117546.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run } */
> +/* { dg-do run { target int32 } } */
>
> typedef struct {
>int a;
> @@ -81,4 +81,6 @@ int main() {
>l.glyf.coords[4] = (e){2, 206};
>l.glyf.coords[6] = (e){0, 308, 5};
>w(&l);
> +
> + return 0;
> }
[patch,wwwdocs] Fix typo in gcc-15/changes
Seems in the "extended asm" there is a typo:
"constraints have been for defining" gives me a syntax error.
The patch also improves punctuation.
Johann
--
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index a9778659..f38745a4 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -105,9 +105,9 @@ a work-in-progress.
A href="https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-musttail-statement-attribute";>
musttail statement attribute was added to
enforce tail calls.
href="https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html";>Extended
inline assembler statements
-can now be used with some limitations outside of functions as
well, new
-constraints have been for defining symbols or using symbols
inside of inline
-assembler and a new generic operand modifier has been added to
allow
+can now be used with some limitations outside of functions as
well. New
+constraints have been added for defining symbols or using
symbols inside of inline
+assembler, and a new generic operand modifier has been added to
allow
printing those regardless of PIC. For example:
struct S { int a, b, c; };
