https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #13 from Richard Biener ---
(In reply to JuzheZhong from comment #12)
> OK. It seems it has data dependency issue:
>
> missed: not vectorized, possible dependence between data-refs a[i_15] and
> a[_4]
>
> a[i_15] = _3; STMT 1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
--- Comment #9 from Richard Biener ---
(In reply to Jan Hubicka from comment #8)
> > Honza - ICF seems to fixup points-to sets when merging variables, so there
> > should be a way to kill off flow-sensitive info inside prevailing bodies
> > as
I realized there is 's' constraint which is defined in GCC generic
infra[1], and that's kinda what same as the new semantic of 'S' here,
(define_constraint "s"
"Matches a symbolic integer constant."
(and (match_test "CONSTANT_P (op)")
(match_test "!CONST_SCALAR_INT_P (op)")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #12 from JuzheZhong ---
OK. It seems it has data dependency issue:
missed: not vectorized, possible dependence between data-refs a[i_15] and
a[_4]
a[i_15] = _3; STMT 1
_4 = i_15 + 2;
_5 = a[_4];STMT 2
STMT2 should not
The constraint "S" can only be used with a symbol that binds locally, so
the following does not work for -fpie/-fpic (GOT access is used).
```
namespace ns { extern int var, a[4]; }
void foo() {
asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "S"(::var));
asm(".reloc .,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #11 from JuzheZhong ---
It seems that we should fix this case (Richard gave) first which I think it's
not the SCEV or value-numbering issue:
double a[1024];
void foo ()
{
for (int i = 0; i < 1022; i += 2)
{
double tem =
Hi,
I asked in https://sourceware.org/bugzilla/show_bug.cgi?id=31109
> I prepared a patch for the releases/gcc-13 branch.
> Richard Biener rejected my patch for
this branch.
> Which branch should I use? master, trunk or something else?
Do you really need gprofng in the gcc repo ?
if yes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113531
--- Comment #2 from Jason Merrill ---
Reduced:
#include
void f(int) { }
void g()
{
for (auto i : { 1, 2, 3 })
f (i);
f(42);
}
int main()
{
g();
g();
}
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
Since my r14-1500-g4d935f52b0d5c0 we promote an initializer_list backing
array to static storage where appropriate, but this happens after we decided
to add it to asan_poisoned_variables. As a result we add unpoison/poison
for it to the gimple.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
在 2024-01-31 08:08, Jonathan Yong 写道:
On 1/24/24 15:17, Matteo Italia wrote:
Ping! That's a one-line fix, and you can find all the details in the bugzilla entry. Also, I can
provide executables built with the affected toolchains, demonstrating the problem and the fix.
Thanks,
Matteo
I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394
--- Comment #2 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:d826596acb02edf41ac4f76af2aed5efa3b8c698
commit r14-8643-gd826596acb02edf41ac4f76af2aed5efa3b8c698
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
--- Comment #8 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:320fb976e933e8892af905e68de65492568f2a49
commit r14-8642-g320fb976e933e8892af905e68de65492568f2a49
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
--- Comment #5 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:320fb976e933e8892af905e68de65492568f2a49
commit r14-8642-g320fb976e933e8892af905e68de65492568f2a49
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113091
Feng Xue changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote:
> On 12/5/23 20:52, Lewis Hyatt wrote:
> > Hello-
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
> >
> > There are two related issues here really, a regression since GCC 11 where we
> > can ICE after restoring a PCH, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
Bug ID: 113678
Summary: SLP misses up vec_concat
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Changes in v2:
1. Check decl non-null before dereferencing it.
2. Update PR rtl-optimization/113617 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617#c14
---
For a private COMDAT function symbol reference in readonly data section,
instead of putting it in .data.rel.ro or .rodata.cst
---
gcc/doc/extend.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0bc586d120e7..1d413b0ef6d1 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9867,6 +9867,22 @@ foo (int x, int y)
@code{y} is not actually
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
---
gcc/c/c-parser.cc | 61 +--
gcc/c/c-tree.h| 2 +-
gcc/c/c-typeck.cc | 15 ++--
3 files changed, 63 insertions(+), 15
Mostly adopted from the existing C musttail plugin tests.
---
gcc/testsuite/c-c++-common/musttail1.c | 17
gcc/testsuite/c-c++-common/musttail2.c | 36 +
gcc/testsuite/c-c++-common/musttail3.c | 31 +
- Give error messages for all causes of non sibling call generation
- Don't override choices of other non sibling call checks with
must tail. This causes ICEs. The must tail attribute now only
overrides flag_optimize_sibling_calls locally.
- Error out when tree-tailcall failed to mark a must-tail
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
Fixed all earlier review comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
Andrew Pinski changed:
What|Removed |Added
Target|x86_64 |x86_64 aarch64
--- Comment #2 from
From: Pan Li
This patch would like to cleanup some comments which are out of date or
incorrect.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Cleanup comments.
(riscv_pass_by_reference): Ditto.
(riscv_fntype_abi): Ditto.
Signed-off-by: Pan Li
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
Bug ID: 113677
Summary: Missing `VEC_PERM_EXPR <{a, CST}, CST, {0, 1, 2,
...}>` optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #10 from JuzheZhong ---
I think the root cause is we think i_16 and _1 are alias due to scalar
evolution:
(get_scalar_evolution
(scalar = i_16)
(scalar_evolution = {0, +, 2}_1))
(get_scalar_evolution
(scalar = _1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911
Joseph S. Myers changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059
Joseph S. Myers changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE:
C front-end bugs 111059 and 111911 both report ICEs with conversions
to boolean of expressions with integer constant operands that can
appear in an integer constant expression as long as they are not
evaluated (such as division by zero).
The issue is a nested C_MAYBE_CONST_EXPR, with the inner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911
--- Comment #7 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:35de88e2ed0aa78f6e3306c8560cd6bb15ce0ffe
commit r14-8641-g35de88e2ed0aa78f6e3306c8560cd6bb15ce0ffe
Author: Joseph Myers
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059
--- Comment #6 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:35de88e2ed0aa78f6e3306c8560cd6bb15ce0ffe
commit r14-8641-g35de88e2ed0aa78f6e3306c8560cd6bb15ce0ffe
Author: Joseph Myers
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
Keywords|
Avoid ICE with -fanalyzer-verbose-state-changes when
region_model::get_representative_tree returns nullptr in
state_change_event::get_desc.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-8640-g18aabe7d203aa1.
gcc/analyzer/ChangeLog:
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113509
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:18aabe7d203aa1276e6cbacfb3ffc8d8fcb14966
commit r14-8640-g18aabe7d203aa1276e6cbacfb3ffc8d8fcb14966
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
Bug ID: 113676
Summary: Miscompilation tree-vrp __builtin_unreachable
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #33 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9dd10de15b183f7b662905e1383fdc3a08755f2e
commit r14-8639-g9dd10de15b183f7b662905e1383fdc3a08755f2e
Author: Juzhe-Zhong
Date: Mon Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #12 from Andrew
On 1/24/24 15:17, Matteo Italia wrote:
Ping! That's a one-line fix, and you can find all the details in the
bugzilla entry. Also, I can provide executables built with the affected
toolchains, demonstrating the problem and the fix.
Thanks,
Matteo
I was away last week. LH, care to comment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
Fangrui Song changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Tue, Jan 16, 2024 at 11:47 PM Uros Bizjak wrote:
>
> On Thu, Jan 11, 2024 at 7:24 PM Fangrui Song wrote:
> >
> > Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> > mangled name). Similar constraints are available in other targets (e.g.
> > "S" for aarch64/riscv, "Cs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
--- Comment #10 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:d7250100381b817114447d91fff4748526d4fb21
commit r14-8637-gd7250100381b817114447d91fff4748526d4fb21
Author: Fangrui Song
Date: Thu
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts
code. This note is an admonishing reminder to convert the Concepts TS
code to C++20 Concepts.
gcc/c-family/ChangeLog:
* c-opts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113675
--- Comment #3 from Andrew Pinski ---
Actually the issue is not %p but rather the constraint. Anyways it is still a
dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113675
--- Comment #2 from Andrew Pinski ---
That is %z was in the process of being reviewed and added:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642580.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113675
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113675
Bug ID: 113675
Summary: %p modifier doesn't work with PIC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #22 from Andrew Pinski ---
(In reply to Robin Dapp from comment #19)
> What seems odd to me is that in fre5 we simplify
>
> _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911
Joseph S. Myers changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059
Joseph S. Myers changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #21 from Andrew Pinski ---
(In reply to JuzheZhong from comment #20)
> Does ARM SVE have the same issue too ? Since I think we should be using same
> folding optimization as ARM SVE.
I could not reproduce it with SVE, see comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #20 from JuzheZhong ---
(In reply to Robin Dapp from comment #19)
> What seems odd to me is that in fre5 we simplify
>
> _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
--- Comment #13 from Lewis Hyatt ---
I think I understand why it is platform dependent. The location being assigned
to the restored macros is pfile->directive_line, which was stored relative to
the original line map instance, before replacing
std::filesystem::hard_link_count() always returns 1 on
mingw-w64ucrt-11.0.1-r3 on Windows 10 19045
hard_link_count() queries _wstat64() on MinGW-w64
The MSFT documentation claims _wstat64() will always return 1 *non*-NTFS volumes
On Tue, Jan 30, 2024 at 12:25:24PM +, Jonathan Wakely via Gcc wrote:
> On Tue, 30 Jan 2024, 10:35 Amol Surati via Gcc, wrote:
>
> > Hello,
> >
> > If a std attribute name is squeezed between 4x underscores,
> >
>
> Which is undefined behaviour, but shouldn't crash.
>
> the compiler (both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
Marek Polacek changed:
What|Removed |Added
Summary|[[attr]] causes |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
Bug ID: 113674
Summary: [[attr]] causes internal compiler error: in
decl_attributes, at attribs.cc:776
Product: gcc
Version: 14.0
Status: UNCONFIRMED
On 30/01/24 15:02 +, Jonathan Wakely wrote:
That way other subdirectories could add their own extra generated files to it.
Like so.
mklog: Add lookup for generated files in specific sub-directories
The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
LGTM.
Regards
Robin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #19 from Robin Dapp ---
What seems odd to me is that in fre5 we simplify
_429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
... });
vect_prephitmp_129.51_282 = _429;
vect_iftmp.55_287 = VEC_COND_EXPR ;
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
while your patch addresses ENw.dE0
Sam James writes:
> [[PGP Signed Part:Undecided]]
>
> Sam James writes:
>
>> Sam James writes:
>>
>>> Dimitry Andric writes:
>>>
Ping. It would be nice to get this QoL fix in.
>>>
>>> Yes please - we've been using this in Gentoo since around when it was
>>> first posted. No
Applied, this adds 6 more devices, 2 new and 4 fairly old
for completeness.
Johann
--
AVR: Add AVR64DU and some older devices.
gcc/
* config/avr/avr-mcus.def: Add AVR64DU28, AVR64DU32, ATA5787,
ATA5835, ATtiny64AUTO, ATA5700M322.
* doc/avr-mmcu.texi: Rebuild.diff --git
On Tue, 30 Jan 2024, 15:03 Jonathan Wakely, wrote:
> OK for trunk?
>
> -- >8 --
>
> The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
> Teaching mklog.py that it's generated makes it correctly use
> "Regenerate" for its changes. We can do the same for the other new
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113671
--- Comment #2 from anlauf at gcc dot gnu.org ---
Another reduced variant:
program arrays10
implicit none
character(5), allocatable :: a(:)
character(:), allocatable :: b(:)
a = [ character(5) :: "one", "two", "three"]
b = [
> I think removing the is_inorder attribute should be ok. I added it
> because I wanted to avoid having two matching insn reservations
> defined since matching solely on the type attribute should also match
> on all subsets as well (i.e. if eventually we add an insn reservation
> checking for type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113509
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
/repo/gcc-trunk//binary-trunk-r14-8635-20240130094253-g24d5e0bf19f-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240130 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113509
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
--- Comment #4 from Lennox Ho ---
Oh right, thanks for pointing that out.
Let me try to put something together.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113671
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111881
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-01-30
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return
NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes,
using TImode causes simplify_gen_subreg to return NULL.
This fixes the issue by using DImode instead for the loop. And then we will have
later on the STP/LDP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #18 from Marek Polacek ---
Should be. Let me know if some are still not fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113672
Bug ID: 113672
Summary: [14 Regression] FAIL: g++.dg/pch/line-map-3.C -g -I.
-Dwith_PCH (test for excess errors)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #6 from Jakub Jelinek ---
Created attachment 57265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57265=edit
gcc14-pr113656.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #17 from Patrick J. LoPresti ---
Are all of the "duplicate" bugs also fixed by this change?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110358
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f2061b2a9641c2228d4e2d86f19532ad7e93d627
commit r14-8636-gf2061b2a9641c2228d4e2d86f19532ad7e93d627
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f2061b2a9641c2228d4e2d86f19532ad7e93d627
commit r14-8636-gf2061b2a9641c2228d4e2d86f19532ad7e93d627
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113531
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Last
On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote:
> On 1/25/24 20:36, Marek Polacek wrote:
> > Better version:
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Real-world experience shows that -Wdangling-reference triggers for
> >
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
My editor judiciously deleted trailing blank spaces in a number of
places. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #6 from Jakub Jelinek ---
But then vnresult->result of (what is correctly believed to be in *i at the
start of the function) is different from rhs of and so it doesn't return
res;
So, I'm afraid I don't know what's going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #5 from Jakub Jelinek ---
This vn_reference_lookup_2 call from vn_reference_lookup_3 has been added for
PR23094 in r8-4877-gd7a160a45ea7ed09.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #4 from Jakub Jelinek ---
(In reply to Richard Biener from comment #2)
> Hmm, so we look for a *(int **) here, reach the toplevel vop, skipping *j =
> ?
> That should have conflicted.
Seems we actually saw that.
On Mon, 29 Jan 2024 11:38:12 PST (-0800), e...@rivosinc.com wrote:
Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #25 from Alex Coplan ---
Proposed fix for GCC 13:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644459.html
From: Takayuki 'January June' Suwa
gcc/ChangeLog:
* config/xtensa/constraints.md (R, T, U):
Change define_constraint to define_memory_constraint.
* config/xtensa/predicates.md (move_operand): Don't check that a
constant pool operand size is a multiple of
Bootstrapped/regtested on aarch64-linux-gnu, OK for the 13 branch after
a week of the trunk fix being in? OK for the other active branches if
the same changes test cleanly there?
GCC 14 patch for reference:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/61.html
Thanks,
Alex
-- >8
1 - 100 of 477 matches
Mail list logo
