> From: Hans-Peter Nilsson
> Date: Fri, 12 May 2023 15:53:49 +0200
> Anyway, Roger mentioned that the clobbers emitted by the
> lower-subreg passes were apparently damaging, so I'll try
> this out "for fun", on the assumption that they're actually
> unnecessary. I don't think actually removing
Richard Biener writes:
> On Fri, 12 May 2023, Andre Vieira (lists) wrote:
>
>> I have dealt with, I think..., most of your comments. There's quite a few
>> changes, I think it's all a bit simpler now. I made some other changes to the
>> costing in tree-inline.cc and gimple-range-op.cc in which I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #12 from Alexander Monakov ---
That would not fix the problem, lifetime-dse affects code that creates 'class
User' objects, not the implementation of its 'operator new' override.
(also the linked bug says "MDNode has the same
Gabriel Ravier writes:
> As somebody that spends a lot of time helping beginners, yes,
> constantly. I'd go as far as to say it's an error that seemingly
> everyone has made at least once.
Really? And after making this mistake (and learning its solution), did
they continue to make the same
On 12/05/2023 14:28, Richard Biener wrote:
On Fri, 12 May 2023, Andre Vieira (lists) wrote:
I have dealt with, I think..., most of your comments. There's quite a few
changes, I think it's all a bit simpler now. I made some other changes to the
costing in tree-inline.cc and
Eli Schwartz writes:
> This sounds like a "you" problem.
I don't write these Makefiles. Others do.
It wasn't the problem of their authors before, so why should it be now?
> From: Hans-Peter Nilsson
> Date: Thu, 11 May 2023 17:05:40 +0200
> Next, I'll turn around completely, and try defaulting to
> -fsplit-wide-types-early, which sounds more promising. :)
> I don't like throwing defaults around randomly, but trying
> out a promising idea this way is easy.
Gabriel Ravier writes:
> It's "extra work" to add 10 characters to a Makefile, but normal to
> add random faulty declarations everywhere ?
You're assuming that people are willing to edit Makefiles, which is all
kinds of pain, and then put up with a complete recompile of whatever
software is
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This should have been removed in r9-2029-g612c9c702e2c9e when the
char16_t and char32_t specializations of std::codecvt were changed to be
defined unconditionally.
libstdc++-v3/ChangeLog:
* testsuite/22_locale/locale/cons/unicode.cc:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This should have been done in r9-2028-g8ba7f29e3dd064 when
std::shared_mutex was changed to be defined without depending on
_GLIBCXX_USE_C99_STDINT_TR1.
libstdc++-v3/ChangeLog:
* testsuite/experimental/feat-cxx14.cc: Remove dependency on
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These #ifdef checks should have been removed in r9-2029-g612c9c702e2c9e
when the u16string_view and u32string_view aliases were changed to be
defined unconditionally.
libstdc++-v3/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #8 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109743
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi Julian, hi all,
(I have not (yet) looked at the patch/testcase in depth - and I prefer
that someone knowledgeable with C++ constructors comments. However:)
Regarding only nvptx - and the testcase on nvptx:
On 12.05.23 14:02, Julian Brown wrote:
The approach taken is to generate a set of
> emit_merge_op can not be wrapped into binop since mask position is
> different in pattern.
>
> I prefer merge op in different wrapper.
Yes, I didn't mean literally the same but that things already
become a bit confusing with all the different variants and bool
arguments or code duplication
Convert vlmul and policy to human readable string, some example below:
Before:
[VALID,Demand
field={1(VL),0(DEMAND_NONZERO_AVL),1(SEW),0(DEMAND_GE_SEW),1(LMUL),0(RATIO),0(TAIL_POLICY),0(MASK_POLICY)}
AVL=(reg:DI 0 zero)
SEW=16,VLMUL=3,RATIO=2,TAIL_POLICY=1,MASK_POLICY=1]
^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #11 from Xi Ruoyao ---
Is it supported to use different -flifetime-dse settings for TUs when LTO is
enabled? If yes we can submit a LLVM change to add -flifetime-dse=1 for
User.cpp.o and mark this MOVED.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109743
--- Comment #1 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:c919d059fcb67747d3c0bd539c7044e874b03fb7
commit r14-789-gc919d059fcb67747d3c0bd539c7044e874b03fb7
Author: Kito Cheng
Date: Fri May
V4 Changes:
- Use different approach of V3.
- Rewrite local_eliminate_vsetvl_insn to unify the optimization
flow.
- Also improve few more case.
Off list discussed and reviewed by Ju-Zhe.
---
This issue happens is because we are currently very conservative in
On Fri, 12 May 2023, Andre Vieira (lists) wrote:
> I have dealt with, I think..., most of your comments. There's quite a few
> changes, I think it's all a bit simpler now. I made some other changes to the
> costing in tree-inline.cc and gimple-range-op.cc in which I try to preserve
> the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #10 from Alexander Monakov ---
Indeed, that makes things easier, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826
--- Comment #1 from Florian Weimer ---
I guess the main issue here is that the common type void * for both the second
and third operand is implicitly converted to many pointer types, including the
original types of those operands. So while
Pedro Alves writes:
> Then write a wrapper script named "cc", and put that in the PATH:
>
> $ cat cc
> #!/bin/sh
>
> exec /my/real/gcc -fwhatever "$@"
>
> Done.
And how many people are going to be forced to do this?
Though this is a good point: I suspect if such an option were actually
"juzhe.zhong" writes:
> Hi, Richard. For "can iterate more than once", is it correct use the
> condition
> "LOOP_LENS ().length >1".
No, that says whether any LOAD_LENs or STORE_LENs operate on multiple
vectors, rather than just single vectors.
I meant: whether the vector loop body might
On 5/12/23 15:19, Po Lu via Gcc wrote:
Jonathan Wakely writes:
It's not about popularity. If that's your takeaway then you're not
paying attention, whatever you claim about reading everything in the
thread. It's about helping people write correct code, first time,
without some of the
Jonathan Wakely writes:
> Then they should not use implicit int and implicit function
> declarations.
And why is that? Is GCC really arrogant enough to think that it is the
only C translator in the world?
BTW, standards.info used to say something along the lines of:
Do not declare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Bug ID: 109829
Summary: Optimizing __builtin_signbit(x) ? -x : x or abs for FP
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #31 from Miklos Karacsony ---
(In reply to Sergei Trofimovich from comment #30)
> > configure: WARNING: unrecognized options: --disable-werror
> > In function 'bigger_buffer',
> > inlined from '__libdw_gunzip' at gzip.c:374:12:
Jonathan Wakely writes:
> It's not about popularity. If that's your takeaway then you're not
> paying attention, whatever you claim about reading everything in the
> thread. It's about helping people write correct code, first time,
> without some of the avoidable traps that C presents.
>
> The
On Fri, 12 May 2023, Andre Vieira (lists) wrote:
> Hi,
>
> I think I tackled all of your comments, let me know if I missed something.
This first and the last patch look good to me now. Let me comment on the
second.
Thanks,
Richard.
>
> gcc/ChangeLog:
>
> 2023-05-12 Andre Vieira
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #9
On Fri, 12 May 2023, Tobias Burnus wrote:
> Long standing issue but as top-level 'asm' statement were rare, it did not
> show up.
> However, the fix for PR108969 in commit r14-321-g9a41d2cdbcd added code
>
> +#elif defined(_GLIBCXX_SYMVER_GNU)
> + __extension__ __asm (".globl
Hi,
in general LGTM, just minor nits and comments.
> - void set_len_and_policy (rtx len, bool force_vlmax = false)
> -{
> - bool vlmax_p = force_vlmax;
> - gcc_assert (has_dest);
> + void set_len_and_policy (rtx len, bool force_vlmax = false, bool ta_p =
> true,
> +
Eli Schwartz writes:
> Instead of adding one flag to their Makefile, which is too much work,
Once again, you're making the silly assumption that adding
`-fpermissive' to many different Makefiles is easy. Especially when the
Makefiles also have to be used with compilers which do not understand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 64731, which changed state.
Bug 64731 Summary: vector lowering should split loads and stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:cc0e22b3f25d4b2a326322bce711179c02377e6c
commit r14-788-gcc0e22b3f25d4b2a326322bce711179c02377e6c
Author: Richard Biener
Date:
The following also covers TARGET_MEM_REF when decomposing stores from
CTORs to supported elementwise operations. This avoids spilling
and cleans up after vector lowering which doesn't touch loads or
stores. It also mimics what we already do for loads.
Bootstrapped and tested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752
Patrick Palka changed:
What|Removed |Added
Target Milestone|13.2|14.0
Status|ASSIGNED
Long standing issue but as top-level 'asm' statement were rare, it did not show
up.
However, the fix for PR108969 in commit r14-321-g9a41d2cdbcd added code
+#elif defined(_GLIBCXX_SYMVER_GNU)
+ __extension__ __asm (".globl _ZSt21ios_base_library_initv");
q
libstdc++-v3/include/std/iostream.
Hi,
PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.
I have already fixed this for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Bug ID: 109828
Summary: C2x:static compound literal (with flexible array) in
initializer leads to invalid size and ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
This rewrites the testcase for PR109752 to make it simpler and more
robust (i.e. no longer dependent on r13-4035-gc41bbfcaf9d6ef).
PR c++/109752
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr109752.C: Rename to ...
* g++.dg/cpp2a/concepts-complete4.C: ... this.
I noticed only after the fact that the new testcase template/function2.C
(from r14-708-gc3afdb8ba8f183) is just a subset of ext/visibility/anon8.C,
so let's get rid of it.
PR c++/83258
gcc/testsuite/ChangeLog:
* g++.dg/ext/visibility/anon8.C: Mention PR83258.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258
--- Comment #15 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:10098788ff61467f5a499f01c5443fb53ff564dd
commit r14-787-g10098788ff61467f5a499f01c5443fb53ff564dd
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752
--- Comment #10 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:11fa2729eff8bc585e33086bb2c595ae8a37d14f
commit r14-786-g11fa2729eff8bc585e33086bb2c595ae8a37d14f
Author: Patrick Palka
Date:
On 12/05/2023 08:16, Richard Biener via Gcc wrote:
On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote:
On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
On Thu, 11 May 2023, Kees Cook via Gcc wrote:
On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
On
On 5/12/23 04:36, Po Lu via Gcc wrote:
Arsen Arsenović writes:
Indeed they should be - but warning vs. error holds significance. A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error
On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > One fairly big GCC-internal task is to clear up the C test suite so that
> > it passes with the new compiler defaults. I already have an offer of
> > help for that, so I think we can complete this work in a reasonable time
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #8 from Richard Biener ---
Created attachment 55064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55064=edit
prototype
This works for me. The consistency check is not fully implemented and instead
of passing down no
Moved the 'changes' from this patch back to the second so it's all just
about removing code that we no longer use. I don't really know why Joel
formatted the patches this way, but I thought I'd keep it as is for now.
cover letter:
This patch removes the old widen plus/minus tree codes which
I have dealt with, I think..., most of your comments. There's quite a
few changes, I think it's all a bit simpler now. I made some other
changes to the costing in tree-inline.cc and gimple-range-op.cc in which
I try to preserve the same behaviour as we had with the tree codes
before. Also
Hi,
I think I tackled all of your comments, let me know if I missed something.
gcc/ChangeLog:
2023-05-12 Andre Vieira
Joel Hutton
* tree-vect-patterns.cc (vect_gimple_build): New Function.
(vect_recog_widen_op_pattern): Refactor to use code_helper.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
This patch adds support for running constructors and destructors for
static (file-scope) aggregates for C++ objects which are marked with
"declare target" directives on OpenMP offload targets.
At present, space is allocated on the target for such aggregates, but
nothing ever constructs them
On 5/12/23 2:01 AM, Po Lu wrote:
> Jason Merrill writes:
>
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
--- Comment #4 from Uroš Bizjak ---
Like this:
--cut here--
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 62fe06fdbaa..e6091b8bd35 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -20417,14 +20417,12
On 5/12/23 1:57 AM, Po Lu wrote:
> Eli Schwartz writes:
>> It's still no big deal, no matter how much you dramatize the intensity
>> of adding a flag to your Makefiles.
>
> It's extra work. Why don't I just write:
>
> extern int foo ();
>
> above each of the new errors?
> That is just about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:560a3e35fe01c499bd5b1e95ddc4c3e958cf5abd
commit r14-785-g560a3e35fe01c499bd5b1e95ddc4c3e958cf5abd
Author: Richard Biener
Date:
Never minder. When preparing the PR, I am keeping ask myself that is everywhere
about machine code bit size updated? Thus would like to align the bit size to
one macro, to avoid developers (perhaps myself in future) suffering such kind
of concern.
Will try to move the machine mode to
The following adds another variant of address difference simplification.
The utility ptr_difference_const only handles constant differences
(we also cannot code generate anything else), so exposing a possible
POINTER_PLUS_EXPR in the match and computing the difference on the
base only makes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
Alexander Klepikov changed:
What|Removed |Added
CC||klepikov.alex+bugs at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Richard Biener from comment #1)
> > I think this was just fixed?
>
> No, the asked mode is V2HImode, so it should also be added.
OTOH, it is a bit
"juzhe.zhong" writes:
> Thanks Richard.
> I will do that as you suggested. I have a question for the first patch. How
> to
> enable decrement IV？ Should I add a target hook or something to let target
> decide whether enable decrement IV？
At the moment, the only other targets that use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
--- Comment #2 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> I think this was just fixed?
No, the asked mode is V2HImode, so it should also be added.
"Li, Pan2 via Gcc-patches" writes:
> Thanks Richard for comments. In previous, I am not sure it is reasonable to
> let everywhere consume the same macro in rtl.h (As the includes you
> mentioned). Thus, make a conservative change in PATCH v1.
>
> I will address the comments and try to align the
On 12/05/2023 04:08, Po Lu via Gcc wrote:
Eli Schwartz writes:
Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** being valid GNU99 or GNU11 code.
How GCC currently behaves defines what is
On 5/12/23 08:25, Eli Zaretskii via Gcc wrote:
Date: Thu, 11 May 2023 18:43:32 -0400
Cc: luang...@yahoo.com, gcc@gcc.gnu.org
From: Eli Schwartz
On 5/11/23 2:24 AM, Eli Zaretskii wrote:
Back to the subject: the guarantees I would personally like to have is
that the current GCC development
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #1 from Richard
Hello Jeff:
On 29/04/23 3:40 am, Jeff Law wrote:
>
>
> On 4/20/23 15:03, Ajit Agarwal wrote:
>
>>
>> Currently I support AND with const1_rtx. This is what is equivalent to zero
>> extension instruction in power instruction set. When you specify many other
>> constants and Could you please
Thanks Richard for comments. In previous, I am not sure it is reasonable to let
everywhere consume the same macro in rtl.h (As the includes you mentioned).
Thus, make a conservative change in PATCH v1.
I will address the comments and try to align the bit size to the one and the
only one macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109827
Bug ID: 109827
Summary: Pointer/integer mismatch in ?: not covered by
-Wint-conversion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826
Bug ID: 109826
Summary: Incompatible pointer types in ?: not covered by
-Wincompatible-pointer-types
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> 1. Fix document description according Jeff && Richard.
> 2. Add LOOP_VINFO_USING_SELECT_VL_P for single rgroup.
> 3. Add LOOP_VINFO_USING_SLP_ADJUSTED_LEN_P for SLP multiple rgroup.
>
> Fix bugs for V5 after testing:
>
On 5/12/23 07:57, Po Lu via Gcc wrote:
Eli Schwartz writes:
There are ***not*** thousands of Makefiles that have this issue. But if
there were, then Makefiles are very easy to update, and only have to be
updated once per project, not thousands of times. So this is fine. You
may have to update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #16 from Jonathan
On 2023-05-12 7:01 a.m., Po Lu via Gcc wrote:
> Jason Merrill writes:
>
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #15 from Jonathan Wakely ---
The reason that std::trunc is not provided is because (In reply to Jonathan
Wakely from comment #11)
> The problem is more likely to be that this macro is not defined for djgpp:
>
> #ifdef
From: Juzhe-Zhong
Consider this following case:
typedef int64_t vnx32di __attribute__ ((vector_size (256)));
__attribute__ ((noipa)) void
f_vnx32di (int64_t a, int64_t b, int64_t *out)
{
vnx32di v
= {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b,
a, b, a, b, a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
On 5/12/23 12:17, Kyrylo Tkachov wrote:
-Original Message-
From: Christophe Lyon
Sent: Friday, May 12, 2023 10:39 AM
To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
Richard Earnshaw ; Richard Sandiford
Cc: Christophe Lyon
Subject: [PATCH 01/26] arm: [MVE intrinsics] add
> Date: Fri, 12 May 2023 10:15:45 +0200
> From: Jakub Jelinek
> Cc: Arsen Arsenović , luang...@yahoo.com,
> jwakely@gmail.com, gcc@gcc.gnu.org
>
> On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> >
> > Let's keep in mind that veterans are much more likely to
> From: Jonathan Wakely
> Date: Fri, 12 May 2023 08:28:00 +0100
> Cc: Eli Schwartz , Po Lu ,
> "gcc@gcc.gnu.org"
>
> It is on topic because there doesn't seem to be anything in the
> arguments brought up for this current proposal that couldn't be
> brought up in favor of removing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
On Fri, 12 May 2023 at 11:30, Mike Crowe wrote:
> On Thursday 11 May 2023 at 21:52:22 +0100, Jonathan Wakely wrote:
> > On Thu, 11 May 2023 at 13:42, Jonathan Wakely
> wrote:
> >
> > >
> > >
> > > On Thu, 11 May 2023 at 13:19, Mike Crowe wrote:
> > >
> > >> However, ...
> > >>
> > >> > > diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Bug ID: 109825
Summary: [14 Regression] ICE in ix86_widen_mult_cost, at
config/i386/i386.cc:20442 since
r14-666-g608e7f3ab47fe7
Product: gcc
Version: 14.0
speculation_barrier for MIPS needs sync+jr.hb (r2+),
so we implement __speculation_barrier in libgcc, like arm32 does.
gcc/ChangeLog:
* config/mips/mips-protos.h (mips_emit_speculation_barrier): New
prototype.
* config/mips/mips.cc (speculation_barrier_libfunc): New static
On Thursday 11 May 2023 at 21:52:22 +0100, Jonathan Wakely wrote:
> On Thu, 11 May 2023 at 13:42, Jonathan Wakely wrote:
>
> >
> >
> > On Thu, 11 May 2023 at 13:19, Mike Crowe wrote:
> >
> >> However, ...
> >>
> >> > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> >> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #14 from Janez Zemva ---
Certainly, but users will still be able to make use of the kludge.
> -Original Message-
> From: Christophe Lyon
> Sent: Friday, May 12, 2023 10:39 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw ; Richard Sandiford
>
> Cc: Christophe Lyon
> Subject: [PATCH 01/26] arm: [MVE intrinsics] add binary_widen_opt_n shape
>
> This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #13 from Jonathan Wakely ---
The workaround is wrong and will not be accepted upstream.
On Fri, 12 May 2023 at 09:46, Christian Groessler wrote:
>
> On 5/12/23 09:53, Eli Zaretskii via Gcc wrote:
> >
> >> With all that to consider, is it *really* a significant cost to add
> >> -fpermissive?
> >
> > See above (and my earlier message): the significant cost is to
> > discover the root
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #12 from Janez Zemva ---
I doubt DJGPP will change their C library, at least this workaround exists now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2023-05-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
Eric Botcazou changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
rsen, Gabriel,
Thanks for your feedback. I read through the n2347 article, and I believe
that your feedback is to leverage the C++ 'enum struct' grammer. As you can
tell, I'm not a C++, and and I did not know that the 'SCOPED enum' is
already available for using 'enum class' or 'enum struct'.
speculation_barrier for MIPS needs sync+jr.hb (r2+),
so we implement __speculation_barrier in libgcc, like arm32 does.
gcc/ChangeLog:
* config/mips/mips-protos.h (mips_emit_speculation_barrier): New
prototype.
* config/mips/mips.cc (speculation_barrier_libfunc): New static
201 - 300 of 415 matches
Mail list logo
