On Thu, Jul 20, 2023 at 10:42:29AM -0400, Jason Merrill wrote:
> On 7/20/23 05:35, Nathaniel Shead wrote:
> > This adds rudimentary lifetime tracking in C++ constexpr contexts,
> > allowing the compiler to report errors with using values after their
> > backing has gone out of scope. We don't yet
On Fri, Jul 21, 2023 at 3:00 AM Jason Merrill wrote:
>
> On 7/20/23 05:37, Nathaniel Shead wrote:
> > This patch updates 'input_location' during constant evaluation to ensure
> > that errors in subexpressions that lack location information still
> > provide accurate diagnostics.
> >
> > By itself
On Fri, Jul 21, 2023 at 05:44:51PM -0400, Jason Merrill wrote:
> On 7/21/23 01:39, Nathaniel Shead wrote:
> > On Thu, Jul 20, 2023 at 11:46:47AM -0400, Jason Merrill wrote:
> > > On 7/20/23 05:36, Nathaniel Shead wrote:
> > > > Currently, when typeck discovers that a return statement will refer to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
That looks like the only thing that changed between GCC 12 and GCC 13 for
crtbeginT.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #5 from Andrew Pinski ---
Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
On 7/21/23 09:16, Siddhesh Poyarekar wrote:
The test deliberately reads beyond bounds to exersize ubsan and the
return value may be anything, based on previous allocations. The OFF
test caters for it by ANDing the return with 0, do the same for the DYN
test.
gcc/testsuite/ChangeLog:
On 7/21/23 18:38, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
-- >8 --
This code in cxx_eval_array_reference has been hard to get right.
In r12-2304 I added some code; in r13-5693 I removed some of it.
Here the problematic line is "S s = arr[0];" which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #4 from Julian Waters ---
My mistake, I forgot to mention that it was indeed inside a function body. I
can't seem to figure out what in parser.cc is causing this bug, anything on
your end?
On Wed, Jul 19, 2023 at 4:12 PM Alexandre Oliva via Gcc-patches
wrote:
>
> On Jul 18, 2023, Richard Biener wrote:
>
> > I think the __symver__ attribute does something similar already so
> > maybe use __attribute__((__sym__("foo")))?
>
> Cool, thanks, that will do. Regstrapped on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52628
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90656
--- Comment #1 from Andrew Pinski ---
I suspect this has been fixed already via PR 91269 / PR 91854 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88556
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88502
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
On Tue, Aug 17, 2021 at 1:43 AM Sebastian Huber
wrote:
>
> abort() is used in gcc_assert() and gcc_unreachable() which is used by target
> libraries such as libgcov.a. This patch changes the abort() definition under
> certain conditions. If inhibit_libc is defined and abort is not already
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
Bug ID: 110775
Summary: arm-openwrt-linux-uclibcgnueabi bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #5 from Brian Bi ---
Partial ordering is different from partial specialization. Partial ordering
selects a best viable function in certain cases where two viable functions are
both instantiated from templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #4 from Andrew Pinski ---
But these function declarations are not partial specializations as far as I
know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #3 from Andrew Pinski ---
Take:
```
template
struct A { typedef char* type; };
template char* f1(T, char*); // #1
template long* f1(T*, typename A::type*); // #2
char *t;
char **t1;
long* p0;
long *p1 = f1(p0, t1); // choses #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #2 from Andrew Pinski ---
Actually 0 vs nullptr is the same:
```
template
struct A { typedef char* type; };
template char* f1(T, char*); // #1
template long* f1(T*, typename A::type*); // #2
long* p1 = f1(p1, nullptr); // #3
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #1 from Andrew Pinski ---
The literal 0 is the issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
Bug ID: 110774
Summary: Ambiguous partial ordering with non-dependent function
parameter type
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords:
The following patch fixes sparc solaris bootstrap. The explanation of
the patch is in the commit message.
The patch was successfully bootstrap on x86-64, aarch64, and sparc64
solaris.
commit d17be8f7f36abe257a7d026dad61e5f8d14bdafc
Author: Vladimir N. Makarov
Date: Fri Jul 21 20:28:50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #4 from Andrew Pinski ---
Note 10.5.0 was the last release in the GCC 10.x series, can you test out GCC
11.4.0 out?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #2 from Andrew Pinski ---
I am trying to understand what you think is wrong here?
lsrsr3, r3, #7
means logical shift right by 7 and compare against 0.
Also this is big-endian arm so the order of bit fields will be different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Bug ID: 110773
Summary: [Aarch64] crash (SIGBUS) due to atomic instructions on
under-aligned memory
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
GCC maintainers:
Version 5, Fixed patch description, the first argument should be of
type vector. Fixed comment in vsx.md to say "Vector and scalar
extract_elt iterator/attr ". Removed a few of the changes in
version 4. Specifically, reverted the names of REPLACE_ELT_V_sh back
to
GCC maintainers:
Version 2: Updated a number of formatting and spacing issues. Added
the NARGS description to the header comment for function find_instance.
This patch was tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
with no regressions.
The rs6000 function find_instance assumes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-08-06 00:00:00 |2023-7-21
--- Comment #5 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #1 from Roland Illig ---
Created attachment 55599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55599=edit
precompiled code that works as intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Bug ID: 110772
Summary: strange code generated for bit-field access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
GCC maintianers:
Version 2. Both patches have been updated the first patch was approved
with minor issues to be fixed. I will post the updated version as
version 2 for completeness of the series. There were a few changes
with the second patch as well. The second patch has not been approved
On Mon, 17 Jul 2023, Michael Matz via Gcc-patches wrote:
> So, essentially you want unignorable attributes, right? Then implement
> exactly that: add one new keyword "__known_attribute__" (invent a better
> name, maybe :) ), semantics exactly as with __attribute__ (including using
> the same
On Fri, 2023-07-21 at 13:04 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/7/18 03:20, Carl Love wrote:
> > GCC maintainers:
> >
> > Version 4, changed the new RS6000_OVLD_VEC_REPLACE_UN case
> > statement
> > rs6000/rs6000-c.cc. The existing REPLACE_ELT iterator name was
> > changed
> > to
On Fri, 2023-07-21 at 10:19 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/7/18 03:19, Carl Love wrote:
> > GCC maintainers:
> >
> > The rs6000 function find_instance assumes that it is called for
> > built-
> > ins with only two arguments. There is no checking for the actual
> > number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81558
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-21
Add a new linemap reason LC_GEN which enables encoding the location of data
that was generated during compilation and does not appear in any source file.
There could be many use cases, such as, for instance, referring to the content
of builtin macros (not yet implemented, but an easy lift after
Currently, the tokens obtained from a destringified _Pragma string do not get
assigned proper locations while they are being lexed. After the tokens have
been obtained, they are reassigned the same location as the _Pragma token,
which is sufficient to make things like _Pragma("GCC diagnostic
The diagnostics routines for SARIF output need to read the source code back
in, so that they can generate "snippet" and "content" records, so they need to
be able to cope with generated data locations. Add support for that in
diagnostic-format-sarif.cc.
gcc/ChangeLog:
*
Class edit_context handles outputting fixit hints in diff form that could be
manually or automatically applied by the user. This will not make sense for
generated data locations, such as the contents of a _Pragma string, because
the text to be modified does not appear in the user's input files. We
Hello-
This is an update to the v2 patch series last sent in January:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609473.html
While I did not receive any feedback on the v2 patches yet, they did need some
rebasing on top of other recent commits to input.cc, so I thought it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> So reading the original bug report, it is almost definitely an incorrectly
> reduced testcase.
Oops, yes, sorry for not noticing that before filling the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
--- Comment #1 from Andrew Pinski ---
3) optimize_size logic is now different. Originally we started duplicating
iff the first conditional was known to be true by ranger query, but then
we used same limits as for -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #13 from Andrew Pinski ---
You could also look at how aarch64 implemented a similar thing (not just for
-0.0 but for many other constants too):
r8-2248-ga217096563e356fa03c .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110727
--- Comment #2 from Thiago Jung Bauermann
---
Thanks! I confirmed that I can't reproduce the problem anymore in trunk.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
-- >8 --
This code in cxx_eval_array_reference has been hard to get right.
In r12-2304 I added some code; in r13-5693 I removed some of it.
Here the problematic line is "S s = arr[0];" which causes a crash
on the assert in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #8 from Maxim Egorushkin ---
It was supposed to be one comment, but I kept clicking "save changes" button
because it provided no visual feedback that the comment was being posted.
Snapshot gcc-12-20230721 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20230721/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #7 from Maxim Egorushkin ---
> Can you provide the preprocessed source? Since I can't seem to reproduce it
> with the above.
It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to
trigger the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #6 from Maxim Egorushkin ---
> Can you provide the preprocessed source? Since I can't seem to reproduce it
> with the above.
It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to
trigger the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #5 from Andrew Pinski ---
(In reply to Maxim Egorushkin from comment #3)
> The original correct reproduction:
>
> #include
> #include
>
> void g(int);
>
> void f() {
> std::vector threads(1);
> threads[0] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #4 from Maxim Egorushkin ---
Full context: https://github.com/max0x7ba/atomic_queue/issues/55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
On Fri, 2023-07-21 at 17:35 +0200, Benjamin Priour wrote:
> Hi,
>
> Upon David's request I've joined the in progress patch to the below
> email.
> I hope it makes more sense now.
>
> Best,
> Benjamin.
Thanks for posting the work-in-progress patch; it makes the idea
clearer.
Some thoughts about
On 7/21/23 01:39, Nathaniel Shead wrote:
On Thu, Jul 20, 2023 at 11:46:47AM -0400, Jason Merrill wrote:
On 7/20/23 05:36, Nathaniel Shead wrote:
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #12 from Vineet Gupta ---
> void znd(double *d) { *d = -0.0; }
> void znf(float *f) { *f = -0.0; }
The rough approach I'm thinking of is to
(1) Introduce a constraint for -0.0 and perhaps a predicate as well for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #11 from Vineet Gupta ---
There's a variation which can be optimized as well and seems non trivial to
implement
Now it is the negative constant -0.0 to be stored to mem. In bit notation this
has a single sign bit set thus can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110742
--- Comment #15 from Thiago Jung Bauermann
---
Thanks! I confirmed that I can't reproduce the problem anymore in trunk.
Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
changed the compiler error message in this testcase from
: In instantiation of 'void foo() [with T = int]':
:14:11: required from here
:8:22: error: 'int' is not a class, struct, or union type
:8:22: error: 'int' is not a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #10 from Vineet Gupta ---
The fix for handling +0.0 is posted to list - really trivial.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625217.html
Your site is far too bright and is absolutely painful to the eyes, I
have a simple invert style that I expected to work on all sites and I
found your site is undertaking the vile act of blocking user styles. I
expect that sort of rotten design from microsoft & apple (which
ironically don't), not
P1642 includes the header cstdarg to the freestanding implementation.
This was probably left out by accident, this patch puts it in.
Since this is one of the headers that go in whole cloth, there should be no
further actions needed.
This might be related to PR106953, but since that one touches the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #2 from Andrew Pinski ---
So reading the original bug report, it is almost definitely an incorrectly
reduced testcase.
On 7/21/23 15:16, Andreas Schwab wrote:
../../gcc/config/riscv/riscv.cc: In function 'void riscv_option_override()':
../../gcc/config/riscv/riscv.cc:6716:7: error: misspelled term 'can not' in
format; use 'cannot' instead [-Werror=format-diag]
6716 | "Current RISC-V GCC can not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #1 from Andrew Pinski ---
hmm, this code seems like undefined code. If I change 1 to 2 as you are
accessing 2 elements via operator[], there is no warning ...
The warning seems correct and even says 1 bounds is above the array
../../gcc/config/riscv/riscv.cc: In function 'void riscv_option_override()':
../../gcc/config/riscv/riscv.cc:6716:7: error: misspelled term 'can not' in
format; use 'cannot' instead [-Werror=format-diag]
6716 | "Current RISC-V GCC can not support VLEN > 4096bit for 'V'
Extension");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
--- Comment #4 from Harris Hancock ---
Created attachment 55597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55597=edit
Reduced example which reproduces the ICE
I'm attaching the reduced example from Vitali's first Compiler Explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
Harris Hancock changed:
What|Removed |Added
CC||harris.hancock at gmail dot com
---
> On Jul 21, 2023, at 7:21 AM, Martin Uecker via Gcc-patches
> wrote:
>
>
>
> This patch adds a warning for allocations with insufficient size
> based on the "alloc_size" attribute and the type of the pointer
> the result is assigned to. While it is theoretically legal to
> assign to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
Andrew Pinski changed:
What|Removed |Added
Summary|ICE on valid code at -O3 on |[14 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
Andrew Pinski changed:
What|Removed |Added
Depends on||110641
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
On 7/21/23 14:34, Patrick Palka wrote:
(This is a follow-up of
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html)
Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look?
-- >8 --
The previous fix doesn't work for partially instantiated ttps primarily
because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770
Andrew Pinski changed:
What|Removed |Added
Target||bpf
Severity|normal
On 7/21/23 10:57, Ben Boeckel wrote:
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
On 7/19/23 20:47, Ben Boeckel wrote:
But it is inhibiting distributed builds because the distributing tool
would need to know:
- what CMIs are actually imported (here, "read the module mapper
On 7/21/23 10:57, Ben Boeckel wrote:
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
On 7/19/23 20:47, Ben Boeckel wrote:
But it is inhibiting distributed builds because the distributing tool
would need to know:
- what CMIs are actually imported (here, "read the module mapper
On Thu, 2023-07-06 at 16:43 +0200, priour...@gmail.com wrote:
> As per David's suggestion.
> - Improved leading comment of "is_placement_new_p"
> - "kf_operator_new::matches_call_types_p" now checks that arg 0 is of
> integral type and that arg 1, if any, is of pointer type.
> - Changed
On 7/20/23 16:45, Rainer Orth wrote:
Hi Vladimir,
The following patch is necessary for porting avr to LRA.
The patch was successfully bootstrapped and tested on x86-64, aarch64, and
ppc64le.
There is still avr poring problem with reloading of subreg of frame
pointer. I'll address it later
The asmgoto feature requires LRA support.
Committed to trunk. Tested on hppa64-hp-hpux11.11.
Dave
---
Require target lra in gcc.c-torture/compile/asmgoto-6.c
2023-07-21 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/asmgoto-6.c: Require target lra.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110771
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110756
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669
--- Comment #11 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:cfe53af09364d94fb86013f85ef598a1d47e0657
commit r14-2721-gcfe53af09364d94fb86013f85ef598a1d47e0657
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699
--- Comment #2 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:cfe53af09364d94fb86013f85ef598a1d47e0657
commit r14-2721-gcfe53af09364d94fb86013f85ef598a1d47e0657
Author: Roger Sayle
Date: Fri
On 7/21/23 11:31, Palmer Dabbelt wrote:
IIUC the pattern to emit fmv suffers from the same bug -- it's fixed
in the same
way, but I think we might be able to come up with a test for it:
`fmv.d.x FREG,
x0` would be the fastest way to generate 0.0, so maybe something like
double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110771
Bug ID: 110771
Summary: [14 regression] g++.dg/gomp/pr58567.C fails after
r14-2655-g92d1425ca78040
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110757
--- Comment #2 from Martin Jambor ---
The second slow-down of 4.5% was caused by r14-2546-g061f74c06735e1:
061f74c06735e1fa35b910ae0bcf01b61a74ec23 is the first bad commit
commit 061f74c06735e1fa35b910ae0bcf01b61a74ec23
Author: Jan Hubicka
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 3063e71c8906..b3be65d3efae 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -946,8 +946,8 @@ Objective-C and Objective-C++ Dialects}.
>>
>> @emph{eBPF Options}
>> @gccoptlist{-mbig-endian -mlittle-endian
Hi,
In the current GCC13 release note, the URL to the option -fstrict-flex-array
is wrong (pointing to -Wstrict-flex-array).
This is the change to correct the URL and also add the URL in another place
where -fstrict-flex-array is mentioned.
I have checked the resulting HTML file, works well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770
--- Comment #1 from CVS Commits ---
The master branch has been updated by Cupertino Miranda :
https://gcc.gnu.org/g:77d0f9ec3809b4d2e32c36069b6b9239d301c030
commit r14-2720-g77d0f9ec3809b4d2e32c36069b6b9239d301c030
Author: Cupertino Miranda
On 7/21/23 11:31, Palmer Dabbelt wrote:
On Fri, 21 Jul 2023 10:55:52 PDT (-0700), Vineet Gupta wrote:
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to
optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770
Bug ID: 110770
Summary: bpf: add pseudoc assembly dialect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On 7/21/23 12:31, Palmer Dabbelt wrote:
(define_expand "len_mask_gather_load"
[(match_operand:VNX1_QHSD 0 "register_operand")
- (match_operand 1 "pmode_reg_or_0_operand")
+ (match_operand:P 1 "pmode_reg_or_0_operand")
(match_operand:VNX1_QHSDI 2 "register_operand")
1 - 100 of 275 matches
Mail list logo
