Hi Mike,
On 2023-04-12 22:46, Michael Meissner wrote:
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote:
I understand that QP insns (e.g. xscmpexpqp) is valid if the system
meets ISA3.0, no matter BE/LE, 32-bit/64-bit.
I think option -mfloat128-hardware is designed for QP insns.
While
Add more reviewers. :)
Jiufu Guo writes:
> Hi,
>
> The case file-CWE-1341-example.c checkes [CWE-1341](`double-fclose`).
> While on some systems, besides [CWE-1341], a message of [CWE-415] is
> also reported. On those systems, attribute `malloc` may be attached on
> fopen:
> ```
> # 258
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 Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file,
On 4/12/23 10:58, Jakub Jelinek wrote:
On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
I've tried the pr108947.c testcase, but I see no differences in the assembly
before/after the patch (but dunno if I'm using the right options).
The pr109040.c testcase from
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 Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #35 from Huaqi ---
OK, thanks
On Mon, Apr 10, 2023 at 10:08 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> This patch mentions Intel AMX-COMPLEX ISA support in GCC 13.
>
> Also it revises the march support according to newly released
> Intel Architecture Instruction Set Extensions and Future Features.
>
> Ok for
On Linux/x86_64,
58c8c1b383bc3c286d6527fc6e8fb62463f9a877 is the first bad commit
commit 58c8c1b383bc3c286d6527fc6e8fb62463f9a877
Author: Andre Vieira
Date: Tue Apr 11 10:07:43 2023 +0100
if-conv: Restore MASK_CALL conversion [PR10]
caused
FAIL: gcc.dg/vect/vect-simd-clone-16e.c
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 Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file,
On 3/27/23 00:59, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
PR 108270
Fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270.
Consider the following testcase:
void f (void * restrict in, void * restrict out, int l, int n, int m)
{
for (int i = 0; i < l; i++){
Yeah, like kito said.
Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
And we like ARM SVE style implmentation.
And now we see swapping rtx_code and mode in rtx_def can make rtx_def overal
not exceed 64 bit.
But it seems that there is still problem in tree_type_common
On 4/5/23 07:53, juzhe.zh...@rivai.ai wrote:
>> So fusion in this context is really about identifying cases where two
configuration settings are equivalent and you "fuse" them together.
Presumably this is only going to be possible when the vector insns are
just doing data movement rather
Yeah. But this patch is not appropriate now since it is conflict with the
upstream GCC.
I am gonna re-check the current upstream GCC and the queue patch for GCC 14.
If there are some conflicts, I will resend them.
Thanks
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-04-13 07:00
To:
On 4/6/23 19:11, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
This patch should be merged before this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614935.html
According to RVV ISA, the EEW = 64 is enable only when -march=*zve64*
Current condition is incorrect, since
Tested x86_64-linux and powerpc-aix. Pushed to trunk.
-- >8 --
AIX defines struct tstate with non-reserved names, so
adjust the 17_intro/names.cc test. It also defines struct user, which
conflicts with namespace user in some tests.
Replacing the global operator new doesn't work on AIX the same
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml: Document libstdc++exp.a library.
* doc/html/*: Regenerate.
diff --git a/libstdc++-v3/doc/xml/manual/using.xml
b/libstdc++-v3/doc/xml/manual/using.xml
index 7f011a6d931..3a507fc1671 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
George Bott changed:
What|Removed |Added
CC||george at bott dot gg
--- Comment #34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> This was built on solaris 2.10 so maybe the solution is just to update
> /opt/csw/bin/gcc. I'll ask the cfarm admins about that.
That wouldn't help,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
Bug ID: 109492
Summary: gcc/fortran/trans-expr.cc:3407:17: error: call of
overloaded ‘abs(long long int&)’ is ambiguous
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161
--- Comment #3 from Indu Bhagat ---
Excerpt from the generated DWARF debug info:
<1><32>: Abbrev Number: 3 (DW_TAG_subprogram)
<33> DW_AT_external: 1
<33> DW_AT_name: (indirect string, offset: 0x12c4): set_cpu_arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #5 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #4)
>
> Can you git bisect this to find the offending commit?
Yes, I was going to start that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #4 from Peter Bergner ---
(In reply to pthaugen from comment #0)
> Created attachment 54845 [details]
> Reduced testcase
>
> Hitting the following segfault on the attached testcase (sorry for size, but
> it is about 1% of original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #9 from Segher Boessenkool ---
That patch looks fine :-)
On 4/12/23 07:01, Richard Biener wrote:
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
Would be nice.
Though, I'm afraid it still wouldn't fix the PR101912 testcase, because
it has exactly what happens in this PR, undefined phi arg from the
pre-header and uses of the previous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #3 from Andrew Pinski ---
Created attachment 54846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54846=edit
Removed altivec intrinsics
This changes the altivec intrinsics except for __builtin_vec_mergeh which I
just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #2 from Andrew Pinski ---
I should note while trying to test this on x86_64 (removing the altivec
specific intrinsics) the compile time was large even for -O0. It was ok with
-fsyntax-only though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #1 from pthaugen at gcc dot gnu.org ---
Note this only happens on a BE system, compiles fine on LE.
On Wednesday 12 April 2023 10:53:32 Nick Clifton wrote:
> Hi Pali,
>
> > > Hello! Just for a record, I filled individual issues to bugzilla:
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30004
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30139
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|Segfault in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Bug ID: 109491
Summary: Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #8 from Wilhelm M ---
Yes. Looks like the patch does its job.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #32 from Marek Polacek ---
(In reply to maic from comment #31)
> Would be nice if this was re-opened, or should a new bug be filed?
This is the same problem as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165#c9
Unfortunately,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #31 from maic ---
Would be nice if this was re-opened, or should a new bug be filed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109483
--- Comment #5 from Andrew Pinski ---
(In reply to Uroš Bizjak from comment #4)
> Even the above is not optimal. I'd expect:
>
> ...
> .L8:
> #APP
> # 6 "t.c" 1
> int3
> # 0 "" 2
> #NO_APP
> je .L2
> xorl%eax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> The behavior also depends on the order of USE statements in the main:
>
> USE H5T
> USE ISO_C_BINDING
>
> differs from
>
> USE ISO_C_BINDING
> USE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490
Bug ID: 109490
Summary: ICE when using custom OpenMP reduction in Lambda in
Template Function
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
--- Comment #6 from Oliver Rosten ---
If you're sure.
The only thing which gives me pause for thought is that the problem I see with
source_location only occurs when I also see
ld: warning: direct access to global weak symbol means the weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
--- Comment #5 from Andrew Pinski ---
(In reply to Oliver Rosten from comment #4)
> I think I've come across a case where this is symptomatic of a serious
> problem -see https://github.com/ojrosten/SourceLoc
That seems totally unrelated to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
Oliver Rosten changed:
What|Removed |Added
CC||oliver.rosten at googlemail
dot co
Hi Paul,
On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
I think that the changelog says it all. OK for mainline?
this looks almost fine, but still fails if one directly uses the
dummy argument as the ASSOCIATE target, as in:
program p
implicit none
character(4) ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69200
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #13)
> > This PR may be a duplicate of others that describe gfortran's confusion
> > when using (intrinsic) modules along a module chain like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #5 from Andrew Pinski ---
Note I think clang's "optimization" might get the case where a subdirectory is
not "executable" but is readable wrong.
So this is definitely something which would need testing too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2015-07-22 00:00:00 |2023-4-12
On Tue, Mar 28, 2023 at 03:49:43PM +, Qing Zhao wrote:
> the C front-end has been approved by Joseph.
>
> Jacub, could you please eview the middle end part of the changes of this
> patch?
>
> The major change is in tree-object-size.cc (addr_object_size).
> (To use the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Andrew Pinski changed:
What|Removed |Added
CC||wumingchuan1992 at foxmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109481
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
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 German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
Andrew Pinski changed:
What|Removed |Added
Summary|Feature request: More |improve include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #2 from Andrew Pinski ---
Also does it work with Windows style pathes?
I am suspecting clang does not do the right thing there ...
On 6 April 2023 12:49:53 CEST, Ajit Agarwal via Gcc-patches
wrote:
>Hello All:
>
>Eliminate unnecessary redundant extension within basic and across basic blocks.
To borrow HP's "arm-chair development mode", unfortunately most of the comments
i had for the previous version apply to this version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489
Bug ID: 109489
Summary: [ubsan] Support -fsanitize-trap=
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #1 from Andrew Pinski ---
Is this even valid with NFS?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488
Bug ID: 109488
Summary: typo in lang.opt: libraries maybe
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
On Tue, Apr 11, 2023 at 11:12 AM Jonathan Wakely wrote:
>
> On Tue, 11 Apr 2023 at 15:59, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
>
> Yes, this is only for C++23 so OK for trunk now.
Yay thanks, pushed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #13 from Bernhard Reutner-Fischer ---
(In reply to anlauf from comment #12)
> Consider the original testcase. Module CModule has no public symbols.
> Technically, the "use CModule" in module DModule should not have any effect.
>
On Wed, Apr 12, 2023 at 11:04 AM Jonathan Wakely wrote:
>
> On Wed, 12 Apr 2023 at 14:45, Patrick Palka via Libstdc++
> wrote:
> >
> > This makes floating_from_chars.cc explicitly include all headers
> > that are used by the original fast_float amalgamation according to
> >
On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
> I've tried the pr108947.c testcase, but I see no differences in the assembly
> before/after the patch (but dunno if I'm using the right options).
> The pr109040.c testcase from the patch I don't see the expected zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #6 from Wilhelm M ---
The following "solution"
constexpr uint16_t mul(const uint8_t a, const uint16_t b) {
const auto aa = std::bit_cast>(b);
return aa[1] * a;
}
or
constexpr uint16_t mul(const uint8_t a, const uint16_t
On Wed, Apr 12, 2023 at 06:35:29PM +0200, Bernhard Reutner-Fischer wrote:
> >+relation_kind ret = le_op1_op2_relation (lhs);
> >+if (ret == VREL_GT
> >+&& (op1.known_isnan ()
> >+|| op1.maybe_isnan ()
> >+|| op2.known_isnan ()
> >+|| op2.maybe_isnan ()))
> >+
On 12 April 2023 16:21:24 CEST, Jakub Jelinek via Gcc-patches
wrote:
>--- gcc/range-op-float.cc.jj 2023-04-12 12:17:44.784962757 +0200
>+++ gcc/range-op-float.cc 2023-04-12 16:07:54.948759355 +0200
>@@ -835,10 +835,17 @@ public:
> bool fold_range (irange , tree type,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108291
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108291
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ae8f903632c930694640a925b042c87e3bdb7200
commit r13-7157-gae8f903632c930694640a925b042c87e3bdb7200
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #5 from Segher Boessenkool ---
Correct, this certainly can not be done by combine, it see two independent
pseudos here. For hard registers it *can* do many tricks, but not for
pseudos like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580
--- Comment #5 from Jonathan Wakely ---
I've implemented the suggested changes to istreamubf_iterator and also proposed
them as a resolution for LWG 2366 https://wg21.link/lwg2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420
--- Comment #2 from Patrick Palka ---
FWIW a candidate fix has been posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615250.html and will
hopefully get reviewed/pushed later this week
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #34 from Costas Argyris ---
Hi Huaqi,
Patch has been pushed to master, you should now be able to get the latest gcc
sources and build without having to apply it manually.
On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 12, 2023 at 08:21:26AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > I would have expected something like
> > WORD_REGISTER_OPERATIONS && known_le (GET_MODE_PRECISION (mode),
> > BITS_PER_WORD)
> > as the condition to
Hi All,
I think that the changelog says it all. OK for mainline?
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-07 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
--- Comment #3 from Jakub Jelinek ---
The Simple Location Description before each DW_OP_{,bit_}piece may be empty,
that is the
DWARF 5 2.6.1.1.1 Empty Location Descriptions.
Sorry for my wording issue earlier, where I wrote Single I meant
Thank you for the feedback Richard and Richard.
> Note the calls are guarded with
>
> && ! known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)
Yes, I believe nelt.is_constant() wouldn't be necessary. I didn't realize
the call was guarded by this condition.
> But I think the better check for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
--- Comment #2 from LU Hongyi ---
Oh, sorry I didn't read the standard carefully.
But still, the code generated by GCC still looks a bit strange.
There is a DW_OP_const2u between two composite location descriptor.
The final DWARF generated by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
Thanks for the quick response! verified and pushed to trunk.
On Wed, Apr 12, 2023 at 9:56 PM wrote:
>
> From: Ju-Zhe Zhong
>
> Fix supporting data type according to RVV ISA.
> For vint64m*_t, we should only allow them in zve64* instead of zve32*_zvl64b
> (>=64b).
> Ideally, we should make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
--- Comment #7 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:31eb8f18bbe64613fd8d77c4520c00beeb13598f
commit r13-7156-g31eb8f18bbe64613fd8d77c4520c00beeb13598f
Author: Ju-Zhe Zhong
Date: Wed
On Wed, 12 Apr 2023 at 15:41, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
>
> PR libstdc++/108291
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (chunk_by_view::_M_find_next): Generalize
>
On Wed, 12 Apr 2023 at 14:45, Patrick Palka via Libstdc++
wrote:
>
> This makes floating_from_chars.cc explicitly include all headers
> that are used by the original fast_float amalgamation according to
> r12-6647-gf5c8b82512f9d3, except:
>
> 1. since fast_float doesn't seem to use anything
Ping for patch 105325. I believe patch V3 answers the objections raised
earlier. Can I check this patch into master? Then can I apply this patch to
GCC 12 and 11 after appropriate delays?
| Date: Mon, 27 Mar 2023 23:19:55 -0400
| Subject: [PATCH, V3] PR target/105325, Make load/cmp fusion know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109458
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:51856718a82ce60f067910d9037ca255645b37eb
commit r13-7155-g51856718a82ce60f067910d9037ca255645b37eb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109458
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4073ce2c4e5584c1be58fbe76dd66285de2529bb
commit r13-7154-g4073ce2c4e5584c1be58fbe76dd66285de2529bb
Author: Jakub Jelinek
Date:
> Am 12.04.2023 um 16:37 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> The following testcase ICEs in reassoc, unlike the last case I've fixed
> there here SSA_NAME_USED_IN_ABNORMAL_PHI is not the case anywhere.
> build_and_add_sum places new statements after the later appearing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109487
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote:
> I understand that QP insns (e.g. xscmpexpqp) is valid if the system
> meets ISA3.0, no matter BE/LE, 32-bit/64-bit.
> I think option -mfloat128-hardware is designed for QP insns.
>
> While there is one issue, on BE machine, when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #31 from Costas Argyris ---
(In reply to Tobias Burnus from comment #30)
> I see commit r13-7153-g3beeebd6934654f3453209730b98c7a1fd0305b6
> "mingw: Support building with older gcc versions"
>
> And I see in the associated email to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108291
libstdc++-v3/ChangeLog:
* include/std/ranges (chunk_by_view::_M_find_next): Generalize
parameter types of the predicate passed to adjacent_find.
(chunk_by_view::_M_find_prev):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109483
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #2)
> Note that clang seems to propagate the constant equivalence which we
> instead un-propagate. With -fdisable-tree-uncprop1 you'll get the
> expected code:
>
>
1 - 100 of 279 matches
Mail list logo
