r14-172-g0368d169492017 use NO_REGS instead of GENERAL_REGS in memory cost
calculation when preferred register class is unkown.
+ /* Costs for NO_REGS are used in cost calculation on the
+1st pass when the preferred register classes are not
+known yet. In this case we take
Hi,
On 2023-05-01 23:52, Segher Boessenkool wrote:
Hi!
On Fri, Mar 17, 2023 at 11:39:52AM +0800, Jiufu Guo wrote:
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr65421-1.c: New test.
* gcc.target/powerpc/pr65421.c: New test.
Please name the tests something else? -1.c and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
Hi,
On 2023-05-01 03:00, Jeff Law wrote:
On 3/16/23 21:39, Jiufu Guo wrote:
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return is passed
through registers.
For this kind of case, it would be better to use the nature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54627
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
From: Juzhe-Zhong
This patch is fix patch of V2:
https://patchwork.sourceware.org/project/gcc/patch/20230419164214.1032017-3-juzhe.zh...@rivai.ai/.
Address comments from Kito && Robin, and fix issues && add testcases for them.
gcc/ChangeLog:
* config/riscv/riscv-protos.h
[Ping]
From: Tejas Belagod
Date: Thursday, March 16, 2023 at 5:09 PM
To: gcc-patches@gcc.gnu.org
Cc: Tejas Belagod , Richard Sandiford
Subject: [PATCH] [PR96339] AArch64: Optimise svlast[ab]
From: Tejas Belagod
This PR optimizes an SVE intrinsics sequence where
svlasta (svptrue_pat_b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104357
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> One thing I should note:
> _7 = x_3(D) >= 0;
> _6 = (unsigned char) _7;
> _8 = -_6;
>
> Should be done on the gimple level as:
> t = x_3(D) >>
On Thu, May 4, 2023 at 1:35 PM Hongtao Liu wrote:
>
> On Thu, Dec 22, 2022 at 4:04 PM Uros Bizjak wrote:
> >
> > On Thu, Dec 22, 2022 at 5:40 AM Hongtao Liu wrote:
> > >
> > > On Thu, Dec 22, 2022 at 6:46 AM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Dec 21, 2022 at 02:43:43PM -0800, H.J. Lu
On Thu, Dec 22, 2022 at 4:04 PM Uros Bizjak wrote:
>
> On Thu, Dec 22, 2022 at 5:40 AM Hongtao Liu wrote:
> >
> > On Thu, Dec 22, 2022 at 6:46 AM Jakub Jelinek wrote:
> > >
> > > On Wed, Dec 21, 2022 at 02:43:43PM -0800, H.J. Lu wrote:
> > > > > > > > > > Target RejectNegative
> > > > > > > >
This ideal of this patch looks good to me.
But I think this patch should be able to handle more cases (not only -16 ~ 15)
in case of CONST_VECTOR initialization.
Case 1 (Other constant value that is not -16 ~ 15):
void vmv_m##VAL (TYPE dst[], int n) \
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678
--- Comment #7 from Quentin Sabah ---
@jason Thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #6 from john.harper at vuw dot ac.nz ---
OK by me but I'm not in charge of gfortran!
On Thu, 4 May 2023, jvdelisle at gcc dot gnu.org wrote:
> Date: Thu, 4 May 2023 03:05:49 +
> From: jvdelisle at gcc dot gnu.org
> To: John
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #13 from LIU Hao ---
dup notwithstanding, I think I had better copy my recommendation here for
reference:
This is how MSVC handles such names:
(https://gcc.godbolt.org/z/TonjYaxqj)
```
static int* volatile rip;
static unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
Andrew Pinski changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109726
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109726
Bug ID: 109726
Summary: use of variables whose name happen to match register
names or keywords
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Bug ID: 109725
Summary: [14 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in riscv_print_operand, at
config/riscv/riscv.cc:4430
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
--- Comment #2 from Andrew Pinski ---
This is the corrected version which surives a bootstrap:
/* Convert ABS[U]_EXPR == 0 or ABS[U]_EXPR != 0 to x == 0 or x != 0. */
(for op (abs absu)
(for eqne (eq ne)
(simplify
(eqne (op @0) zerop@1)
Here's update patch with documents in md.texi.
Ok for trunk?
--
Use swap_communattive_operands_p for canonicalization. When both value
has same operand precedence value, then first bit in the mask should
select first operand.
The canonicalization should help backends for pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #15 from CVS Commits ---
The releases/gcc-13 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:5821f378b58443e21c77c0f8c673067fc7655fcb
commit r13-7285-g5821f378b58443e21c77c0f8c673067fc7655fcb
Author: Ju-Zhe Zhong
On Tue, May 2, 2023 at 4:08 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following testcase ICEs because STV replaces there
> (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
> (nil))
> with
> (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724
--- Comment #3 from Sam James ---
Created attachment 54989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54989=edit
reduced.ii
This reduced version seems to exhibit the same behaviour but please verify.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #5 from Jerry DeLisle ---
Is this acceptable:
$ ./a.out
Compiler version = GCC version 14.0.0 20230424 (experimental)
Compiler options = -mtune=generic -march=x86-64 -Wpedantic
On Mon, May 1, 2023 at 3:37 AM Jeff Law wrote:
>
>
>
> On 4/19/23 21:58, liuhongt via Gcc-patches wrote:
> > Use swap_communattive_operands_p for canonicalization. When both value
> > has same operand precedence value, then first bit in the mask should
> > select first operand.
> >
> > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724
--- Comment #2 from Sam James ---
I'm going to try reduce this with a timeout of ~3s or so and pray, but please
tell me if you have a better idea to help speed it up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724
Sam James changed:
What|Removed |Added
Keywords||compile-time-hog,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724
Bug ID: 109724
Summary: [10 regression] Huge memory usage when building
qtwebengine's SkOpAngle.cpp
Product: gcc
Version: 10.4.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109723
Sam James changed:
What|Removed |Added
Keywords||needs-bisection,
|
commit 490c1c096ca1d3a1f4a84801a46231d64c07ba49)
14.0.0 20230503 (experimental) 6cff5f3da7f263bb11cf48e6011931422b62b364
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
This kind of transformation seems pretty generic and might be a
candidate for adding to the middle-end, perhaps as part of combine.
I noticed these happened more often for LRA, which is the reason I
went on this track of low-hanging-fruit-microoptimizations that are
such an itch when noticing
This has no effect on arith-rand-ll (which suffers badly from LRA) and
marginal effects (0.01% improvement) on coremark, but the size of
coremark shrinks by 0.2%. An earlier version was tested with a tree
around 2023-03 which showed (marginally) that ALL_REGS is preferable
to GENERAL_REGS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
--- Comment #1 from Andrew Pinski ---
Note I accidently found this while creating a patch for PR 101541 and I had
messed up creating ABSU when I didn't need to and it was causing the testsuite
patterns in tree-ssa/vrp20.c not to match (though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
Bug ID: 109722
Summary: ABSU == 0 is not optimized to just a == 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:9525daf0fbc5c836ee028f5b58612857de7da51d
commit r14-465-g9525daf0fbc5c836ee028f5b58612857de7da51d
Author: Gaius Mulley
Date: Thu
Ping again.
> From: Hans-Peter Nilsson
> Date: Thu, 27 Apr 2023 01:55:24 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 19 Apr 2023 18:59:14 +0200
> [...]
>
> > So again: Approvers: pdf output reviewed. Ok to commit?
> > -- >8 --
> > I was a bit surprised when my newly-added
On previous occasions when a general LRA transition has been
discussed, IIRC, the argument was used, that everything is ready for
targets and their maintainers to make the transition. As I pointed
out then (though more than a year ago last time, people forget) that's
still not true: LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541
--- Comment #4 from Andrew Pinski ---
Another one missed:
```
unsigned abssat2 (unsigned x)
{
int y = x;
if (y < 0)
x = -x;
return x;
}
```
I have a patch for the this case, I think. Working on the other case now.
While improving replace_phi_edge_with_variable for the diamond formed bb
case, I need a way to copy phi entries from one edge to another as I am
removing a forwarding bb inbetween. I was pointed out that jump threading
code had copy_phi_arg_into_existing_phi which I can use.
I also noticed that
While looking at differences between what minmax_replacement
and match_simplify_replacement does. I noticed that they sometimes
chose different edges to remove. I decided we should be able to do
better and be able to remove both empty basic blocks in the
case of match_simplify_replacement as that
When I added the dce_ssa_names argument, I didn't realize bitmap was a
pointer so I used the default argument value as auto_bitmap(). But
instead we could just use nullptr and check if it was a nullptr
before calling simple_dce_from_worklist.
OK? Bootstrapped and tested on x86_64-linux-gnu with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544
--- Comment #4 from JuzheZhong ---
(In reply to Mathieu Malaterre from comment #2)
> ok then. Closing as resolved/invalid then !
Hi, the GCC master has supported the latest segment intrinsics.
Would you mind using the latest segment intrinsics
Snapshot gcc-10-20230503 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20230503/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109721
--- Comment #1 from Andrew Pinski ---
The testcase might need now -fno-tree-vectorizer .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109721
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] predcom-2 |[14 Regression] predcom-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109721
Bug ID: 109721
Summary: [14 Regression] predcom-2 fails after recent changes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
> 2023年5月3日 22:04，Maciej W. Rozycki 写道：
>
> On Wed, 3 May 2023, Richard Sandiford wrote:
>
>>> speculation_barrier for MIPS needs sync+jr.hb (r2+),
>>> so we implement __speculation_barrier in libgcc, like arm32 does.
>>
>> Looks reasonable, but do you have a source for the fallback
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #4 from Andrew Pinski ---
Some internal GCC Notes:
PRE introduces the read from uninitialized memory though it is not used in some
pathes. The IR/CFG is very has some interesting twists and turns to it which
looks like it confuses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #3 from Paul Smith ---
Created attachment 54986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54986=edit
bitset.i.gz compressed preprocessor output
Hm, I did attach it when I filed the bug; I guess I forgot to click some
gcc/ChangeLog:
* doc/extend.texi: Replace @itemx not being preceded by @item.
---
Fixes errors raised by newer Texinfo.
Pushed as obvious.
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index
On Wed, 3 May 2023, Richard Sandiford wrote:
> > speculation_barrier for MIPS needs sync+jr.hb (r2+),
> > so we implement __speculation_barrier in libgcc, like arm32 does.
>
> Looks reasonable, but do you have a source for the fallback
> pre-r2 handling? (Thanks for adding that btw, since I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b357af31b8d1e93f0f70133e25d3ad4045f7a32b
commit r10-11389-gb357af31b8d1e93f0f70133e25d3ad4045f7a32b
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #2 from Andrew Pinski ---
(In reply to Paul Smith from comment #1)
> Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that
> we only use the dynamic_bitset leg of the union after we've initialized it?
Once we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #1 from Paul Smith ---
Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that we
only use the dynamic_bitset leg of the union after we've initialized it?
I wonder if this warning could just assume that if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #5 from Christoph Reiter ---
Taking `libgcc_s_dw2-1.dll` from gcc 12.2 fixes the issue. We also found that
gdb and cmake are broken due to broken exception handling (in case of cmake it
is flaky). In both those cases taking the old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
--- Comment #5 from Jonathan Wakely ---
I suppose we could do something like:
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -364,7 +364,9 @@ You must have GNU make installed to build GCC@.
Necessary (only on some platforms) to
On Wed, 3 May 2023, Jason Merrill wrote:
> On 5/2/23 15:53, Patrick Palka wrote:
> > on Tue, 2 May 2023, Patrick Palka wrote:
> >
> > > On Tue, 2 May 2023, Jason Merrill wrote:
> > >
> > > > On 5/1/23 15:59, Patrick Palka wrote:
> > > > > Here we're incorrectly deeming the templated call a.g()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
Christian Hergert changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
--- Comment #3 from Manuel Jacob ---
(In reply to Richard Biener from comment #1)
> Huh, can you post how it fails?
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc && \
make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
Bug ID: 109720
Summary: -Wmaybe-uninitialized triggering when I can see no
path that would allow it
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #8 from Andrew Pinski ---
(In reply to Christian Hergert from comment #6)
> (In reply to Andrew Pinski from comment #2)
> > HUH? omit frame pointer is on by default on x86_64.
>
> Yes, Fedora 38 changed the default compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #7 from Christian Hergert ---
(In reply to Andrew Pinski from comment #3)
> Also on x86_64, frame pointers are not required by the ABI so this is not an
> ABI issue. Why instead are you not using the dwarf2 unwind tables that are
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #6 from Christian Hergert ---
(In reply to Andrew Pinski from comment #2)
> HUH? omit frame pointer is on by default on x86_64.
Yes, Fedora 38 changed the default compiler flags to `-fno-omit-frame-pointer`
so that the system can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
--- Comment #4 from Jonathan Wakely ---
Some of the warnings were always present, but suppressed unless you used
-Wsystem-headers
Now they're issued even when the "problem" is in a system header.
This is considered progress ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #5 from Christian Hergert ---
Created attachment 54985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54985=edit
First level of stack traces with g++
This shows stack traces when the only change was compiling harfbuzz with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #4 from Christian Hergert ---
Created attachment 54984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54984=edit
First level of stack traces with clang++
This shows a more proper first-level of stack frames within the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #3 from Andrew Pinski ---
Also on x86_64, frame pointers are not required by the ABI so this is not an
ABI issue. Why instead are you not using the dwarf2 unwind tables that are
generated by default too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109710
--- Comment #5 from Jonathan Wakely ---
It should not be hard to understand. You are using this path:
/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/
There is a comma in _13,1.x
Just like you were using _12,1,x earlier.
Stop doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
--- Comment #1 from Christian Hergert ---
> When I recompile the project with clang++ instead
I realize this was a bit vague, by "project" I mean Harfbuzz. Simply compiling
Harfbuzz with clang++ made frame-pointer unwinding work by Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
--- Comment #3 from Paul Smith ---
OK, well, we don't have to say "broken"; all I know is that perfectly
respectable code that used to work without triggering these warnings in older
versions of GCC, and with older -std=c++..., is now failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819
--- Comment #15 from Jonathan Wakely ---
*** Bug 109710 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109710
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719
Bug ID: 109719
Summary: Truncated frame-pointer unwinding via Linux perf with
g++
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
On Wed, 3 May 2023 at 21:06, Jakub Jelinek wrote:
>
> On Wed, May 03, 2023 at 08:56:40PM +0100, Jonathan Wakely wrote:
> > Do we want a #pragma to suppress -Wattribute-alias here?
>
> I think that isn't needed, as the aliases use the same argument types
> as the functions they are aliasing (did
On Wed, May 03, 2023 at 08:56:40PM +0100, Jonathan Wakely wrote:
> Do we want a #pragma to suppress -Wattribute-alias here?
I think that isn't needed, as the aliases use the same argument types
as the functions they are aliasing (did that because other
aliases in those files do it that way as
On Wed, 3 May 2023 at 19:55, Jakub Jelinek via Libstdc++
wrote:
>
> Hi!
>
> This is an ABI problem on powerpc64le-linux, introduced in 13.1.
> When libstdc++ is configured against old glibc, the
> _ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
>
On 5/2/23 15:53, Patrick Palka wrote:
on Tue, 2 May 2023, Patrick Palka wrote:
On Tue, 2 May 2023, Jason Merrill wrote:
On 5/1/23 15:59, Patrick Palka wrote:
Here we're incorrectly deeming the templated call a.g() inside b's
initializer as potentially constant, despite g being
On Wed, 3 May 2023, 19:44 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> As discussed ON IRC, my _Float128/_Float64x support changes broke
> abi.exp testing on powerpc64-linux.
>
> The
> _ZTIDF128_@@CXXABI_1.3.14
> _ZTIDF64x@@CXXABI_1.3.14
> _ZTIPDF128_@@CXXABI_1.3.14
>
On 5/2/23 17:13, Patrick Palka wrote:
constraints_satisfied_p already carefully checks dependence of template
arguments before proceeding with satisfaction, so the dependence check
in instantiate_alias_template is unnecessary and overly conservative.
Getting rid of it allows us to check
On 5/2/23 19:10, Marek Polacek wrote:
This PR points out that std::is_convertible has given the wrong answer
in
static_assert (!std::is_convertible_v , "");
since r13-2822 implemented __is_{,nothrow_}convertible.
std::is_convertible uses the imaginary
To test() { return std::declval();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
--- Comment #15 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd
commit r14-460-g7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd
commit r14-460-g7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A bug in the simplification I did around 91618; at this point X::f has
DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template
it corresponds to, so we don't want to call check_explicit_specialization.
To distinguish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649
--- Comment #3 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:6138e862038180c7cfb94d6c120bd0b76da382ae
commit r13-7283-g6138e862038180c7cfb94d6c120bd0b76da382ae
Author: Jason Merrill
Hi, Jan,
You added the following patch into gcc10:
>From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001
From: Jan Hubicka
Date: Thu, 5 Dec 2019 19:12:51 +0100
Subject: [PATCH] cgraphclones.c (localize_profile): New function.
* cgraphclones.c (localize_profile): New
Richard Biener writes:
> On Fri, 28 Apr 2023, Andre Vieira (lists) wrote:
>
>> This patch replaces the existing tree_code widen_plus and widen_minus
>> patterns with internal_fn versions.
>>
>> DEF_INTERNAL_OPTAB_HILO_FN is like DEF_INTERNAL_OPTAB_FN except it provides
>> convenience wrappers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #20 from gagan sidhu (broly) ---
my apologies, i should open a new ticket if this is indeed an error.
but it may be my fault for not specifying the ARCH parameter when installing
the linux headers prior to starting the toolchain.
Hi!
This is an ABI problem on powerpc64le-linux, introduced in 13.1.
When libstdc++ is configured against old glibc, the
_ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109710
Andrew Pinski changed:
What|Removed |Added
Summary|OS X Lio : make failed -> |Build fails with `,` in the
Hi!
As discussed ON IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.
The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on
1 - 100 of 366 matches
Mail list logo
