On 4/7/22 18:25, Alexandre Oliva wrote:
Hello, Jason,
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted
as part of the git transition:
https://gcc.gnu.org/contribute.html#patches
Oh, wow, I
On 4/7/22 18:48, Alexandre Oliva wrote:
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
*nod*, thanks
* tree.cc (protected_set_expr_location): Propagate locus to
call wrapped in cast-to-void.
I'm reluctant to put
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105191
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:4822108e61ab879067482704f2f7d1670813d61a
commit r12-8066-g4822108e61ab879067482704f2f7d1670813d61a
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105191
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:4822108e61ab879067482704f2f7d1670813d61a
commit r12-8066-g4822108e61ab879067482704f2f7d1670813d61a
Author: Jason Merrill
Date:
My patch for PR92385 made us use VEC_INIT_EXPR for aggregate initialization
of an array where some elements are not explicitly initialized. Constexpr
handling of that was treating initialization from {} as equivalent to
value-initialization, which is problematic for classes with default member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96604
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:58586721c79f77224b8571a5dba732620d5546ab
commit r12-8065-g58586721c79f77224b8571a5dba732620d5546ab
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:58586721c79f77224b8571a5dba732620d5546ab
commit r12-8065-g58586721c79f77224b8571a5dba732620d5546ab
Author: Jason Merrill
Date:
This rule that for a friend with a qualified name we try to find a
matching template was already in C++98, but it seems we never implemented
it, and nobody reported it until 2019.
This patch sets DECL_IMPLICIT_INSTANTIATION to signal to
check_explicit_specialization that we want to find a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
eggert at cs dot ucla.edu changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #5 from Eric Gallager ---
(In reply to David Malcolm from comment #4)
> As noted in https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592889.html
> the above patch seems to fix "make jit.pdf", but doesn't fix "make jit.dvi";
> it
Sorry for the late reply.
I did check gomp_thread_self but I'm still not sure about what I should do,
maybe because I lack experience/knowledge.
Here is where my thinking is going right now and I hope you tell me if I'm
wrong.
in gomp_thread_to_pthread_t there are 4 possible outputs
1 - if
Snapshot gcc-10-20220408 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20220408/
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
Another simple testcase change for LoongArch. Ok for trunk?
---
LoongArch backend allocates two additional 8-byte stack slots for LP64,
one for saving $fp and another for saving the temporary value "1".
Ideally they are both unneeded, but (1) we're using -O0 so the code is
suboptimized by the
A simple testcase change, tested on loongarch64-linux-gnuabif64. Ok for trunk?
---
On LoongArch, variadic functions use different arugment passing
conventions so this test is not valid (see the section named "Variadic
argument" in the [ELF ABI][1]) and should be skipped.
[1]:
On Wed, Apr 06, 2022 at 03:01:33PM -0500, will schmidt wrote:
> In this context it's not clear what is the "old code" ?
> The mtvsrdd
> instruction is referenced in this code path. I see no direct reference
> to lxvrdx here, though I suppose it's assumed somewhere behind the
> emit_ calls.
The
Dear all,
Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran:
Dear all,
the logic for checking the allocate-coshape-spec in an ALLOCATE
statement was sort of sideways, and allowed to pass invalid
specifications to the code generation.
The fix seems obvious (to me).
after submitting the
On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote:
> I'm excited to read that rustc_codegen_gcc, the libgccjit-based
> backend
> for rustc can now bootstrap rustc:
> https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10
>
> I've been focusing on the analyzer, and so haven't been as
David, it seems you missed this email that contains the updated patch
and a few questions.
Attaching the patch again.
Thanks for the reviews!
On Fri, 2022-01-21 at 11:22 -0500, Antoni Boucher via Jit wrote:
> David: this is the email I was talking about in my other email.
> Here's the updated
On Apr 08 2022, Patrick O'Neill wrote:
> It looks like the file:
> gcc/config/nds32/linux.h
> interacts with the macro:
> #define HAVE_sync_compare_and_swaphi 1
>
> I'm not sure if that's the correct way to do it/if this is defined in a
> different way for targets like x86/ARM/etc.
They are
Hi!
On Mon, Feb 28, 2022 at 11:17:27AM +0800, HAO CHEN GUI wrote:
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to be
>
I'm excited to read that rustc_codegen_gcc, the libgccjit-based backend
for rustc can now bootstrap rustc:
https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10
I've been focusing on the analyzer, and so haven't been as on top of
libgccjit patch review as I should have been. Sorry about
On Fri, 2022-01-21 at 18:41 -0500, Antoni Boucher wrote:
> Hi.
> Here's the updated patch.
>
Thanks. Review below:
[...snip...]
> diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> index 4c352e8c93d..6bf1e1ceee0 100644
> --- a/gcc/jit/libgccjit.cc
> +++ b/gcc/jit/libgccjit.cc
> @@
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
> On 4/1/22 15:14, Marek Polacek wrote:
> > Attribute format takes three arguments: archetype, string-index, and
> > first-to-check. The last two specify the position in the function
> > parameter list. r63030 clarified that "Since
On Sun, 2022-01-30 at 20:38 -0500, Antoni Boucher via Gcc-patches
wrote:
> Hi.
> This patch adds support for setting the alignment of variables in
> libgccjit.
Thanks. Sorry about the delay in reviewing it.
>
> I was wondering if I should change it so that it takes/returns bytes
> instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105191
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Hi Pan RZ,
I appreciate the help - that's a good starting point for the macros.
It looks like the file:
gcc/config/nds32/linux.h
interacts with the macro:
#define HAVE_sync_compare_and_swaphi 1
I'm not sure if that's the correct way to do it/if this is defined in a
different way for targets
On Mon, 2022-04-04 at 21:46 +0530, Mir Immad wrote:
> Hi David,
>
> Sorry for such late reply. I've been busy with classes and exams.
>
> As the contributor applications are opening, I would like to put
> forward a
> proposal for a medium project for extending the static analyzer to work
> with
Hi Patrick,
We are more than delighted to hear that you'd like to implement inlining
subword atomic load/store and exchange as well!
I searched for these macros in the gcc codebase, and it seems like the
internal logic that defines ATOMIC_* builtin macros can be found at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892
--- Comment #2 from David Malcolm ---
Still affects trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105146
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105154
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105153
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105153
* include/std/expected
(expected::expected(expected&&)): Fix constraints.
* testsuite/20_util/expected/cons.cc: Check constructor.
---
libstdc++-v3/include/std/expected
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105154
* include/std/expected (expected::swap): Set
_M_has_value to false for objects that previously had a value.
* testsuite/20_util/expected/swap.cc: Fix test to check void
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105146
* include/std/expected (bad_expected_access): Move constructor
parameter.
* testsuite/20_util/expected/bad.cc: New test.
---
libstdc++-v3/include/std/expected
On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
> As Jakub noted here, we don't have the soft-float support for both m32 and m64
> before, as the bifs are always guarded under hard-float previously.
But that bug was fixed for GCC 12. Or we thought so, at least :-(
> >> What makes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105153
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7b4495d3c4040d8f56c05dd254d76269d4471623
commit r12-8063-g7b4495d3c4040d8f56c05dd254d76269d4471623
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105154
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:0dfaf562521ba97c18398d027bf44a15f802f303
commit r12-8062-g0dfaf562521ba97c18398d027bf44a15f802f303
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105146
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:29e355d0d671c7474935220e8bef784f05143820
commit r12-8061-g29e355d0d671c7474935220e8bef784f05143820
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105161
--- Comment #2 from Alexandre Oliva ---
Debug binds in edges was something I considered for some time, but concluded it
would be unlikely to bring useful debug information: the confluence operator
for debug-bind-capable decls during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
--- Comment #11 from Tomas Kalibera ---
Thanks for the very quick fix! I confirm that when R is built with the fixed
version of GCC 12, the R testcase for MASS is fixed, it works with -O2.
On Thu, Apr 07, 2022 at 03:00:14PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 07, 2022 at 06:09:52AM -0500, Segher Boessenkool wrote:
> > On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote:
> > > As PR103623 shows, it's a regression failure due to new built-in
> > > function framework,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104668
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Hi RZ Pan,
I'll start working on the atomic store/exchange stuff. It shouldn't be
too difficult to add since it will have similar masking logic to
atomic fetch.
Also - I briefly looked and couldn't find the place where those macro's
values for RISC-V are defined in GCC. If anyone can point me
On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #13 from Jakub Jelinek ---
Created attachment 52774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52774=edit
gcc12-pr104639.patch
Untested patch to optimize this in phiopt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #5 from Segher Boessenkool ---
It does not show up with any configuration I have tried, so clearly it needs
something more :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #4 from Arseny Solokha ---
It is not target-dependent and, besides x86_64, can be reproduced at least at
powerpc and aarch64 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105182
kargl at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Add
AC_CONFIG_MACRO_DIRS([../config])
So that just running:
$ autoreconf -vf
... does the right thing (no need to specify -I ../config).
Note: I don't have access to the gcc repo, so if this patch is approved,
can somebody push it there on my behalf? I can push it to binutils-gdb.
On Fri, Apr 08, 2022 at 03:09:00PM +0800, Kewen.Lin wrote:
> As PR103623 shows, it's a regression failure due to new built-in
> function framework, previously we guard __builtin_{un,}pack_{longdouble,
> ibm128} built-in functions under hard float, so they are unavailable
> with the given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #3 from Segher Boessenkool ---
Lol, this isn't a PowerPC issue at all. Please fill out the target field?
How can there be a difference in the number of uses only (and no difference
in actual uses!)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #2 from Segher Boessenkool ---
I cannot reproduce this problem, what other flags does it need to reproduce?
On 2022-04-08 10:32, Nick Clifton wrote:
> Hi Simon,
>
>> Ping.
>
> Patch approved - please apply.
>
> I appreciate that modifying these top level files is a bit nerve
> wracking, but I think that you have done a good job in this case. :-)
>
> Cheers
> Nick
>
Thanks Nick, pushed.
Simon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98886
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
Hi,
This patch is removing unnecessary armv9-a multilib variant which was
introduced in commit 32ba7860ccaddd5219e6dae94a3d0653e124c9dd (add
armv9-a architecture to -march). Now armv9-a(+simd) multilibs point to
already existing armv8-a(+simd) ones as there are no changes between
the two.
Users
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105204
--- Comment #1 from Piotr Grabowski ---
Created attachment 52773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52773=edit
example shared pointer implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105204
Bug ID: 105204
Summary: -Wuse-after-free=1 inconsistency with conditional free
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi!
Thanks for investigating.
On Fri, Apr 08, 2022 at 03:25:51PM +0800, Kewen.Lin wrote:
> on 2022/4/8 3:29 AM, Segher Boessenkool wrote:
> > On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote:
> >> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
> >>> As PR103196
Hi Simon,
Ping.
Patch approved - please apply.
I appreciate that modifying these top level files is a bit nerve
wracking, but I think that you have done a good job in this case. :-)
Cheers
Nick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #6 from Richard Earnshaw ---
That should have said 'years'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #5 from Richard Earnshaw ---
If you look at the examples I cite you'll find they rarely, if ever, change
because of changes to GCC. This interface has been stable for year.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
--- Comment #10 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:5522dec054cb940fe83661b96249aa12c54c1d77
commit r12-8060-g5522dec054cb940fe83661b96249aa12c54c1d77
Author: Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #4 from R. Diez ---
That is certainly a way to fix the crt0 nuisance. But it requires some specs
file black magic, so yet another thing to learn. And then you have to keep up
with GCC in case something changes around the specs files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99893
Patrick Palka changed:
What|Removed |Added
Target Milestone|12.0|11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99893
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:2837450c4e8f5f241db5519977ab24c1f871258f
commit r11-9801-g2837450c4e8f5f241db5519977ab24c1f871258f
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103885
--- Comment #3 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:2837450c4e8f5f241db5519977ab24c1f871258f
commit r11-9801-g2837450c4e8f5f241db5519977ab24c1f871258f
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Hi Luis,
There is a CVE [1] for zlib < 1.2.12 (released march 27th).
GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory
from GCC. The recommendation is to get it updated to 1.2.12, which contains the
proper fix [2].
I am all for updating the binutils-gdb copy of
Ankur,
> I was browsing the list of submitted GSoC projects this year and the
> project regarding bypassing assembler when generating LTO object files
> caught my eye.
I apologize for late reply. I would be very happy to mentor this
project.
>
> I already have a gcc built from source (sync-ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
Richard Biener changed:
What|Removed |Added
Summary|[9/10/11 Regression] Wrong |[9/10 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:542c30dc4d220f6d2138e55d5fb8e1529339badf
commit r11-9800-g542c30dc4d220f6d2138e55d5fb8e1529339badf
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
--- Comment #7 from Richard Biener ---
(In reply to R. Diez from comment #6)
> I am experimenting with a GCC 11.2 cross-compiler for bare-metal embedded
> software.
>
> There is no operating system, so no shared libraries or anything fancy. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > Btw, a good example might be how we handle .vtable_map_vars for VTV which
> > uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> Btw, a good example might be how we handle .vtable_map_vars for VTV which
> uses handle_vtv_comdat_section instead of switch_to_section. It might have
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200
--- Comment #3 from Florian Albrechtskirchinger ---
(In reply to Jakub Jelinek from comment #2)
> If one defines instead say bool operator<(const foo, const foo);
> then the built-in candidate isn't considered because of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169
--- Comment #10 from Richard Biener ---
Btw, a good example might be how we handle .vtable_map_vars for VTV which
uses handle_vtv_comdat_section instead of switch_to_section. It might have
more specialities but then it should serve as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
Richard Biener changed:
What|Removed |Added
Summary|[9/10/11/12 Regression] |[9/10/11 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e5453bcc217ea4ac53a4ac277661d6ef0ccd425b
commit r12-8059-ge5453bcc217ea4ac53a4ac277661d6ef0ccd425b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105202
--- Comment #3 from Jakub Jelinek ---
I don't know.
https://eel.is/c++draft/dcl.fct.def.default#1.1
says that defaulted comparison operator function doesn't have to be a special
member function, but then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105202
--- Comment #2 from Florian Albrechtskirchinger ---
(In reply to Martin Liška from comment #1)
> Is the code invalid, right?
I'd say so, yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169
--- Comment #9 from Martin Liška ---
> + const char *sname = "__patchable_function_entries";
> + const char *name = DECL_SECTION_NAME (current_function_decl);
> +
> + dot = strchr (name + 1, '.');
> + if (!dot)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
Richard Biener changed:
What|Removed |Added
Summary|[11/12 Regression] Wrong|[9/10/11/12 Regression]
When predictive commoning looks for a looparound PHI it tries
to match the entry value definition (a load) up with the appropriate
member of the chain. But it fails to consider stmts clobbering
the very same memory location inbetween the load and loop entry.
In theory we could be more clever on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-04-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105202
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
On Fri, Apr 8, 2022 at 12:55 PM Martin Jambor wrote:
>
> Hi,
>
> a scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of
> platforms. I investigated only i?86-*-* with -mno-sse but assume the
> issue is the same on all of the affected platform.
>
> Because function bar is not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200
--- Comment #2 from Jakub Jelinek ---
If one defines instead say bool operator<(const foo, const foo);
then the built-in candidate isn't considered because of
https://eel.is/c++draft/over.match.oper#3.3
But for the user operator<=> vs. built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
--- Comment #5 from Martin Jambor ---
I proposed to increase the parameter specification in the test in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592994.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
--- Comment #5 from Richard Biener ---
So before pcom we have
[local count: 114863530]:
j_29 = k_28(D) + -1;
_1 = (long unsigned int) j_29;
_2 = _1 * 4;
_3 = x_30(D) + _2;
_4 = *_3;
_5 = _4 + 1;
*_3 = _5;
if (j_29 > 0)
Hi,
a scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of
platforms. I investigated only i?86-*-* with -mno-sse but assume the
issue is the same on all of the affected platform.
Because function bar is not inlined there even though it is only called
once, the process that is being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
--- Comment #8 from Richard Earnshaw ---
(In reply to CVS Commits from comment #7)
> The releases/gcc-11 branch has been updated by Richard Biener
> :
>
> https://gcc.gnu.org/g:5155015ce57dc133e006f87fdf0237a5f259bebd
>
Just to note that on
"Andre Vieira (lists)" writes:
> On 08/04/2022 08:04, Richard Sandiford wrote:
>> I think this would be better as a static assert at the top level:
>>
>>static_assert (TARGET_CPU_generic < TARGET_CPU_MASK,
>> "TARGET_CPU_NBITS is big enough");
> The motivation being that you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
--- Comment #4 from Martin Jambor ---
I expected that the only call of bar in the testcase to be always
inlined everywhere but apparently it is not at least on i?86-*-* with
-mno-sse (and I expect the problem to be the same on the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
Hi!
I noticed the discussions about making cp-demangle use malloc/free instead of
recursion,
and I wonder about signal handlers, and I don't see that mentioned in
https://gcc.gnu.org/wiki/SummerOfCode's description of the project.
See my question to Ian a few years back, here, and his answer:
1 - 100 of 143 matches
Mail list logo
