https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970
--- Comment #1 from Andrew Pinski ---
Isn't this just writing through a named pipe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
--- Comment #6 from Andrew Pinski ---
(In reply to Noah Williams from comment #5)
> It isn't? The library I was trying to compile included the "optional"
> header, and I had looked it up and found it was part of C++ 17, so I thought
> it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115968
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Andrew Pinski changed:
What|Removed |Added
CC||summersnow9403 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Andrew Pinski changed:
What|Removed |Added
CC||akihiko.odaki at daynix dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115291
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
--- Comment #5 from Andrew Pinski ---
See https://libeigen.gitlab.io/docs/TopicPitfalls.html
section "C++11 and the auto keyword" explictly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115965
--- Comment #7 from Andrew Pinski ---
Note valgrind in this case cannot always capture buffer overruns due to it
cann't easily add a redzone (buffer to detect overruns) for stack arrays. This
is why -fsanitize=address is more powerful than both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115965
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 115967, which changed state.
Bug 115967 Summary: ubsan: shift exponent 64 is too large for 64-bit type
HOST_WIDE_INT in ext-dce.cc on line 600 since r15-1901-g98914f9eba5f19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115967
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
Andrew Pinski changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115968
--- Comment #2 from Andrew Pinski ---
See C++11 and the auto keyword section of
https://eigen.tuxfamily.org/dox/TopicPitfalls.html
The problem is that eval() returns a temporary object (in this case a MatrixXd)
which is then referenced by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115968
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115963
--- Comment #1 from Andrew Pinski ---
Note most of the rest of the paragraphs around it say "If the value of the
operand of the delete-expression is not a null pointer value and .." The
question becomes is that an oversight of P3144R2 or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #4 from Andrew Pinski ---
(In reply to Li Pan from comment #3)
> Only x86 implemented the .SAT_TRUNC for scalar, so I bet it is almost the
> same as this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863 ?
No it is a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #17 from Andrew Pinski ---
(In reply to Sam James from comment #14)
> ```
...
> @@ -299452,7 +299451,11 @@ Processing insn:
>REG_DEAD r477:SI
> Trying to simplify pattern:
> (zero_extend:SI (subreg:HI (reg:SI 477) 0))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
--- Comment #2 from Andrew Pinski ---
Anyways this is not a GCC issue.
The AttrBuilder::addAllocSizeAttr is declared in the preprocessed source as:
AttrBuilder (unsigned ElemSizeArg,
const std::optional );
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #11 from Andrew Pinski ---
Can someone please raise this also to
https://github.com/ARM-software/abi-aa/issues ? Looks like the riscv folks are
ahead of the curve of defining the size/alignment here, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115959
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115959
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
--- Comment #2 from Andrew Pinski ---
Hmm actually there are patterns there but they are not matching. Something
seems to be going wrong with define_insn_and_rewrite ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
Andrew Pinski changed:
What|Removed |Added
Keywords||aarch64-sve
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #10 from Andrew Pinski ---
https://gcc.gnu.org/legacy-ml/gcc/2019-08/msg00198.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #9 from Andrew Pinski ---
Note this was raised on the LLVM side back in 2016:
https://github.com/llvm/llvm-project/issues/26836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #8 from Andrew Pinski ---
https://gcc.gnu.org/legacy-ml/gcc/2019-08/msg00191.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> Note it might also be useful to add dbgcnt.def support to ext-dce.cc. If I
> get a chance I might add it too.
I have a patch which implements this; just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110736
Andrew Pinski changed:
What|Removed |Added
CC||iamanonymous.cs at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115956
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #6 from Andrew Pinski ---
https://gitlab.com/x86-psABIs/i386-ABI/-/issues/1 for x86_64 abi.
Aarch64 should most likely also do the same ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82255
--- Comment #14 from Andrew Pinski ---
This sounds very similar to what I am now running into
https://gcc.gnu.org/pipermail/gcc/2024-July/244362.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #11 from Andrew Pinski ---
(In reply to Sam James from comment #10)
> libharfbuzz_subset_la-hb-subset.cc.300r.ext_dce.xz:
> https://dev.gentoo.org/~sam/bugs/gcc/gcc-harfbuzz-dce/libharfbuzz_subset_la-
> hb-subset.cc.300r.ext_dce.xz.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66036
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82255
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #7 from Andrew Pinski ---
Can you attach the file ./arch/arm64/kernel/module.lds ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #5 from Andrew Pinski ---
So according to the linux kernel modules linker script, it should have combined
the .plt sections.
So I am thinking this is a linux kernel issue with an older version of the
kernel.
Can you show exact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115947
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115947
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #14 from Andrew Pinski ---
(In reply to GCC Commits from comment #13)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:de19b516edbf919d31e9d22fdbf6066342d904a2
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #10 from Andrew Pinski ---
(In reply to Guinevere Larsen from comment #9)
> I'm confused because, according to the DWARF spec:
>
> [is_stmt indicates] that the current instruction is a recommended breakpoint
> location. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > If so then the bug is in binutils's as support for the .loc, please report
> > it there instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> If so then the bug is in binutils's as support for the .loc, please report
> it there instead. https://sourceware.org/bugzilla/ .
Maybe it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #8 from Andrew Pinski ---
(In reply to Guinevere Larsen from comment #7)
> I understand that you could have multiple lines related to a single
> instruction (even if I disagree it should happen at -Og). My question is,
> why is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #5 from Andrew Pinski ---
Does `-gno-as-loc-support` adding work? If so this is a binutils (as) bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #3 from Andrew Pinski ---
Created attachment 58674
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58674=edit
output corresponding to `-gno-as-loc-support -dA`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #2 from Andrew Pinski ---
Created attachment 58673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58673=edit
-gno-as-loc-support -dA output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |INVALID
--- Comment #6 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #5 from Andrew Pinski ---
(In reply to Guinevere Larsen from comment #4)
> Could you explain why having a single instruction be a statement and not a
> statement at once is expected?
Because that is expected with optimizations. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
Andrew Pinski changed:
What|Removed |Added
CC||blarsen at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #2 from Andrew Pinski ---
x86_64:
```
_ZN7MyClass4callEv:
.LVL0:
.LFB1:
.file 1 "/app/example.cpp"
.loc 1 7 22 view -0
.cfi_startproc
.loc 1 8 5 view .LVU1
.loc 1 8 23 is_stmt 0 view .LVU2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #1 from Andrew Pinski ---
Note gcc outputs .line directives usually so this could also be a binutils
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
--- Comment #2 from Andrew Pinski ---
See https://gcc.gnu.org/bugs/#need too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #3 from Andrew Pinski ---
https://unix.stackexchange.com/questions/780176/sysfsduplicate-plt-under-sys-modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #2 from Andrew Pinski ---
>I changed my gcc from 7.3.0 to 10.3.1 and recompiled kernel code.
Did you change binutils version too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
Andrew Pinski changed:
What|Removed |Added
CC||rush102333 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115938
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113916
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90790
Andrew Pinski changed:
What|Removed |Added
CC||rush102333 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115941
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97755
--- Comment #2 from Andrew Pinski ---
pedwarn does change into an error with -pedantic-errors .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115941
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> It is not related to PR 109247 since it is rejected in GCC 13.1.0 rather
> than 13.3.0.
s/rather than 13.3.0/rather than just 13.3.0+/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115941
--- Comment #1 from Andrew Pinski ---
It is not related to PR 109247 since it is rejected in GCC 13.1.0 rather than
13.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115858
--- Comment #2 from Andrew Pinski ---
(In reply to Arsen Arsenović from comment #1)
> - clang: permits alloca in coroutines in many cases. by my crude testing,
> it seems to only fail if the size is dynamic and the use of the allocated
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115933
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
--- Comment #10 from Andrew Pinski ---
Created attachment 58663
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58663=edit
Reduced testcase based on suggestion
Reduced testcase based on comment #8.
Notes on it, you need a and b be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115925
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
--- Comment #9 from Andrew Pinski ---
*** Bug 115925 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115925
--- Comment #1 from Andrew Pinski ---
/* x | C -> C if we know that x & ~C == 0. */
(simplify
(bit_ior SSA_NAME@0 INTEGER_CST@1)
(if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 115902, which changed state.
Bug 115902 Summary: [14/15 Regression] Can't call immediate function within "if
consteval" when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115583
Andrew Pinski changed:
What|Removed |Added
CC||gcc at nospam dot
scs.stanford.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115925
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.2
Version|unknown
|15.0
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115927
Andrew Pinski changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864
--- Comment #6 from Andrew Pinski ---
*** Bug 115926 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115926
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115926
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |ipa
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
--- Comment #3 from Andrew Pinski ---
Note better example:
```
#include
uint32_t f(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return ((i2 >> 17) + (aa >> 17) + (aa1 >> 17)) << 17;
}
uint32_t fa(uint32_t i2, uint32_t aa, uint32_t aa1)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
--- Comment #2 from Andrew Pinski ---
Note clang also falls over for 3 additions and swapping the order of the
addition just slightly.
```
#include
int32_t f(int32_t i2, int32_t aa, int32_t aa1)
{
return ((i2 >> 17) + (aa >> 17) + (aa1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115915
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-14
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
template struct extent{};
struct extent t;
struct ::extent t1;
```
GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115915
--- Comment #1 from Andrew Pinski ---
The question is does that friend is naming `::extent` or is naming
`std_1::extent` using the `using namespace` statement. I suspect GCC and EDG
think it is `::extent` while clang and MSVC think it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Andrew Pinski changed:
What|Removed |Added
CC||iamanonymous.cs at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115920
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
1 - 100 of 72015 matches
Mail list logo
