https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813
--- Comment #1 from Zhendong Su ---
Compiler Explorer: https://godbolt.org/z/6cfcq4Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813
Bug ID: 104813
Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in
adjust_references_in_caller, at ipa-cp.cc:4963
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104762
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929
--- Comment #7 from Richard Biener ---
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 9188d727e33..7f1f12fb6c6 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -2374,7 +2375,7 @@ fail:
From: Sören Tempel
The .regs member is primarily intended to be used in conjunction with
ptrace. Since this code is not using ptrace, using .regs is a bad idea.
Furthermore, the code currently fails to compile on musl since the
pt_regs type (used by .regs) is in an incomplete type which has to
在 3/5/22 07:21, Gerald Pfeifer 写道:
Slovakia, Bratislava: http://gcc.fyxm.net/;>gcc.fyxm.net, thanks
to Jan Teluch (ad...@2600.sk)
+Taiwan, Hsinchu: https://free.nchc.org.tw/gcc/;>nchc.org.tw, thanks
to FSLab Team, NCHC (fs...@nchc.org.tw)
Please stop naming Taiwan like that. `China,
Dear Gerald,
I'm Ceasar Sun , from Free Software Lab, NCHC , Taiwan.
We provide several free software mirror service in Taiwan : free.nchc.org.tw
We would like to become a gcc mirror site and the service would be presented
as :
Country : Taiwan ,TW
City: Hsinchu
Site:
Met some problem in git send-email --cc=a,b,c, so manually CC.
On Mon, Mar 7, 2022 at 1:11 PM liuhongt via Gcc-patches
wrote:
>
> >What happens if you set preferred_for_speed to false for alternative 1?
> It works, and I've removed the newly added splitter in this patch.
> Also i tried to do
>What happens if you set preferred_for_speed to false for alternative 1?
It works, and I've removed the newly added splitter in this patch.
Also i tried to do similar things to *vec_dup with mode iterator
AVX2_VEC_DUP_MODE, but it hit ICE during reload since x86 don't have direct
move for QImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812
Bug ID: 104812
Summary: Construct-name with same variable name in scope
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi, Richard:
Thanks for your review.
We will revise it as soon as possible and submit it in the next version.
在 2022/3/7 上午12:16, Richard Sandiford 写道:
Hi,
Some comments below, but otherwise it looks good to me.
xucheng...@loongson.cn writes:
[…]
+(define_memory_constraint "k"
+ "A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104811
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104811
Bug ID: 104811
Summary: maxloc/minloc cannot accept character arguments
without `dim` optional argument.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
On Sat, Mar 5, 2022 at 4:05 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because the cond_andv* expander
> has vector_operand predicates in both of the commutative inputs
> and calls gen_andv*_mask which calls ix86_binary_operator_ok
> in its condition, but nothing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104616
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-03-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104613
--- Comment #1 from Andrew Pinski ---
struct _Unwind_Context _Unwind_Resume_or_Rethrow_this_context;
void offset (int);
struct _Unwind_Context {
void *reg[7];
} _Unwind_Resume_or_Rethrow() {
struct _Unwind_Context cur_contextcur_context =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104615
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104809
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Snapshot gcc-12-20220306 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20220306/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi,
On Sun, Mar 06, 2022 at 11:20:56PM +0100, Mark Wielaard wrote:
> On Sun, Mar 06, 2022 at 10:01:10PM +, build...@builder.wildebeest.org
> wrote:
> > The Buildbot has detected a new failure on builder gccrust-debian-arm64
> > while building gccrust.
> > Full details are available at:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104808
--- Comment #2 from Roland Illig ---
(In reply to Andrew Pinski from comment #1)
> these are in debug_* functions so they don't need to be translated as they
> are not user visible at all.
> That is they are only used while debugging GCC.
If
On Sun, Mar 06, 2022 at 10:01:10PM +, build...@builder.wildebeest.org wrote:
> The Buildbot has detected a new failure on builder gccrust-debian-arm64 while
> building gccrust.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/58/builds/1716
>
>
The Buildbot has detected a new failure on builder gccrust-debian-arm64 while
building gccrust.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/58/builds/1716
Buildbot URL: https://builder.wildebeest.org/buildbot/
Worker for this Build: debian-arm64
Build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552
--- Comment #26 from Roland Illig ---
>From cp/module.cc:
> returning to the gate for a mechanical issue
This diagnostic is a fatal error. Fatal errors must be actionable. This
diagnostic isn't actionable, instead it increases confusion for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552
--- Comment #25 from Roland Illig ---
>From cp/module.cc:
inform (loc, "compiler is %sversion %s%s%s",
IS_EXPERIMENTAL (my_ver) ? "experimental " : "",
my_string,
reject_p ? "" :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552
--- Comment #24 from Roland Illig ---
>From cp/module.cc:
> error_at (loc, "compiled module is %sversion %s",
> IS_EXPERIMENTAL (their_ver) ? "experimental " : "",
> their_string);
The word "experimental" must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104810
Bug ID: 104810
Summary: Wrong order of "note: ... this enumerator %qD"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic, testsuite-fail
Severity:
On Sun, Mar 06, 2022 at 07:59:24PM +0100, soe...@soeren-tempel.net wrote:
> From: Sören Tempel
>
> The .regs member is primarily intended to be used in conjunction with
> ptrace. Since this code is not using ptrace, using .regs is a bad idea.
> Furthermore, the code currently fails to compile on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104809
Bug ID: 104809
Summary: Explain ELRoND to translators
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104808
--- Comment #1 from Andrew Pinski ---
these are in debug_* functions so they don't need to be translated as they are
not user visible at all.
That is they are only used while debugging GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104806
--- Comment #1 from Andrew Pinski ---
Actually "__dt " should not be recommended at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104808
Bug ID: 104808
Summary: unclear diagnostic "MAP %qD TO %qT"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104807
Bug ID: 104807
Summary: x86_64-w64-mingw32 target does not have visibility
setting
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
--- Comment #6 from Andrew Pinski ---
See
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Optimize-Options.html#index-fomit-frame-pointer
From: Sören Tempel
The .regs member is primarily intended to be used in conjunction with
ptrace. Since this code is not using ptrace, using .regs is a bad idea.
Furthermore, the code currently fails to compile on musl since the
pt_regs type (used by .regs) is in an incomplete type which has to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104636
--- Comment #6 from Jakub Jelinek ---
If you have something in between {}s it will be an error, not a pedwarn
(pedwarn will emit a warning with -Wpedantic and error with -pedantic-errors).
I believe the reason why it is a pedwarn in the {} case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104636
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
> PR target/104781
> * config.host (tmake_file): Add i386/32/t-eh-return-no-sse for
> 32-bit x86 Cygwin and Solaris.
> * config/i386/32/t-eh-return-no-sse: New file.
What about MinGW here?
--
Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
Eric Gallager changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99297
Eric Gallager changed:
What|Removed |Added
Keywords||easyhack
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104797
Eric Gallager changed:
What|Removed |Added
Severity|normal |trivial
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104795
Eric Gallager changed:
What|Removed |Added
Keywords||easyhack
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104795
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96248
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Eric Gallager changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
On Sun, Mar 06, 2022 at 10:22:56AM -0500, Rich Felker wrote:
> On Mon, Feb 21, 2022 at 09:25:43AM -0800, Ian Lance Taylor via Gcc-patches
> wrote:
> > Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
> > using uc_regs instead of regs, which does look correct to me.
>
> Yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104636
--- Comment #4 from Artur Bać ---
So conclusion from Your arguments is to me that -std=c++20 doesn't guarantee
strict c++20 compatibility as another switches are required to force explicit
constructor be used only explicitly and disallow
Hi,
Some comments below, but otherwise it looks good to me.
xucheng...@loongson.cn writes:
> […]
> +(define_memory_constraint "k"
> + "A memory operand whose address is formed by a base register and
> (optionally scaled)
> + index register."
> + (and (match_code "mem")
> + (not
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file,
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file,
On Mon, Feb 21, 2022 at 09:25:43AM -0800, Ian Lance Taylor via Gcc-patches
wrote:
> Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
> using uc_regs instead of regs, which does look correct to me.
Yes, this is absolutely the correct fix. Having pt_regs appear at all
in code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90597
Roger Sayle changed:
What|Removed |Added
Target Milestone|9.5 |12.0
CC|
Hi,
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 already have a gcc built from source (sync-ed with trunk/master) and
launched the test-suite on it.
I am currently in process of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
--- Comment #5 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #4)
> rbp is hard frame pointer, so depending on whether the function needs a
> frame pointer (at -O0 I think all functions do), the register isn't
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104806
Bug ID: 104806
Summary: Weird error message: did you mean "__dt "
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
--- Comment #4 from Jakub Jelinek ---
rbp is hard frame pointer, so depending on whether the function needs a frame
pointer (at -O0 I think all functions do), the register isn't available for use
(and therefore for clobbering) in inline asm.
What would be the benefit of using .uc_regs instead of .regs? The
current code works entirely fine as it, it just needs an include of the
Linux Kernel header defining the pt_regs type (which my proposed patch
adds).
Furthermore, it seems to me that .uc_regs is only available on powerpc
but not on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104801
Pawel P changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104801
--- Comment #3 from 康桓瑋 ---
(In reply to Pawel P from comment #2)
> I understand. Thank you for clarification
You should close with RESOLVED INVALID since there is nothing to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104801
Pawel P changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
--- Comment #3 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Clobber of "rsp" makes no sense, you can't change the value of the stack
> pointer in inline asm without restoring it back before the end of inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804
--- Comment #4 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #3)
> What exactly are you trying to achieve (because & on your testcase makes no
> sense at all, the other input is "r" and therefore can't ever match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
--- Comment #2 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Clobber of "rsp" makes no sense, you can't change the value of the stack
> pointer in inline asm without restoring it back before the end of inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804
--- Comment #3 from Jakub Jelinek ---
As I wrote, the only way to implement +m reliably in gcc is to lower it
immediately as "=m" (whatever) ... "0" (whatever) with ensuring that
side-effects in whatever are evaluated just once.
And, in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805
Bug ID: 104805
Summary: [12.0] x86_64 Extended asm may use rbp register to
input/output even thougth "rbp" is in the clobber list
when "rsp" and "rbp" are both in the in the clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804
--- Comment #2 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #1)
> +m is handled as =m with corresponding m, early clobber for that doesn't
> make sense, on one side you require that the input is the same as the
>
This updates gcc.dg/lower-subreg-1.c to reflect that the i386 backend now
lowers iordi3 itself, rather than relying on the middle-end's subreg1 pass.
Committed as obvious. Sorry for the noise; my "-m32 -march=cascadelake"
scripts were looking for regressions in gcc.target/i386 [now corrected].
On Mär 06 2022, Richard Sandiford via Gcc-patches wrote:
> Similarly here we need to avoid bash's $(...).
$(...) is 100% POSIX.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi,
Thanks for the submission. Some comments below on this patch,
but otherwise it looks good. I hope to get to the other patches
in the series soon.
I haven't followed all of the previous discussion, so some of these
points might already have been discussed. Sorry in advance if so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
On Sat, Mar 05, 2022 at 09:33:58AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in other formats used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804
Bug ID: 104804
Summary: [12.0] x86_64 Extended asm always failed with "+=m" in
Output Operands and wrong error info
Product: gcc
Version: 12.0
Status: UNCONFIRMED
75 matches
Mail list logo
