Hi!
On 2022-01-10T17:14:00+0100, Martin Liška wrote:
> The script is capable of checking if MAINTAINER names are sorted
> alphabetically.
Irrespective of the pre-existing issue that a concept of a first and a
last name doesn't exist in all cultures, and thus sorting by the latter
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
For testcase in PR, the patch supports QI:4 -> HI:16 pack with
multi steps(first pack QI:4 -> QI:8 through vec_pack_sbool_trunc_qi,
then pack QI:8 -> HI:16 through vec_pack_trunc_hi).
Similar for QI:2 -> HI:16 which is test4 in mask-pack-prefer-128.c.
Bootstrapped both with and w/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98824
--- Comment #4 from Bernie Innocenti ---
Are there any known workarounds?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98824
Bernie Innocenti changed:
What|Removed |Added
CC||bernie at codewiz dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On Mon, Jan 17, 2022 at 10:36 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Fri, Jan 14, 2022 at 09:41:35AM +0100, Jan Hubicka via Gcc-patches wrote:
> > > > > > > --- a/gcc/ipa-split.c
> > > > > > > +++ b/gcc/ipa-split.c
> > > > > > > @@ -873,7 +873,7 @@ visit_bb (basic_block bb, basic_block
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065
Andrew Pinski changed:
What|Removed |Added
Keywords||build
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #4
On Mon, Jan 17, 2022 at 8:35 AM Sundeep KOKKONDA via Gcc-patches
wrote:
>
> Hello,
>
>
>
> The '-MF' option cannot deal with path size >256 characters in Windows. This
> patch is to fix this long path issue with -MF option.
>
> Let me know is it ok to commit?
I don't think this is the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103973
--- Comment #11 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:5e26bf17220926d308d0e3bb82bae6e592d2e485
commit r12-6655-g5e26bf17220926d308d0e3bb82bae6e592d2e485
Author: liuhongt
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #11 from Kewen Lin ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Checking the number of tries might be useful, but if so, I think
> it should be done by a test that was written for that specific
> purpose. The tst can
> From: Patrick Palka via Gcc-patches
> Date: Sun, 16 Jan 2022 19:06:48 +0100
> We're going to use the fast_float library in our (compiled-in)
> floating-point std::from_chars implementation for faster and more
> portable parsing of binary32/64 decimal strings.
>
> The single file
Hi,
As discussed in PR104015, the test case slp-perm-9.c can be
fragile when vectorizer tries to use different vectorisation
strategies.
As Richard suggested, this patch tries to make the check not
sensitive on the re-trying times by removing the times checking.
To still retain the test coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|NEW
On Tue, Jan 18, 2022 at 10:57 AM liuhongt via Gcc-patches
wrote:
>
> Change scan-assembler from "\tucomisd" to "\t\[v\]?ucomisd".
It's an obvious "fix", Pushed to trunk.
>
> refer to https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076241.html
>
> gcc/testsuite/ChangeLog:
>
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080
--- Comment #2 from Hans-Peter Nilsson ---
Created attachment 52215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52215=edit
patch for endian.h issue
This patch is not sufficient: after this, I get:
libtool: compile: /X-obj/./gcc/xgcc
Change scan-assembler from "\tucomisd" to "\t\[v\]?ucomisd".
refer to https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076241.html
gcc/testsuite/ChangeLog:
* g++.target/i386/pr103973-1.C: Change scan-assembler from
"\tucomisd" to "\t\[v\]?ucomisd".
*
Hi,
This patch enables absolute jump table on PPC Linux. When PIC is set, the
absolute jump tables are
placed in RELRO section. Otherwise, they're placed in rodata section.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is
this okay for trunk?
Any
Bump default ISA spec to newer version 20191213, current default ISA spec
is 2.2, but it's already out of date for a long time, sync with binutils
ISA version, convention in toolchain use.
gcc/ChangeLog:
* config.gcc: Modify default isa_spec version.
---
gcc/config.gcc | 8
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080
Hans-Peter Nilsson changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080
Hans-Peter Nilsson changed:
What|Removed |Added
Last reconfirmed||2022-01-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080
Bug ID: 104080
Summary: [12 Regression] newlib doesn't have endian.h causing
build failure with 2800bc08e4ab r12-6646
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Hi.
This option will be useful for rustc_codegen_gcc to hide the error
about unsupported 128-bit integer types.
David, if you know of a better way to check if these types are
supported than creating such a type and checking if it causes an error,
I will not need this patch.
Thanks for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
--- Comment #4 from Kewen Lin ---
Patch was posted with the link
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html, still
pending on review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079
--- Comment #2 from Andrew Pinski ---
A little more reduced:
template
struct AT
{
static void cn() noexcept(noexcept(DT::CN()));
void SNFP( void *n ) noexcept(noexcept(cn()));
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079
Bug ID: 104079
Summary: internal compiler error: in nothrow_spec_p, at
cp/except.c:1192
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #17 from Martin Sebor ---
Jaosn: this is how all middle-end warnings have always behaved. They trigger
on invalid statements present in the IL. A statement is considered invalid
when any of its operands is out of bounds or in some
I missed the comment about the new define, so here's the updated patch.
Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a
écrit :
> Hi.
> This patch add supports for register variables in libgccjit.
>
> It passes the JIT tests, but since I added a function in reginfo.c, I
> wonder
I was missing the define, so I added it.
Here's the new patch with it.
Le lundi 17 janvier 2022 à 17:18 -0500, Antoni Boucher via Jit a
écrit :
> Hi.
> This patch add support for bitcasts in libgccjit.
>
> It passes the JIT tests, but since I added a function in tree.c, I
> wonder if I should
Hi.
This patch add supports for register variables in libgccjit.
It passes the JIT tests, but since I added a function in reginfo.c, I
wonder if I should run the whole testsuite.
Thanks for the review.
From 328eca2be438c4a05c21942b4b2c3650ff7de0eb Mon Sep 17 00:00:00 2001
From: Antoni Boucher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #13 from hubicka at kam dot mff.cuni.cz ---
> Result pure looping 0
> Function found to be pure: foo/4
This is good - we are supposed to find it to be pure and walk all
aliases and update noninterposable ones
> Declaration updated to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #16 from Andrew Macleod ---
The only thing I can think of is it is *guaranteed* to be out of range, then
assume that is because those other values were handled elsewhere and don't
report it?
L_3 int [5, +INF]
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Jason Merrill changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968
--- Comment #6 from Eric Botcazou ---
I get this compilation error:
In file included from /home/ebotcazou/src/libgfortran/runtime/fpu.c:29:
./fpu-target.h:36:24: error: invalid application of 'sizeof' to incomplete type
'struct fenv'
36 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074
Andrew Pinski changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104078
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025
--- Comment #6 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 52213 [details]
> gcc12-pr104025.patch
>
> Untested fix. I think the old input_location is the right one.
I think the bug is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104078
Bug ID: 104078
Summary: Some type determination weirdness
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Sat, Jan 15, 2022 at 3:28 AM Anthony Sharp
wrote:
> Hi Jason,
>
> Hope you are well. Apologies, I've not had time to sit down and look at
> this since last month I quit my old job, then I had family around for the
> whole of the Christmas period, and then even more recently I've had to
>
Hi Harald,
after lengthy debugging of this PR it became obvious that we killed
the typespec while trying to expand an empty array constructor.
Bad idea, but easy to fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch?
OK.
Thanks for the patch!
Best regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #12 from Andrew Pinski ---
(In reply to Rich Felker from comment #11)
> Are you sure? If pure/const discovery is no longer applied to weak
> definitions, it shouldn't be able to propagate to a non-inlined caller. Of
> course the fix
Hi.
This patch add support for bitcasts in libgccjit.
It passes the JIT tests, but since I added a function in tree.c, I
wonder if I should run the whole testsuite.
David, you can now disregard my question in my email about 128-bit
integers regarding my issue with initialize_sizetypes being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2022-01-17
Alias|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
Bug ID: 104077
Summary: bogus/missing -Wdangling-pointer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
Bug ID: 104076
Summary: bogus -Wdangling-pointer on a conditional
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #11 from Rich Felker ---
Are you sure? If pure/const discovery is no longer applied to weak definitions,
it shouldn't be able to propagate to a non-inlined caller. Of course the fix
may be incomplete or not working, which I guess we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103692
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Dear Fortranners,
after lengthy debugging of this PR it became obvious that we killed
the typespec while trying to expand an empty array constructor.
Bad idea, but easy to fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch?
Thanks,
Harald
From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Bug ID: 104075
Summary: bogus/missing -Wuse-after-free
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074
--- Comment #2 from Andrew Pinski ---
The following are accepted:
struct f;
template class pfm;
template using u0 = pfm<::recycle>;
template class pmv;
template using u1= pmv<::recycle>;
template class ptr;
template using u2=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #4 from Martin Sebor ---
Actually, this is already supposed to be handled but the code is not effective
due to a typo. This fixes it:
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074
Bug ID: 104074
Summary: [12 Regression] Maybe rejected code: is not a valid
type for a template non-type parameter since
r12-6022-gbb2a7f80a98de3fe
Product: gcc
On 1/13/22 12:01, Martin Liška wrote:
Hello.
Based on the discussion with release managers, the change is going to happen
after stage4 begins.
Martin
Hi.
The renaming patches have been just installed and I've built a few target
compilers so far.
I'll be online in ~10 hours from now so I
On 1/13/22 12:01, Martin Liška wrote:
Hello.
Based on the discussion with release managers, the change is going to happen
after stage4 begins.
Martin
Hi.
The renaming patches have been just installed and I've built a few target
compilers so far.
I'll be online in ~10 hours from now so I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
--- Comment #17 from CVS Commits ---
The releases/gcc-11 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:2c4b5bd4440292eca51de1f09ccce0d139ab981e
commit r11-9474-g2c4b5bd4440292eca51de1f09ccce0d139ab981e
Author: Marek Polacek
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patch has been installed as I've made the renaming now.
Cheers,
Martin
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patch has been installed as I've made the renaming now.
Cheers,
Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045
--- Comment #5 from joseph at codesourcery dot com ---
Folding the fmax operation should be valid in the absence of
-fsignaling-nans (fmax (a, +Inf) should return +Inf without raising any
exceptions, for any x not a signaling NaN). However,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073
Bug ID: 104073
Summary: Add option to hide stderr logging in libgccjit
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072
Bug ID: 104072
Summary: Register variables in libgccjit
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071
Bug ID: 104071
Summary: Add support for bitcast
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103692
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
---
On 1/17/22 12:18, Shubham Narlawar via Gcc wrote:
On Mon, Jan 17, 2022 at 1:55 PM Richard Biener
wrote:
On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc wrote:
On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
Hello,
Hi; various notes inline below...
My aim is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104007
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On Mon, Jan 17, 2022 at 5:54 AM Jonathan Wakely wrote:
>
>
>
> On Sun, 16 Jan 2022 at 18:17, Patrick Palka via Libstdc++
> wrote:
>>
>> libstdc++-v3/ChangeLog:
>>
>> * testsuite/20_util/from_chars/double.cc: New test, consisting
>> of testcases extracted from the MSVC STL
Hi!
On Mon, Jan 17, 2022 at 09:06:25PM +0100, Sebastian Huber wrote:
> On 11/01/2022 09:10, Sebastian Huber wrote:
> >On 20/04/2021 17:00, Segher Boessenkool wrote:
> >>There are various non-IBM CPUs with isel as well, so it is easiest if we
> >>just don't consider that flag here (it is not
On 11/01/2022 09:10, Sebastian Huber wrote:
Hello Segher,
On 20/04/2021 17:00, Segher Boessenkool wrote:
There are various non-IBM CPUs with isel as well, so it is easiest if we
just don't consider that flag here (it is not needed).
2021-04-20 Segher Boessenkool
PR target/100108
*
On Mon, Jan 17, 2022 at 5:49 AM Jonathan Wakely wrote:
>
>
>
> On Sun, 16 Jan 2022 at 18:12, Patrick Palka via Libstdc++
> wrote:
>>
>> This makes fast_float handle the situation where std::from_chars is
>> specified to return result_out_of_range, i.e. when the parsed value
>> is outside the
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
---
libatomic/configure.ac| 6 --
libbacktrace/configure.ac | 7
As mentioned in the PR, this demonstrates the potentially quadratic
performance behaviour of adding transitive relations over a series of
cascading calculations.
As the lookup in a basic block is also linear in nature, I think for
this release it makes sense to simply limit the number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103942
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10 Regression] invalid |[9 Regression] invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Attached
(the cut n paste looks like it removed some whitespace formatting)
0001-c-designated-init-of-char-array-by-string-constant-P.patch
Description: Binary data
Ping, could a global maintainer take a look at this?
On Mon, Jan 03, 2022 at 07:32:25PM -0800, H.J. Lu via Gcc-patches wrote:
> On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu wrote:
> >
> > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu wrote:
> > >
> > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote:
> > >
V3 addresses Jason's review point - it.undoes unnecessary variable renames
(back from arr_init to str_init)
Also address "FIXME: this code is duplicated from reshape_init" in
cp_complete_array_type by always calling reshape_init on init-list.
PR c++/55227
gcc/cp/ChangeLog:
* decl.c
On Mon, Jan 17, 2022 at 1:55 PM Richard Biener
wrote:
>
> On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc
> wrote:
> >
> > On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> > > Hello,
> >
> > Hi; various notes inline below...
> >
> > >
> > > My aim is to iterate over
On Mon, Jan 17, 2022 at 5:23 AM David Malcolm wrote:
>
> On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> > Hello,
>
> Hi; various notes inline below...
>
> >
> > My aim is to iterate over gimple call stmt parameters and check
> > whether it is constant or constant expression
On Linux/x86_64,
463d9108766dcbb6a1051985e6c840a46897fe10 is the first bad commit
commit 463d9108766dcbb6a1051985e6c840a46897fe10
Author: Jakub Jelinek
Date: Mon Jan 17 13:39:05 2022 +0100
widening_mul, i386: Improve spaceship expansion on x86 [PR103973]
caused
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #10 from Alexander Monakov ---
As comment #5 mentioned, it is still broken, you just need -fno-inline in
addition to -O2 for the original testcase. Andrew's remark is quite useful for
situations like this, you know :)
On 1/17/22 06:46, Stephan Bergmann wrote:
On 10/01/2022 22:51, Martin Sebor via Gcc-patches wrote:
Last ping for this stage 1 feature before stage 3 ends:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
This hits somewhat unexpectedly at (test case reduced from a hit in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
On Mon, Jan 17, 2022 at 9:24 AM Joseph Faulls wrote:
>
> Hello all,
>
> Small disclaimer of being new to EH, but I have come across a problem that
> seems quite fundamental to EH frame registry. I am targeting riscv64, but I
> believe the problem to be entirely platform agnostic.
>
> When using
On 1/14/22 19:22, Marek Polacek wrote:
This is a "canonical types differ for identical types" ICE, which started
with r11-4682. It's a bit tricky to explain. Consider:
template struct S {
S bar() noexcept(T::value); // #1
S foo() noexcept(T::value); // #2
};
template S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
--- Comment #16 from Marek Polacek ---
Yeah, I'm testing a patch which does just that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
--- Comment #15 from Jakub Jelinek ---
Just replace startswith (x, y) with strncmp (x, y, strlen (y)) == 0 for 11 and
earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
--- Comment #5 from Jeffrey A. Law ---
I briefly looked at the other BZ last week, but didn't make much headway. The
first thing that stood out was why are we threading around the loop. I thought
that was disabled. Anyway, Aldy and/or I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
--- Comment #14 from Marek Polacek ---
Oops, that broke the build:
.../c-family/c-format.c:3229:22: error: ‘startswith’ was not declared in this
scope
3229 | && startswith (format_chars, "decl-specifier"))
I've reverted the
1 - 100 of 347 matches
Mail list logo
