https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106460
--- Comment #1 from Jiu Fu Guo ---
The ice occur when output rtx "(high:DI (symbol_ref:DI ("var_48")..))) to
constant pool.
This rtx is generated at function "recog_for_combine"(in combine.cc) after
invoking "force_const_mem".
This kind of rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106460
Bug ID: 106460
Summary: internal compiler error: output_operand: invalid
expression as operand on -O1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
[PATCH 5/5] Support IEEE 128-bit overload test data built-in functions.
This patch adds support for overloading the IEEE 128-bit test data and
test data negate built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
[PATCH 4/5] Support IEEE 128-bit overload extract and insert built-in functions.
This patch adds support for overloading the IEEE 128-bit extract and
insert built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults
PATCH 3/5] Support IEEE 128-bit overload comparison built-in functions.
This patch adds support for overloading the IEEE 128-bit comparison
built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long
[PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in functions.
This patch adds support for overloading the IEEE 128-bit round to odd
built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults to using
[PATCH 1/5] IEEE 128-bit built-in overload support.
This patch lays the ground work that future patches will use to add
builtin support (both normal and overloaded) for the case where long
double uses the IEEE 128-bit encoding.
This adds a new stanza (ieee128-hw-ld) for when we have IEEE 128-bit
The following patches add support for doing built-in function overloading
between the two 128-bit IEEE types (i.e. _Float182/__float128 using KFmode and
when long double uses the IEEE 128-bit encoding with TFmode).
These patches lay the foundation for a set of follow-on patches that will
change
This patch adds the additional options on RISC-V target.
"-fprefetch-loop-arrays" option needs enable prefetch instruction,
for RISC-V that contained in "zicbop" extension.
Use "-march" with "zicbop" will enable this feature.
gcc/testsuite/ChangeLog:
* gcc.dg/pr106397.c: New
在 2022/7/26 下午8:01, Xi Ruoyao 写道:
On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:
在 2022/7/26 下午5:44, Xi Ruoyao 写道:
Should we indicate that our .eh_frame section format has changed?
I don't really understand C++ exception handling, so: does the change
breaks something? For example,
We already have a warning that warns about pessimizing std::move
in a return statement, when it prevents the NRVO:
T fn()
{
T t;
return std::move (t); // warning \o/
}
However, the warning doesn't warn when what we are returning is a class
prvalue, that is, when std::move prevents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
--- Comment #5 from Andrew Pinski ---
It might also be:
#define IMM16_OPERAND(VALUE) \
((unsigned HOST_WIDE_INT) (VALUE) + 0x8000 < 0x1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
--- Comment #4 from Andrew Pinski ---
I suspect it is this macro which is causing the issue:
/* True if VALUE can be loaded into a register using LU12I. */
#define LU12I_OPERAND(VALUE) \
(((VALUE) | ((1UL << 31) - IMM_REACH)) == ((1UL <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
Andrew Pinski changed:
What|Removed |Added
Component|c++ |target
--- Comment #3 from Andrew
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.
I'd expect this patch also to add tests verifying that u8"" strings have
the old type for C11 (unless there
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
> index bfcfdf664c7..75ed7965689 100644
> --- a/gcc/ginclude/stdatomic.h
> +++ b/gcc/ginclude/stdatomic.h
> @@ -49,6 +49,10 @@ typedef _Atomic long atomic_long;
> typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
cqwrteur changed:
What|Removed |Added
Component|other |c++
--- Comment #2 from cqwrteur ---
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
--- Comment #1 from cqwrteur ---
It does not crash on linux host but crash on windows host.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
Bug ID: 106459
Summary: Compiler crashing for loongarch64-linux-gnu on windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
> require that the target diagnostic option be enabled for the preprocessor
> (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170
--- Comment #17 from cqwrteur ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.
case $target in
riscv*)
# do not use locking as pthread depends on libatomic
;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170
--- Comment #16 from cqwrteur ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.
make[4]: Leaving directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99860
--- Comment #2 from David Malcolm ---
Quoting Paul Eggert here:
https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00066.html
> I looked into this a bit more, and it turns out that GCC was wrong
> about
> what happens when some
On Tue, 19 Jul 2022, Maciej W. Rozycki wrote:
> Our documentation indicates that it is the `-frounding-math' invocation
> option that controls whether we respect what the FENV_ACCESS pragma
> would imply, should we implement it, regarding the floating point
> environment. It is only a part of
On Tue, Jul 19, 2022 at 02:09:46PM +, Qing Zhao wrote:
> [...]
> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
> index c8d96723f4c..10d16532f0d 100644
> --- a/gcc/c-family/c-attribs.cc
> +++ b/gcc/c-family/c-attribs.cc
> @@ -101,6 +101,8 @@ static tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106430
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
Summary|[modules] ICE on function |[modules] ICE on function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
Bug 106358 depends on bug 106204, which changed state.
Bug 106204 Summary: False positive from -Wanalyzer-use-of-uninitialized-value
with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
Bug 106358 depends on bug 106225, which changed state.
Bug 106225 Summary: False positives from -Wanalyzer-tainted-divisor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106225
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106225
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
I've backported the following patches to the releases/gcc-12 branch:
r12-8631-g1321183a13540b:
"analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility"
from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074
r12-8632-g05530fcea07a9e:
"analyzer: handle repeated accesses after init of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106225
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by David Malcolm
:
https://gcc.gnu.org/g:71a4f739c218746df70612eeb844024d1fe206bb
commit r12-8638-g71a4f739c218746df70612eeb844024d1fe206bb
Author: David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by David Malcolm
:
https://gcc.gnu.org/g:09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77
commit r12-8637-g09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77
Author: David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #13 from CVS Commits ---
The releases/gcc-12 branch has been updated by David Malcolm
:
https://gcc.gnu.org/g:05530fcea07a9ee5c7501867f3f11f0fbc504a06
commit r12-8632-g05530fcea07a9ee5c7501867f3f11f0fbc504a06
Author: David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by David Malcolm
:
https://gcc.gnu.org/g:1321183a13540b5c3503586b94c758198471c7b3
commit r12-8631-g1321183a13540b5c3503586b94c758198471c7b3
Author: David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105842
--- Comment #6 from Joe Loser ---
(In reply to Patrick Palka from comment #5)
> Fixed for GCC 12.2/13
Thanks for the fix, Patrick!
Hi!
On Wed, Jul 27, 2022 at 02:42:25PM +0100, Roger Sayle wrote:
> This patch implements some additional zero-extension and sign-extension
> related optimizations in simplify-rtx.cc. The original motivation comes
> from PR rtl-optimization/71775, where in comment #2 Andrew Pinski sees:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
> _Complex int are strange beasts, I'd simply avoid the transform for them.
>
>
I added to the match.pd rule to not simplify if the operands are complex.
There is now a test case for complex types to make sure they do not
simplify. I had to move the "dg-do run" test to g++.dg to accommodate the
On 7/27/22 21:45, Harald Anlauf via Fortran wrote:
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
May I suggest that, if well known Fortran
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
If somebody else convinces me to accept that NAG has it wrong this
time, I would be happy to proceed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #3 from John David Anglin ---
Created attachment 53366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53366=edit
.s file generated with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #2 from John David Anglin ---
Created attachment 53365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53365=edit
.s file generated with gcc-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #1 from John David Anglin ---
Created attachment 53364
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53364=edit
.i file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
Bug ID: 106458
Summary: [12 Regression] glibc's malloc/tst-scratch_buffer.c
test is miscompiled with gcc-12
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
Bug ID: 106457
Summary: array_at_struct_end_p returns TRUE for a two-dimension
array which is not inside any structure
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Hi Xionghu,
Yes, I'm pretty sure both of the fixes you mentioned are applicable to GCC 10.
I'm not sure what the bar is for backporting fixes.
Jan, can you comment on that?
The fixes that Xionghu mentioned are:
Fix indirect call inlining with AutoFDO
On Wed, Jul 27, 2022 at 08:51:58AM +0100, Roger Sayle wrote:
> > They can be, as clearly documented (and obvious from the code), but you
> can
> > not ever have that in the RTL stream, which is needed for your patch to do
> > anything.
>
> That's the misunderstanding; neither this nor the
On 7/12/22 08:13, Jose E. Marchesi via Gcc-patches wrote:
>
> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
> annotation reflecting the linkage of functions (static, global). For
> whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
> instead of
Hi Jan,
Thank you for your reply. I did have you on the TO line in my latest patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html
That's the patch I need a review on.
I'm looking forward to co-maintaining AutoFDO with you.
Thanks,
Eugene
-Original Message-
From: Jan
I merged trunk revision 5eb9f117a361538834b9740d59219911680717d1 to
the gccgo branch.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106415
--- Comment #6 from Undefined Opcode ---
(In reply to Kewen Lin from comment #5)
> At the top of tree-ssa-loop-ivopts.cc file, there are some useful comments
> describing the costs for iv candidate itself and group, it may help.
>
> :
> cand
Hi David,
Thank you for your offer to take on the responsibility of maintaining the
AutoFDO-specific portions of the code. I'll be happy to do that with Jan's and
other GGC maintainers' help.
I hope more people will start using and contributing to AutoFDO.
Thanks,
Eugene
-Original
ChangeLog:
* MAINTAINERS: Add myself as reviewer for CTF and BTF.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7408396471f..1a37f4419b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -267,6 +267,7 @@ arc port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #37 from Iain Sandoe ---
(In reply to Eric Gallager from comment #36)
> Note that the solution to this has caused downstream MacPorts bug 65236:
> https://trac.macports.org/ticket/65236
the macports ticket does not contain enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106298
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-07-27
Assignee|dmalcolm
On Mon, 11 Jul 2022, Lewis Hyatt via Gcc-patches wrote:
> Hello-
>
> As discussed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
>
> Here is another short patch that improves "#pragma GCC diagnostic" handling.
> Longer term, it will be desirable to make the handling of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #36 from Eric Gallager ---
Note that the solution to this has caused downstream MacPorts bug 65236:
https://trac.macports.org/ticket/65236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #30 from Andrew Pinski ---
*** Bug 106456 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106456
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106456
--- Comment #1 from Andrew Pinski ---
Wunreachable-code
Common Ignore Warning
Does nothing. Preserved for backward compatibility.
On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
wrote:
> This is the initial version 1 patch set for the Rust front-end. There
> are more changes that need to be extracted out for all the target
> hooks we have implemented. The goal is to see if we are implementing
> the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448
--- Comment #2 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #1)
> is incorrectly accepted in C and rejected in C++.
I mean is correctly rejected in C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448
--- Comment #1 from Jakub Jelinek ---
int x;
void
bar (void)
{
#pragma omp atomic
x = (x + 6);
#pragma omp atomic
x = (x * 6);
}
is incorrectly accepted in C and rejected in C++.
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-20T14:46:03+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-13T10:42:44+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-05T16:59:23+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-20T14:44:36+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-13T10:41:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-05T16:58:54+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093
--- Comment #2 from Florian Weimer ---
It seems that
auto x = 1.0;
will change meaning in C2X (as implemented by GCC) and use type double instead
of int for x. We are probably way too late to fix this (by rejecting the
construct in earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449
--- Comment #7 from Tobias Burnus ---
Comment on attachment 53362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362
gcc13-pr106449.patch
The code does not seem to work. If I add:
void foobar(int *a, int*b) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106455
--- Comment #4 from Andreas Schwab ---
bool > bool is evaluated as (int)bool > (int)bool.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106455
--- Comment #3 from David Binderman ---
(In reply to Andrew Pinski from comment #1)
> bool > bool works just fine and is exactly what we want to test here.
Confused. So is false > true or true > false ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106455
--- Comment #2 from Andreas Schwab ---
negative && !other_negative is definitely easier to understand than negative >
other_negative. In fact, given the condition negative != other_negative,
negative already implies !other_negative, so this
On Thu, Jul 21, 2022 at 11:53 AM H.J. Lu wrote:
>
> We can't always use the PLT entry as the function address for local IFUNC
> functions. When the PIC register is needed for PLT call, indirect call
> via the PLT entry will fail since the PIC register may not be set up
> properly for indirect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106455
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449
--- Comment #6 from Tobias Burnus ---
Comment on attachment 53362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362
gcc13-pr106449.patch
> + t = fold_convert (sizetype, fd->loops[i + 1].n1);
> + t =
On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva wrote:
>
>
> g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed,
> have made it clear that there were problems in the optimizations to
> use @GOTOFF to refer to locally-bound ifuncs. GNU ld as recently as
> May 2018 would reject
On Fri, Jul 1, 2022 at 8:31 AM Uros Bizjak wrote:
>
> On Thu, Jun 30, 2022 at 4:50 PM H.J. Lu wrote:
> >
> > 1. Add a predicate for constant vectors which can be converted to integer
> > constants suitable for constant integer stores. For a 8-byte constant
> > vector, the converted 64-bit
This reference has been wrong since 2007; committed as an obvious fix.
gcc/ChangeLog:
* doc/loop.texi: Refer to LOOPS_HAVE_RECORDED_EXITS instead.
diff --git a/gcc/doc/loop.texi b/gcc/doc/loop.texi
index
d7b71a24dbfed284b13da702bd5037691a515535..6e8657a074d2447db7ae9b75cbfbb71282b84287
A restored build has been detected on builder gccrust-bootstrap-debian-amd64
while building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/107/builds/48
Build state: build successful
Revision: 961468ed824a7b49f10ed597ba9dcc98177125ca
Worker: bb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106456
Bug ID: 106456
Summary: -Wunreachable-code seems very broken
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
On 27/07/2022 14:40, herron.philip--- via Gcc-patches wrote:
From: Philip Herron
This adds the nessecary target hooks for the arm target.
gcc/ChangeLog:
* config.gcc: add rust_target_objs for arm
gcc/config/arm/ChangeLog:
* arm-protos.h: define arm_rust_target_cpu_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106455
Bug ID: 106455
Summary: bad style: comparatives over booleans ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Hi Richard,
On 27/07/22 12:28 pm, Richard Biener wrote:
> On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc
> wrote:
>> To fix the issue of insns being assigned different cycles, there are two
>> possible solutions:
>>
>> 1. Modify no_real_insns_p() to treat a DEBUG insn as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449
--- Comment #5 from Jakub Jelinek ---
Created attachment 53362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362=edit
gcc13-pr106449.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
Bug 106003 depends on bug 106286, which changed state.
Bug 106286 Summary: fd_diagnostic should implement get_meaning_for_state_change
vfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106286
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106286
Immad Mir changed:
What|Removed |Added
CC||mir at gcc dot gnu.org
Hi all,
Tomorrow meeting will cancel since there are few new topics to discuss.
The next meeting will be two weeks later, and we are collecting the themes.
If you have any questions want to discuss please mail me and I will add it
into
the agenda for next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106286
--- Comment #2 from CVS Commits ---
The master branch has been updated by Immad Mir :
https://gcc.gnu.org/g:0f82c0ea8d86ee3bb404c460a04ff2ccfb56d2a0
commit r13-1860-g0f82c0ea8d86ee3bb404c460a04ff2ccfb56d2a0
Author: Immad Mir
Date: Wed Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #10 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > So for which pseudo and which hard register did this ICE, and what did the
> > code look like at that
This patch implements some additional zero-extension and sign-extension
related optimizations in simplify-rtx.cc. The original motivation comes
from PR rtl-optimization/71775, where in comment #2 Andrew Pinski sees:
Failed to match this instruction:
(set (reg:DI 88 [ _1 ])
(sign_extend:DI
From: Philip Herron
This patch introduces a new set of interfaces to define the target info as
expected by the rust front-end. It takes advantage of the information
within gcc/config/target directories which gets called by the front-end
to populate rust front-end datastructures by calling into:
From: Philip Herron
This adds the nessecary target hooks for the arm target.
gcc/ChangeLog:
* config.gcc: add rust_target_objs for arm
gcc/config/arm/ChangeLog:
* arm-protos.h: define arm_rust_target_cpu_info
* arm-rust.cc: new file to generate info
* arm.h:
From: Philip Herron
This is a skeleton front-end which is used so we can ensure each patch is
buildable:
gcc/rust/ChangeLog:
* Make-lang.in
* config-lang.in
* lang-specs.h
* lang.opt
* rust-lang.cc
* rustspec.cc
---
gcc/rust/Make-lang.in | 308
This is the initial version 1 patch set for the Rust front-end. There are more
changes that need to be extracted out for all the target hooks we have
implemented. The goal is to see if we are implementing the target hooks
information for x86 and arm. We have more patches for the other targets I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #47 from Richard Earnshaw ---
Created attachment 53361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53361=edit
Possible patch
A slightly more thorough attempt to avoid the problem by detecting when the
alias sets are known
Thank you for your reply. I am gonna try another to implement the fractional
vector spilling of RVV in RISC-V backend.
If this patch is really having a bad impact on other targets. I think this
patch may needs to be abandon.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2022-07-27
On Wed, 2022-07-27 at 17:57 +0800, WANG Xuerui wrote:
> On 2022/7/27 17:28, Lulu Cheng wrote:
> >
> >
> > 在 2022/7/27 下午5:15, Xi Ruoyao 写道:
> > > On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
> > >
> > > > > "Use or do not use assembler relocation operators when dealing with
> > > > >
After consideration. Maybe I can try another solution. I aggree with you that
it is not good idea that fake the BYTESIZE of vint8mf2_t and let GCC think it
is a full vector. I think the best way is let GCC understand the real size of
'vint8mf2_t' as a half of a vector and then RISC-V backend
1 - 100 of 191 matches
Mail list logo
