https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
My stepping out of gfortran activities has been for rather longer than I
expected. I had hoped to have completed the finalization work by now and to
have got on with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #6 from Kewen Lin ---
(In reply to Fangrui Song from comment #5)
> * There is a restriction on the number of instructions between the function
> label and the .localentry directive.
> * For -fpatchable-function-entry=N[,M], M nops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
--- Comment #6 from Stefan Schulze Frielinghaus
---
Created attachment 53433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53433=edit
a-t2.c.325r.vartrack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578
--- Comment #4 from Gökçe Aydos ---
Just to clarify my entry:
In my opinion gcc should not fire a warning in my first example. In case
`realloc` was not successful, then `realloc` does not touch its argument. I
should be able to use its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #3 from Francois-Xavier Coudert ---
The module in the runtime library is compiled only once, unless the library is
multilib (one libgfortran compiled for IBM double double, one libgfortran
compiled for IEEE quad).
My goal would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104992
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8e69f2a6e91b7a01619dfd3b0788bfda4ad28941
commit r13-2018-g8e69f2a6e91b7a01619dfd3b0788bfda4ad28941
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106243
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:621f5362253f00b910686e8221e6756457f71e81
commit r13-2019-g621f5362253f00b910686e8221e6756457f71e81
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
Bug ID: 106582
Summary: Wrong code generation resulting in HardFault
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410
--- Comment #6 from Zopolis0 ---
I found success in simply disabling the check at line 3754 of
gcc/cp/name-lookup.cc by setting it to 'if (1 != 1)', which then generated an
ICE at line 2484 of gcc/cp/name-lookup.cc, so I simply disabled the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
--- Comment #5 from Stefan Schulze Frielinghaus
---
However, I found another example (see attachment a-t2.c.325r.vartrack) which
does not profit from the patch:
__attribute__((noinline, noclone)) void
fn1 (int x)
{
__asm volatile ("" : "+r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
Richard Biener changed:
What|Removed |Added
Target||arm-none-eabi
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #2 from Piotr ---
Created attachment 53434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53434=edit
Preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106583
Bug ID: 106583
Summary: Suboptimal immediate generation on aarch64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
--- Comment #4 from Stefan Schulze Frielinghaus
---
I really like the idea of enhancing cselib since there is a chance that other
passes might profit from it, too. The following patch fixes the initial
reported problem:
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #4 from Jakub Jelinek ---
Ok, I'll first implement __builtin_issignaling and then
conv_intrinsic_ieee_{value,class}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #3 from Piotr ---
(In reply to Richard Biener from comment #1)
> Can you provide preprocessed source of the file where the crash occurs and
> the compiler commandline? Can you also try GCC 10.4 (or a compiler built
> from
> the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:16b013c9d9b4d950f89821476e791bf18c1295df
commit r13-2020-g16b013c9d9b4d950f89821476e791bf18c1295df
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53164
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #25 from David Malcolm ---
Created attachment 53435
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53435=edit
v1 of a patch to implement -Wxor-used-as-pow
This patch implements the warning, but doesn't work well; as noted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #8 from Yuri Gribov ---
(In reply to Jakub Jelinek from comment #7)
I've started work on this but I'll probly only have enough time to cook a patch
on weekend.
> Perhaps either a quick check that for base ptrs that live in memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
Bug ID: 106584
Summary: g++ not showing correct line number in "use of deleted
function" error
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:04ce2400b35225302e0d6883bb0817378180f5d7
commit r13-2022-g04ce2400b35225302e0d6883bb0817378180f5d7
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Summary|[11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 102633, which changed state.
Bug 102633 Summary: [11/12 Regression] warning for self-initialization despite
-Wno-init-self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #4 from Andrew Pinski ---
>
080157fe: movsr3, #0
08015800: ldr.w r2, [r9, #20]
08015804: str r2, [r3, #12]
This is doing a store at the address 12 which is invalid normally.
I suspect for your code you need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #9 from Jakub Jelinek ---
If maybe_get_single_definition returns a SSA_NAME or is_gimple_min_invariant,
then it is ok as is and doesn't need anything new.
Otherwise I think we need to ask the alias oracle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
--- Comment #1 from Devourer Station ---
Created attachment 53436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53436=edit
Preprocessed source file
compile with g++ example.cpp -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
--- Comment #2 from Devourer Station ---
Created attachment 53437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53437=edit
compiler's output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #1 from Andrew Pinski ---
Created attachment 53439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53439=edit
bzip2 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #5 from Kito Cheng ---
bset generated after change X to GPR for most zbs pattern:
```
foo:
bseta1,x0,a1
andna0,a0,a1
sext.w a0,a0
ret
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #6 from Andrew Pinski ---
There is much more changes needed for ZBS support to work correctly for 32bit.
And some to get it to good state for 64bits.
I will be fixing all of them but first I need to setup a test env.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101976
--- Comment #1 from Dmitry Prokoptsev ---
I believe I stumbled on this one as well -- see
https://godbolt.org/z/or31cz6eW, although it's not as trivial as the snippet
provided here.
Reproduces in 10.3 and all subsequent versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780
--- Comment #8 from S. Davis Herring ---
I looked at P2266R3 again; it claims that the conversion function case (in #7)
is actually covered by P1825R0. I think that case is questionable, since it
still refers to "overload resolution to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #11 from joseph at codesourcery dot com ---
On Wed, 10 Aug 2022, michael.hudson at canonical dot com via Gcc-bugs wrote:
> I just changed
>
> z = xx * xx;
>
> to
>
> z = math_opt_barrier(xx * xx);
>
> which perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Jakub Jelinek changed:
What|Removed |Added
Attachment #53438|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
Piotr changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
Bug ID: 106586
Summary: riscv32 still broke with zba_zbb_zbc_zbs, ICE in
do_SUBST in C++ code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #2 from Andrew Pinski ---
Reducing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #4 from Andrew Pinski ---
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 5a0adffb5ce..b4a08de6b93 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -426,7 +426,9 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551
--- Comment #3 from CVS Commits ---
The master branch has been updated by Immad Mir :
https://gcc.gnu.org/g:837142257cbde3cc03ee0dacd1d7b2fb4fa48bae
commit r13-2023-g837142257cbde3cc03ee0dacd1d7b2fb4fa48bae
Author: Immad Mir
Date: Thu Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #6 from Jakub Jelinek ---
Created attachment 53438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53438=edit
gcc13-builtin-issignaling.patch
Current WIP on the __builtin_issignaling.
Still need to look at decimal arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106587
Bug ID: 106587
Summary: RISCV invalid jump address when compiled with
-fcall-saved-reg and TCO
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #12 from Michael Hudson-Doyle
---
Ah OK, yes that fixes the failure. Does this mean all uses of
SET_RESTORE_ROUND* should be using math_opt_barrier / math_force_eval to avoid
this issue? Sounds awkward. I guess having a macro to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #7 from Andrew Pinski ---
It is address 12, that is offset 12 from address 0.
And yes there is a path where pQueryChunk can still be null pointer.
If pPage->dwOptions & (0x2000) is false and (pQuery is nulll or *pQuery !=
'?'),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
void f(int);
void g(long long __off)
{
const int max = (1u << 31) - 1;
while (__off > max)
{
f(max);
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106588
Bug ID: 106588
Summary: The constraints on most of the patterns in bitmanip.md
are broken
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #5 from Piotr ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe: movsr3, #0
> 08015800: ldr.w r2, [r9, #20]
> 08015804: str r2, [r3, #12]
>
> This is doing a store at the address 12 which is invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
David Malcolm changed:
What|Removed |Added
Keywords||patch
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589
Bug ID: 106589
Summary: visit rejects lambdas that do not return void
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
Bug ID: 106590
Summary: x86-64 miscompilation starting with "i386: Improve
ix86_expand_int_movcc" w/ mtune=skylake
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:6aaaf20ee4ad9c85f3099ef425720547644fb08d
commit r12-8682-g6aaaf20ee4ad9c85f3099ef425720547644fb08d
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #8 from Andrew Pinski ---
(In reply to jiawei from comment #7)
> I had roll back the RISC-V commit and found that this modification cause
> this building failure.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
jiawei changed:
What|Removed |Added
CC||jiawei at iscas dot ac.cn
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589
--- Comment #1 from 康桓瑋 ---
variant#L1730:
if constexpr (sizeof...(_Variants) == 0)
return std::forward<_Visitor>(__visitor)();
In this branch, we seem to need to detect if _Result_type is void and
explicitly cast the return type to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
--- Comment #13 from CVS Commits ---
The releases/gcc-11 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:df8567535a1f3eaa20b700be62374b2fb4f09204
commit r11-10201-gdf8567535a1f3eaa20b700be62374b2fb4f09204
Author: Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
--- Comment #1 from Andres Freund ---
Created attachment 53441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53441=edit
reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
Sergio Durigan Junior changed:
What|Removed |Added
CC||sergiodj at sergiodj dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
--- Comment #5 from Andrew Pinski ---
Created attachment 53442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53442=edit
testcase that should be ready for gcc.c-torture/execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
--- Comment #2 from Andrew Pinski ---
r12-8233-g1ceddd7497e15d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #8 from Alan Modra ---
(In reply to Segher Boessenkool from comment #7)
> '-fpatchable-function-entry=N[,M]'
> Generate N NOPs right at the beginning of each function, with the
> function entry point before the Mth NOP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
--- Comment #4 from Andrew Pinski ---
So the IR is slightly different entering CE1. The two BB for the sides of the
if are swapped. But that is the only difference.
This is definitely a latent bug that got exposed, it is not the first latent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #7 from Segher Boessenkool ---
'-fpatchable-function-entry=N[,M]'
Generate N NOPs right at the beginning of each function, with the
function entry point before the Mth NOP.
The nops have to be consecutive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
Bug ID: 106585
Summary: RISC-V: Mis-optimized code gen for zbs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106584
--- Comment #4 from Andrew Pinski ---
Actually clang references the call:
f(cl);
When it comes to the copy constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #1 from Andrew Pinski ---
Interesting rv32i_zbb produces:
foo:
bclra0,a0,a1
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #2 from Andrew Pinski ---
One issue is RV32i_zbb produces:
(insn 8 4 9 2 (set (reg:SI 78)
(ashift:SI (const_int 1 [0x1])
(subreg:QI (reg/v:SI 76 [ rs2 ]) 0))) "t6.c":3:20 323 {*bsetsi_1}
(expr_list:REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #3 from Andrew Pinski ---
(define_insn "*bset"
[(set (match_operand:X 0 "register_operand" "=r")
(ior:X (ashift:X (const_int 1)
(match_operand:QI 2 "register_operand" "r"))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780
--- Comment #7 from S. Davis Herring ---
> In the withMove case, in C++20, we issue:
> warning: moving a local object in a return statement prevents copy elision
> for
> template Dest withMove();
> and:
> warning: redundant move in return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #4 from Kito Cheng ---
> It uses X iterator here instead of GPR, hmmm ...
I think that because we have w-variant before, so use X rather than GPR here,
but apparently we should revise this.
80 matches
Mail list logo
