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/C
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
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 functio
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/d
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
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
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.
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 anyon
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/
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 eff
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 stateme
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
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::ad
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 objec
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 purpo
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
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.
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
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:
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 Q
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
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
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
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
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);
> > > };
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 sup
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)
> >
27 matches
Mail list logo
