On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
wrote:
>
> Hi!
>
> On 2022-12-13T14:40:36+0100, Arthur Cohen wrote:
> > We've also added one more commit, which only affects files inside the
> > Rust front-end folder. This commit adds an experimental flag, which
> > blocks the compilation of
on 2022/12/14 18:33, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote:
>>> The hacks with different precisions of powerpc 128-bit floating types are
>>> very unfortunate, it is I assume because the middle-end asserted that scalar
>>> floating point types with
On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
wrote:
>
> Hi!
>
> On 2022-12-13T14:40:36+0100, Arthur Cohen wrote:
> > We've also added one more commit, which only affects files inside the
> > Rust front-end folder. This commit adds an experimental flag, which
> > blocks the compilation of
Hi!
The following testcase ICEs, because ccp1 replaced
s.0_1 =
__asm__ goto("" : "=r" MEM[(T *)s.0_1] : : : "lab" lab);
with
__asm__ goto("" : "=r" s : : : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
__asm__ goto("" : "=r" s_7 : : :
On Wed, 14 Dec 2022, Qing Zhao wrote:
> Hi, Richard,
>
> I guess that we now agreed on the following:
>
> “ the information that we ran into a trailing array but didn't consider
> it a flex array because of -fstrict-flex-arrays is always a useful
> information”
>
> The only thing we didn’t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
David Binderman changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment
>> I bet the above workaround in generic code was added for a reason, it would
>> surprise me if _Float128 worked at all without that hack.
>
> OK, I'll have a look at those nan failures soon.
By investigating the exposed NaN failures, I found it's due to that it wants
to convert _Float128 type
On Thu, Dec 15, 2022 at 3:39 PM Jakub Jelinek wrote:
>
> On Thu, Dec 15, 2022 at 02:21:37PM +0800, liuhongt via Gcc-patches wrote:
> > --- a/gcc/config/i386/i386.opt
> > +++ b/gcc/config/i386/i386.opt
> > @@ -420,6 +420,10 @@ mpc80
> > Target RejectNegative
> > Set 80387 floating-point
On Thu, Dec 15, 2022 at 02:21:37PM +0800, liuhongt via Gcc-patches wrote:
> --- a/gcc/config/i386/i386.opt
> +++ b/gcc/config/i386/i386.opt
> @@ -420,6 +420,10 @@ mpc80
> Target RejectNegative
> Set 80387 floating-point precision to 80-bit.
>
> +mdaz-ftz
> +Target
s/Target/Driver/
> +Set the
> On 15 Dec 2022, at 05:58, chuanqi.xcq wrote:
>
> Hi Nathan,
>
> > But how do they specify the mapping from module/header-unit name to CMI, so
> > that
> > imports work?
> >
> > Is this really a clang-specific mechanism, as it has no module mapper ATM
> > (IIUC)?
>
> Yes, clang doesn't
Forgot it indeed, thanks for notifying me!
I modified the commit message to add it and added it into this email.
Le mer. 14 déc. 2022 à 16:12, Antoni Boucher a écrit :
> Thanks!
>
> In your patch, you're missing this line at the end of the commit
> message:
>
>Signed-off-by: Guillaume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> That revision seems good. Trying 7450b25566b7a738.
Seems good. Trying 512098a3316f07d4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
Seriously? You UNIX folks are completely clueless about usability! It would
have been far easier to supply a built-in or separate utility to
automatically collect all the pertinent source files with the option of
mailing them to you. It also wouldn't be half as backward if you didn't
make me read
Update in v2:
1. Support -mno-daz-ftz, and make the the option effectively three state as:
if (mdaz-ftz)
link crtfastmath.o
else if ((Ofast || ffast-math || funsafe-math-optimizations)
&& !shared && !mno-daz-ftz)
link crtfastmath.o
else
Don't link crtfastmath.o
2. Still make the
Update in V2:
Split -shared change into a separate commit and add some documentation
for it.
Bootstrapped and regtested on x86_64-pc-linu-gnu{-m32,}.
Ok of trunk?
Don't add crtfastmath.o for -shared to avoid changing the MXCSR register
when loading a shared library. crtfastmath.o will be used
Hi Nathan,
> But how do they specify the mapping from module/header-unit name to CMI, so
> that
> imports work?
>
> Is this really a clang-specific mechanism, as it has no module mapper ATM
> (IIUC)?
Yes, clang doesn't have a module mapper. And I remember Iain said he want to
introduce these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #5 from David Binderman ---
That revision seems good. Trying 7450b25566b7a738.
For the reduced code, -march=zen3 not required.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #3 from Andrew Pinski ---
There used to be a warning for this. Even saw someone post an updated version
of it that happens on gimple (but that never went in).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #2 from Andrew Pinski ---
https://en.cppreference.com/w/c/program/setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Bug ID: 108117
Summary: Wrong instruction scheduling on value coming from
abnormal SSA
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108096
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:4ef521bbc63f8a3883d507a8b6c1f95f442df3fe
commit r13-4712-g4ef521bbc63f8a3883d507a8b6c1f95f442df3fe
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108071
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:4ef521bbc63f8a3883d507a8b6c1f95f442df3fe
commit r13-4712-g4ef521bbc63f8a3883d507a8b6c1f95f442df3fe
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In these testcases, we weren't adequately verifying that constructing the
element type from an array element would have the same effect as
constructing it from one of the initializers.
PR c++/108071
PR c++/105838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #4 from David Binderman ---
Git bisect now running. Trying 15f04af347e3b65f.
Hi Richard,
I will commit tomorrow the attached patches to the active branches gcc-10, 11,
and 12.
The patches passed bootstrap and regression test on arm64-linux.
Sebastian
From: Richard Sandiford
Sent: Thursday, December 8, 2022 1:38:07 AM
To: Pop,
Hi,
"Kewen.Lin" writes:
> Hi Jeff,
>
> on 2022/12/12 09:38, Jiufu Guo via Gcc-patches wrote:
>> Hi,
>>
>> For constant C:
>> If '(c & 0x8000ULL) == 0x8000ULL' or say:
>> 32(1) || 16(x) || 1(1) || 15(x), using "li; xoris" would be ok.
>>
>> If '(c &
Hi,
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Segher Boessenkool writes:
>
>> Hi!
>>
>> Sorry for the tardiness.
>>
>> On Mon, Aug 29, 2022 at 11:42:16AM +0800, Jiufu Guo wrote:
>>> When checking eq/ne with a constant which has only 16bits, it can be
>>> optimized to check the rotated data.
six
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221214 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B'
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/' '-B'
'/home/zopolis4/gcjbuild/./gcc/' '-B'
'/usr/local/x86_64-pc-linux-gnu/bin/' '-B'
'/usr/local/x86_64-pc-linux-gnu/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116
m101010a at gmail dot com changed:
What|Removed |Added
Attachment #54098|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116
Bug ID: 108116
Summary: internal compiler error: in check_noexcept_r, at
cp/except.cc:1074
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Bug 104075 depends on bug 108115, which changed state.
Bug 108115 Summary: spurious pointer used after realloc warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108115
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108115
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-15
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Bug 104075 depends on bug 108115, which changed state.
Bug 108115 Summary: spurious pointer used after realloc warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108115
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106119
Andrew Pinski changed:
What|Removed |Added
CC||t...@develop-help.com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108115
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108115
Bug ID: 108115
Summary: spurious pointer used after realloc warning
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Here we're triggering an overzealous assert in unify during partial
ordering since the member function pointer constants are represented as
ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
expects only COMPOUND_LITERAL_P constructors.
Bootstrapped and regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
[CC += groff]
Hi Andrew,
On 12/14/22 23:57, Andrew Pinski wrote:
On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha
wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
Patch 19 has been resolved.
I had a look-- issue fixed, rough patch below. Full patch will be part of v2.
>From b0d93d8212328fabcbdb32c266c265a4eed49e00 Mon Sep 17 00:00:00 2001
From: Maximilian Downey Twiss
Date: Thu, 15 Dec 2022 09:54:36 +1100
Subject: [PATCH] java: Adjustments to end_params_node and void_list_node.
Hi!
On 2022-12-13T14:40:36+0100, Arthur Cohen wrote:
> We've also added one more commit, which only affects files inside the
> Rust front-end folder. This commit adds an experimental flag, which
> blocks the compilation of Rust code when not used.
(That's commit
Hi!
On 2022-12-13T14:40:36+0100, Arthur Cohen wrote:
> We've also added one more commit, which only affects files inside the
> Rust front-end folder. This commit adds an experimental flag, which
> blocks the compilation of Rust code when not used.
(That's commit
On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha
wrote:
>
> Hi,
>
> I was rewriting the strncat(3) manual page, and when I tried to compile the
> example program, I got a surprise from the compiler.
>
> Here goes the page:
>
>
>strncat(3) Library Functions Manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #3 from David Binderman ---
Reduced C++ code seems to be:
namespace std {
template struct integral_constant {
static constexpr int value = __v;
};
using true_type = integral_constant;
using false_type = integral_constant;
On 12/14/22 23:51, Alejandro Colomar wrote:
On 12/14/22 23:45, Alejandro Colomar wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library
On 12/14/22 23:45, Alejandro Colomar wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual strncat(3)
NAME
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual strncat(3)
NAME
strncat - concatenate a null‐padded
On Wed, Nov 30, 2022 at 04:30:13PM +0800, Kewen.Lin wrote:
> As PR104024 shows, the option -mpower10-fusion isn't guarded by
> -mcpu=power10, it causes compiler to fuse for some patterns
> even without power10 support and then causes ICE unexpectedly,
> this patch is to simply unmask it without
I'm missing something from this discussion. IIUC the claim is that these 2 new
options -fmodule-output{,=NAME} are for build systems that want to specify the
module output file.
But how do they specify the mapping from module/header-unit name to CMI, so that
imports work?
Is this really a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
--- Comment #2 from Jonathan Wakely ---
(In reply to Marc Poulhiès from comment #1)
> I'll need to read a bit more about the 8 (default move assignment op being
> deleted).
Lexer has this member:
buffered_queue input_queue;
That has a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
--- Comment #2 from Jonathan Wakely ---
(In reply to Marc Poulhiès from comment #1)
> I'll need to read a bit more about the 8 (default move assignment op being
> deleted).
Lexer has this member:
buffered_queue input_queue;
That has a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
--- Comment #1 from Marc Poulhiès ---
Hello David,
Looking at the errors, most of them are trivial to fix.
1-6: missing 'override'.
9: not present in most recent dev branch on github, can be ignored as it will
disappear when we update the gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
--- Comment #1 from Marc Poulhiès ---
Hello David,
Looking at the errors, most of them are trivial to fix.
1-6: missing 'override'.
9: not present in most recent dev branch on github, can be ignored as it will
disappear when we update the gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108065
David Malcolm changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108109
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4710-g41faa1d7beb90b.
gcc/analyzer/ChangeLog:
PR analyzer/108065
* region.cc (decl_region::get_svalue_for_initializer): Bail out to
avoid calling binding_key::make with an empty region.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108065
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:41faa1d7beb90b235858c8a692be926642ad5559
commit r13-4710-g41faa1d7beb90b235858c8a692be926642ad5559
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113
Marc Poulhiès changed:
What|Removed |Added
See Also||https://github.com/Rust-GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947
--- Comment #6 from anlauf at gcc dot gnu.org ---
Setting a breakpoint in gfc_resolve_pack, I find for the len=: case:
(gdb) p *array->ts.u.cl
$12 = {length = 0x0, next = 0x2cc7af0, length_from_typespec = false,
backend_decl = 0x0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108109
--- Comment #2 from Tobias Burnus ---
Created attachment 54096
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54096=edit
valgrind output.
(In reply to anlauf from comment #1)
> Is this attached file to be preprocessed? Or does it need
This patch fixes two tests that are still failing when long double is IEEE
128-bit after the previous 2 patches for PR target/107299 have been applied.
The tests are:
gcc.target/powerpc/convert-fp-128.c
gcc.target/powerpc/pr85657-3.c
This patch is a rewrite of the patch submitted
This patch fixes the issue that GCC cannot build when the default long double
is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc
during the evrp pass. Ultimately it is failing because the
This patch reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
This set of patches was first submitted on November 1st. Kewen.Lin
asked for some changes to the first set of patches. I
also tried to clean up the comments in the second patch about types that Segher
Boessenkool mentioned.
I had just re-submitted the first patch yesterday, but Segher asked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947
--- Comment #5 from anlauf at gcc dot gnu.org ---
The dump tree shows near the pack intrinsic:
- for character(len=10):
atmp.4.dtype = {.elem_len=10, .rank=1, .type=6};
atmp.4.span = 10;
atmp.4.data = 0B;
atmp.4.offset = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108114
--- Comment #2 from Andrew Pinski ---
(In reply to Gawain Bolton from comment #0)
> From my understanding of the C++20 standard (cf.
> https://eel.is/c++draft/dcl.init.general#nt:brace-or-equal-initializer)
> this code attached is valid since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108114
--- Comment #1 from Andrew Pinski ---
clang gives:
:11:19: warning: mixture of designated and non-designated initializers
in the same initializer list is a C99 extension [-Wc99-designator]
B b{{.a = 0}, .b = 1};
^~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108114
Bug ID: 108114
Summary: Designated initialization of parent class results in
error in C++20 mode
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107537
--- Comment #4 from michael.foerderer at gmx dot de ---
This is my first patch, I hope that I did it right:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608512.html
Dear all,
this is a patch to print the gcov annotations (fallthrough or throw) als
to uncovered branches.
Best regards,
Michael
From b65cfc8a837cd9d1b6421978865210e59ba62e0e Mon Sep 17 00:00:00 2001
From: Spacetown
Date: Sun, 4 Dec 2022 21:03:34 +0100
Subject: [PATCH] gcov: annotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113
Marc Poulhiès changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dkm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113
Marc Poulhiès changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dkm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113
Bug ID: 108113
Summary: Rust and --enable-link-serialization=1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113
Bug ID: 108113
Summary: Rust and --enable-link-serialization=1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
Andrew Pinski changed:
What|Removed |Added
Known to fail||
--- Comment #9 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108112
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108112
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79426
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10 Regression] fortran -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108093
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|Quadratic error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108112
Bug ID: 108112
Summary: ICE on explicit instantiation of template member
operator delete
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108109
--- Comment #1 from anlauf at gcc dot gnu.org ---
Is this attached file to be preprocessed? Or does it need special options?
Can't reproduce here.
Hi Tobias,
thanks for your explanation! Now things are clearer.
Am 14.12.22 um 08:57 schrieb Tobias Burnus:
@@ -63 +66 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
- d->dtype.version = s->version;
+ d->dtype.version = 0;
I was wondering what the significance of "version" is.
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #10 from Jakub Jelinek ---
Another question is what with this tolerated extension happens when the typedef
is unsigned.
// PR c++/108099
// { dg-do compile { target c++11 } }
// { dg-options "" }
typedef unsigned long long t64;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
Bug ID: 108111
Summary: Rust meets clang
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
Bug ID: 108111
Summary: Rust meets clang
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #2 from Andrew Pinski ---
Most likely one of the following revisions ranges caused the issue:
r13-4705 - r13-4706
r13-4684 - r13-4691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|ice in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #1 from David Binderman ---
CPU is AMD Ryzen 7 5700G, so -march flag is zen3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #9 from Jakub Jelinek ---
Though, on
// PR c++/108099
// { dg-do compile { target c++11 } }
// { dg-options "" }
using u128 = unsigned __int128_t;
using s128 = signed __int128_t;
template struct integral_constant {
static
^
0xe33c71 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
../../trunk.d1/gcc/ipa-param-manipulation.cc:700
I have a reduction running. Problem seems to be recent (today or yesterday).
Command line is
$ ~/gcc/results.20221214.asan.ubsan/bin/g++ -c -march=native -std=c++14 -O3
bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104
--- Comment #3 from Andrew Pinski ---
It is definitely a pointer to member function issue.
I tried with just a pointer to a function and it worked and even a pointer to a
member field works too:
```
struct ss {
int t;
};
template struct
> Am 14.12.2022 um 18:28 schrieb G.T. via Gcc :
>
> At line 276, lra_assert (spill_class != NO_REGS); would trigger
> whenever execution reached here with spill_class equal to NO_REGS.
> Seems to me that would never happen. Because one of the conditions in
> the if statement right above it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108108
--- Comment #4 from M Welinder ---
> Since it was not read again, the file is not considered included ...
It must have been read -- how else could gcc decide it was the same?
# strace -f gcc -MM c.c 2>&1 >Makefile | grep 'open.*\.h' | grep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
On Wed, Dec 14, 2022 at 1:56 AM chuanqi.xcq wrote:
>
> Hi David,
>
> > I think Nathan might've been asking not only about what currently
> happens, but what we think should happen?
>
> Yes.
>
> > Is that consistent with `-o`? (I assume so, but don't know - I guess
> there aren't many cases where
1 - 100 of 297 matches
Mail list logo
