https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105052
Bug ID: 105052
Summary: Incorrect constraint on SSSE3 split patterns with MMX
operands
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105051
--- Comment #2 from Godmar Back ---
Thank you for your reply.
To make sure I understand, the only work-around is to completely disable all
builtins (as in -fno-builtin), or is using `-fno-builtin-memset` as I proposed
sufficient?
I'm not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78074
Andrew Pinski changed:
What|Removed |Added
CC||godmar at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105051
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105051
Bug ID: 105051
Summary: consider not combining malloc + memset to calloc when
inside calloc itself
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
Hi Uros,
This patch fix Zhaoxin CPU Vendor ID detection problem
and add Zhaoxin "lujiazui" processor support and tuning.
Currently gcc can't recognize Zhaoxin CPU (Vendor ID "CentaurHauls" and
"Shanghai")
and wrongly identify Zhaoxin "lujiazui" as Intel core2 or i386, which is
confusing for
When building a const to a reg, it may need a few instructions.
This patch updates rs6000_rtx_costs to make it more accurate for
constant building.
With this patch, cse.cc could get accurate cost for complex
constant and then read the constant from a pool.
As discussed in the mail list, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
--- Comment #9 from David Malcolm ---
(In reply to Richard Biener from comment #1)
> Does not enabling sanitizer improve things?
Removing the sanitizer options speeds up the non-analyzer part of the build,
reducing the overall wallclock time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66390
tornenvi at gmail dot com changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
PR analyzer/104954 tracks that -fanalyzer was taking a very long time
on a particular source file in the Linux kernel:
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
One issue occurs with the repeated use of dynamic debug lines e.g. via
the DC_LOG_BANDWIDTH_CALCS macro, such as in
From: Avinash Sonawane
On Thu, 2022-03-24 at 10:41 +0530, Avinash Sonawane wrote:
> On Wed, 23 Mar 2022 18:33:38 -0400
> David Malcolm wrote:
>
> > This is almost ready to push to trunk, but there are a couple of
> > extra
> > tasks needed to be done:
>
> Done.
>
> Please find the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:5f6197d7c197f9d2b7fb2e1a19dac39a023755e8
commit r12-7809-g5f6197d7c197f9d2b7fb2e1a19dac39a023755e8
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:319ba7e241e7e21f9eb481f075310796f13d2035
commit r12-7808-g319ba7e241e7e21f9eb481f075310796f13d2035
Author: Avinash Sonawane
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #7 from Alan Modra ---
So, similar code to what we have in rs6000_call_aix to handle
if ((INTVAL (cookie) & CALL_LONG) != 0
&& GET_CODE (func_desc) == SYMBOL_REF)
should be added to rs6000_sibcall_aix, I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #6 from Alan Modra ---
I'm sorry, I forgot exactly what was happening when I talked about this on the
call. What I should have said is that -mlongcall code is correct but is
missing a sibcall optimisation. -fno-plt code (after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050
Bug ID: 105050
Summary: error: expression '' is not a constant
expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104284
Marek Polacek changed:
What|Removed |Added
Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104284
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:9fdac7e16c940fb6264e6ddaf99c761f1a64a054
commit r12-7805-g9fdac7e16c940fb6264e6ddaf99c761f1a64a054
Author: Marek Polacek
Date:
On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote:
> On 3/24/22 15:56, Marek Polacek wrote:
> > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> > > On 3/24/22 11:49, Marek Polacek wrote:
> > > > I started looking into this PR because in GCC 4.9 we were able to
> > > >
c version 12.0.1 20220324 (experimental) (GCC)
Snapshot gcc-9-20220324 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20220324/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #31 from Jonathan Wakely ---
std::construct_at and std::destroy_at are in alongside
std::_Construct and std::_Destroy. But the latter need iterator category
definitions for destroying sequences. std::construct_at and std::destroy_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
--- Comment #10 from Elliott M ---
Eyes must have glazed over when trying to find other reports. 105048 is indeed
a duplicate.
Another option might be "R" for architectures which haven't
already grabbed "R" for something else. I notice Clang
On 3/24/22 17:53, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote:
On 3/18/22 17:55, Marek Polacek wrote:
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression
On 3/13/22 19:43, Zhao Wei Liew wrote:
On Sat, 12 Mar 2022 at 06:15, Jason Merrill wrote:
It looks good, but unfortunately regresses some other warning tests,
such as Wnonnull5.C. Please remember to run the regression tests before
sending a patch (https://gcc.gnu.org/contribute.html#testing).
On 3/17/22 01:51, Zhao Wei Liew wrote:
Thanks for the review. I've tested and uploaded a new patch v2 with
the requested changes.
On Thu, 17 Mar 2022 at 09:20, Jason Merrill wrote:
On 3/14/22 02:36, Zhao Wei Liew via Gcc-patches wrote:
This patch adds a warning when casting "this" to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Andrew Pinski changed:
What|Removed |Added
CC||ehem+gccbugs at m5p dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105048
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote:
> On 3/18/22 17:55, Marek Polacek wrote:
> > On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
> > > On 3/10/22 18:04, Marek Polacek wrote:
> > > > Since r9-6073 cxx_eval_store_expression preevaluates the value to
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
Elliott M changed:
What|Removed |Added
Component|middle-end |c
--- Comment #6 from Elliott M ---
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105048
--- Comment #1 from Elliott M ---
Created attachment 52684
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52684=edit
Sample of with and without this feature
Hmm, Bugzilla attachment during initial submission failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105048
Bug ID: 105048
Summary: [enhancement] Allow specific register constraints
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: inline-asm
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #5 from Peter Bergner ---
(In reply to Alan Modra from comment #4)
> Do check that the result is not a direct call. I think I was wrong to say
> the assert could be removed (or modified as you have done).
I'm assuming you mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
--- Comment #5 from Jakub Jelinek ---
Sure, but it doesn't force the input to be an lvalue.
You can add variables even in macros in statement expressions,
#define FOO(whatever) \
({ int dummy; __asm ("" : "=c" (dummy) : ...); retval; })
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105047
Bug ID: 105047
Summary: invalid non-dependent call to non-static member of the
current instantiation not rejected ahead of time
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
On 3/24/22 15:56, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
Elliott M changed:
What|Removed |Added
Component|middle-end |c
--- Comment #4 from Elliott M ---
I had
On 3/22/22 16:59, Marek Polacek via Gcc-patches wrote:
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
If two arrays do not have the exact same element type including qualification, this could
be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be distinguished
by the
On 3/23/22 21:01, Pokechu22 via Gcc-patches wrote:
When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first time
(this happened when auto deduces to an initializer_list).
cp_apply_type_quals_to_decl removes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043
--- Comment #6 from Andrew Pinski ---
(In reply to Eric Gallager from comment #5)
> it's not *just* a glibc feature; Darwin Libc uses the same macro, too, for
> example
Yes and Darwin (and FreeBSD, OpenBSD, NetBSD, etc.) should document it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> On 3/24/22 11:49, Marek Polacek wrote:
> > I started looking into this PR because in GCC 4.9 we were able to
> > detect the invalid
> >
> >struct alignas(void) S{};
> >
> > but I broke it in r210262.
> >
> > It's ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
Bug ID: 105046
Summary: [enhancement] Allow inline-assembly clobbers to
overlap inputs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:346ab5a54a831ad9c78afcbd8dfe98e0e07e3070
commit r12-7804-g346ab5a54a831ad9c78afcbd8dfe98e0e07e3070
Author: Jason Merrill
Date:
With the changes for PR81359 and PR88368 to make get_nsdmi errors be treated
as substitution failure, we have the problem that if we check
std::is_default_constructible for a complete class that still has unparsed
default member initializers, we get an answer (false) that will be wrong
once the
Ping.
On 16/03/2022 15:00, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
As requested, I updated the Neoverse N2 entry to use the
AARCH64_FL_FOR_ARCH9 feature set, removed duplicate entries, updated
the ARCH_INDENT to 9A and moved it under the Armv9 cores.
gcc/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #10 from Patrick Palka ---
(In reply to Jason Merrill from comment #8)
> (In reply to Patrick Palka from comment #7)
> > IIUC as long as NON_DEPENDENT_EXPR doesn't appear inside a non-dependent
> > consteval call then we'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990
Marek Polacek changed:
What|Removed |Added
Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f0530882d99abc410bb080051aa04e5cea848f18
commit r12-7803-gf0530882d99abc410bb080051aa04e5cea848f18
Author: Marek Polacek
Date:
On 3/24/22 13:03, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote:
On 3/23/22 19:26, Marek Polacek wrote:
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into
On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote:
> On 3/23/22 19:26, Marek Polacek wrote:
> > On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
> > > On 3/22/22 19:55, Marek Polacek wrote:
> > > > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103775
--- Comment #8 from Jakub Jelinek ---
Created attachment 52682
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52682=edit
gcc12-pr103775.patch
This untested patch seems to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Thomas Schwinge changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105006
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105045
Bug ID: 105045
Summary: [modules] Can't deduce defaulted template parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
On 3/21/22 12:55, Jørgen Kvalsvik via Gcc-patches wrote:
Hello.
Thanks for very interesting extension of the existing GCOV profiling.
I briefly read the patch and investigated what happens and I've got various
questions/comments about it:
1) Do I correctly understand that
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103775
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same effect as alignas(alignof(type-id))", and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103775
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #9 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:647537adefb34041cc2d44585252fd765cc0daae
commit r12-7802-g647537adefb34041cc2d44585252fd765cc0daae
Author: Patrick Palka
Date:
On 3/18/22 17:55, Marek Polacek wrote:
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691
--- Comment #9 from Jakub Jelinek ---
Created attachment 52681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52681=edit
gcc12-pr103691.patch
Untested FE patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #8 from Jason Merrill ---
(In reply to Patrick Palka from comment #7)
> IIUC as long as NON_DEPENDENT_EXPR doesn't appear inside a non-dependent
> consteval call then we'll currently correctly accept/reject it ahead of
> time, e.g.:
On 3/24/22 10:32, Patrick Palka wrote:
Here we weren't respecting SFINAE when evaluating a substituted call to
a consteval function, which caused us to reject the new testcase below.
This patch fixes this by making build_over_call use the SFINAE-friendly
version of cxx_constant_value.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101906
--- Comment #2 from Patrick Palka ---
FWIW one workaround is to use a class template instead of an alias template,
e.g.
-template using voidify = void;
+template struct voidify {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
Jakub Jelinek changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment
Here we weren't respecting SFINAE when evaluating a substituted call to
a consteval function, which caused us to reject the new testcase below.
This patch fixes this by making build_over_call use the SFINAE-friendly
version of cxx_constant_value.
This change causes us to no longer diagnose ahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #7 from Patrick Palka ---
(In reply to Jakub Jelinek from comment #4)
> This one is valid, but before your r12-7264 was incorrectly rejected because
> 8 * baz (0) etc. is wrapped in NON_DEPENDENT_EXPR,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
--- Comment #10 from Richard Biener ---
The issue for FRE is that we have
[local count: 10737416]:
step.val = 610334368;
value.val = 1;
goto ; [100.00%]
[local count: 1073741824]:
# __1 = PHI <0(2), __11(4)>
if (__1 != 100)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #6 from Patrick Palka ---
The reason that the two tests in constexpr-if2.C don't fail with -fchecking=2
after r12-7264 seems to be a latent bug. The error comes from the call to
fold_non_dependent_expr in build_non_dependent_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #9 from Martin Liška ---
You should see the difference in between -D_FORTIFY_SOURCE=2 and
-D_FORTIFY_SOURCE=3 in the attached pre-processed source files.
$ gcc fs2.i -c -O2 -Werror
$ gcc fs3.i -c -O2 -Werror
In file included from
On 3/23/22 19:26, Marek Polacek wrote:
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().
The history of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #8 from Martin Liška ---
Created attachment 52680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52680=edit
libacl/__acl_to_any_text.c with FS == 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #7 from Martin Liška ---
Created attachment 52679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52679=edit
libacl/__acl_to_any_text.c with FS == 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #5 from Patrick Palka ---
Some context: consider the simplified/extended C++20 testcase (the consteval-if
seems to be a red herring):
consteval int foo(int x) { return x; }
template
void bar(int x)
{
constexpr int y = 0;
foo(8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105036
--- Comment #2 from Cristian Assaiante ---
Indeed, we understand some information may be lost for the sake of keeping
debug info correct.
We reported this in the first place because, besides the missing variables, a
wrong function (i.e., foo)
On Mon, 2022-03-14 at 18:38 +0100, David Seifert wrote:
> Use AC_CACHE_CHECK to store the result of the header check for
> systemtap's "sys/sdt.h", which is similar in spirit to libstdc++'s
> AC_CACHE_CHECK(..., glibcxx_cv_sys_sdt_h).
>
> gcc/
> * configure.ac: Add AC_CACHE_CHECK(...,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014
--- Comment #5 from Tom de Vries ---
Minimal test-case:
...
void __attribute__((noinline)) foo (unsigned long long d0) {
unsigned long long __a;
__a = 0x38;
for (; __a > 0; __a -= 8)
if (((d0 >> __a) & 0xff) != 0)
break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039
Nick Clifton changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #1
Hi Guys,
Attached is a proposed patch to fix another Rust demangling bug
reported in PR 105039. I would like to say that this is the
last time that we will see this problem for the Rust demangler,
but I am not that naive...
OK to apply ?
Cheers
Nickdiff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564
--- Comment #3 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:fb488cba571539b6644e8f99f1dd997cdb4c82c1
commit r12-7801-gfb488cba571539b6644e8f99f1dd997cdb4c82c1
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975
--- Comment #4 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:b8c4171ebd72079e55aceadbcfc883f517cdf895
commit r12-7800-gb8c4171ebd72079e55aceadbcfc883f517cdf895
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #54 from Iain Sandoe ---
(In reply to Martin Liška from comment #53)
> > Yes, I forgot to mention that.
> > I hope you are right and someone will make these backports in 10.1, 10.2,
> > 10.3, 11.1, 11.2.
>
> Note one can't rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #53 from Martin Liška ---
> Yes, I forgot to mention that.
> I hope you are right and someone will make these backports in 10.1, 10.2,
> 10.3, 11.1, 11.2.
Note one can't rewrite history, but as written, pull the gcc-11 branch and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #52 from Martin Liška ---
It's fixed on master with r12-3350-g88974974d8188cf1 and it *got* backported to
gcc-11 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #51 from Mkkt Bkkt ---
(In reply to Avi Kivity from comment #50)
> Your reproducer does pass in trunk. So perhaps just a missing backport.
Yes, I forgot to mention that.
I hope you are right and someone will make these backports in
Hi, Jakub:
Thanks for your review.
在 2022/3/24 下午8:41, Jakub Jelinek 写道:
On Thu, Mar 24, 2022 at 08:37:32PM +0800, chenglulu wrote:
libgomp/
* configure.tgt: Add LoongArch triplet.
Ok.
diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index d4f1e741b5a..2cd7272fcd8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #50 from Avi Kivity ---
Your reproducer does pass in trunk. So perhaps just a missing backport.
On Thu, Mar 24, 2022 at 08:37:32PM +0800, chenglulu wrote:
> libgomp/
>
> * configure.tgt: Add LoongArch triplet.
Ok.
> diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
> index d4f1e741b5a..2cd7272fcd8 100644
> --- a/libgomp/configure.tgt
> +++ b/libgomp/configure.tgt
> @@
* contrib/config-list.mk: Add LoongArch triplet.
* gcc/doc/install.texi: Add LoongArch options section.
* gcc/doc/invoke.texi: Add LoongArch options section.
* gcc/doc/md.texi: Add LoongArch options section.
---
contrib/config-list.mk | 4 +-
gcc/doc/install.texi
1 - 100 of 172 matches
Mail list logo
