https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #7 from Jerry DeLisle ---
In list_read.c we have this comment:
/* To read a logical we have to look ahead in the input stream to make sure
there is not an equal sign indicating a variable name. To do this we use
line_buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #6 from Jerry DeLisle ---
What is happening here is that in the name list input, the variable flp is also
a legal LOGICAL value, so our read is interpreting it as the second value of
the array flc and trying to continue to read value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109851
Bug ID: 109851
Summary: False positive va_arg when iterating through format
string with for-loop
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #15 from Christoph Reiter ---
(In reply to Thomas Neumann from comment #12)
> Created attachment 55037 [details]
> radix sort fix
>
> I could reproduce the problem, the radix sort did not behave correctly when
> we ran out of bits,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87379
--- Comment #3 from Sam James ---
This is a bit of (not entirely, but a lot of) what I was reaching for in
PR109835. I knew there was a ppc64 example in my head but I couldn't find it.
It's also a good argument for just doing it entirely for fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #4 from Sam James ---
(In reply to Eric Gallager from comment #3)
> I thought that there was already a separate bug for this, but it turns out
> that I was thinking of bug 87379, which is for something different...
Good catch. I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
--- Comment #4 from Andrew Pinski ---
And yes it is a dup:
void
LocalStorage::recompress
{
[&](const auto& l1_index, const auto& l1_progress_receiver) {
[&](const auto& l2_index, const auto& l2_progress_receiver) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
Andrew Pinski changed:
What|Removed |Added
CC||psmith at gnu dot org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
Andrew Pinski changed:
What|Removed |Added
Known to fail||12.3.0, 13.0
Target Milestone|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
--- Comment #2 from Paul Smith ---
I don't know if this is of any use but I ran under valgrind and get this
result:
==3019683== Command:
/data/src/build/x86_64-linux/cc/unknown/bin/../libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus
-fprepro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #2 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #0)
> saving an instruction. Why we do not move stack+8 updating out of the loop?
Maybe because of a clobber:
cur$second_5 = MEM[(const struct pairD.26349 &)_7 +
1844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
Paul Smith changed:
What|Removed |Added
CC||psmith at gnu dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #1 from Andrew Pinski ---
Actually why didn't we copy the loop header in the first place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
Bug ID: 109850
Summary: ICE compiling ccache 4.8
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #8 from Andrew Pinski ---
Created attachment 55079
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55079&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
--- Comment #2 from Neil Carlson ---
Amusing! I have a regression in 13.1 (which I need to create a reproducer for)
where the workaround for a segfault is to use a RESULT variable -- just the
opposite :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug ID: 109849
Summary: suboptimal code for vector walking loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848
Bug ID: 109848
Summary: [14 Regression] Recent change causing testsuite ICE on
csky port
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109847
Bug ID: 109847
Summary: -Wanalyzer-out-of-bounds false positive with Emacs
tagged pointers
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
Bug ID: 109846
Summary: [rejects valid] Pointer-valued function reference
rejected as actual argument
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #9 from Sergio Durigan Junior ---
at(In reply to Richard Biener from comment #8)
> This works for me. The consistency check is not fully implemented and
> instead
> of passing down no -fdebug-prefix-map the patch passes the first bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-13
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845
--- Comment #1 from Andrew Pinski ---
Created attachment 55077
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55077&action=edit
full testcase
Next time please attach the full compilable testcase or paste it inline rather
than just includi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845
Bug ID: 109845
Summary: Addition overflow/carry flag unnecessarily put in a
temporary register
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109844
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
Andrew Pinski changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109844
Bug ID: 109844
Summary: Unnecessary basic block with single jmp instruction
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109843
Bug ID: 109843
Summary: signbit comparisons -> copysign optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> I need to double check if == 1 will show up here though.
The only thing we know about __builtin_signbit is that is 0 or non-zero. The
exact value is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
Andrew Pinski changed:
What|Removed |Added
CC||141242068 at smail dot
nju.edu.cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #26 from Janez Zemva ---
I am a c++ user, so I don't like using c header files if at all possible. I am
pleased with how things are: I now compile/link a replacement libm and replace
the sloppy djgpp header files, but I haven't teste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
--- Comment #5 from Gabriel Ravier ---
Also, as an extra note, w.r.t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911#c3, I've just noticed that I
had indeed made a separate bug report at https://gcc.gnu.org/PR94912 (which
ended up being close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109817
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
--- Comment #11 from Uroš Bizjak ---
(In reply to David Binderman from comment #10)
> (In reply to Uroš Bizjak from comment #8)
> > Fixed.
>
> I don't think so. The code I gave seems still to crash the compiler:
Yes, the cost function is ICEin
cb38/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20230513.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.year/configure
--prefix=/home/dcb38/gcc/results.20230513.asan.ubsan --disable-multilib
--disable-bootstrap --wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #25 from Jonathan Wakely ---
I think the simplest solution for this bug is just use and call trunc
instead of trying to use std::trunc. If you use the functions in the
global namespace then you get exactly the set that is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Xi Ruoyao changed:
What|Removed |Added
Known to fail||12.1.0, 12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Bug ID: 109842
Summary: GCC-12 hangs on simple piece of inline assembly code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Uroš Bizjak changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #9 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Uroš Bizjak changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #6 from Carlos Galvez ---
Hi again!
I realized there is still one more problem missing, so I suspect the linker was
not the only culprit. It does not segfault, but it gets stuck in an infinite
loop, once again when mixing exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878
Andrew Pinski changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #32 from Alexander Monakov ---
Ranger ICE is PR 109841 (reduced so it doesn't need LTO).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841
Bug ID: 109841
Summary: [12/13/14 Regression] ranger ICE in
operator_bitwise_not::fold_range
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Keywords: ice-on-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
--- Comment #3 from Andrew Pinski ---
Now the aarch64 backend could add hi and qi patterns for popcount.
For the TARGET_CSSC case, it would need to zero extend to SImode.
For the !TARGET_CSSC case, it would also zero extend but instead to DImod
61 matches
Mail list logo