https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93070
John Simon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071
--- Comment #1 from John Simon ---
*** Bug 93070 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071
Bug ID: 93071
Summary: std::__lg (and all functions that use it) generates
suboptimal code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93070
Bug ID: 93070
Summary: std::__lg (and all functions that use it) generates
suboptimal code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
Bug ID: 93069
Summary: Assembler messages: Error: unsupported masking for
`vextracti32x8'
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93045
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063
--- Comment #1 from Marc Glisse ---
Created attachment 47549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47549=edit
Untested patch
Not ready, at the very least it misses a comment and a test, but it shows where
the test needs relaxing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #10 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #9)
> (In reply to Marc Glisse from comment #8)
> > (In reply to fdlbxtqi from comment #6)
> > > void copy_char_vector_with_iter(std::vector::iterator
> > > out,std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #9 from fdlbxtqi ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396
--- Comment #10 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #4)
> Either we can do something in the bswap pass with it as done in this
> untested patch, or we could consider match.pd optimization for:
> _3 = BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93068
Bug ID: 93068
Summary: Professional Dissertation Writing Services
Product: gcc
Version: new-ra
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067
--- Comment #1 from Lewis Hyatt ---
Created attachment 47548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47548=edit
testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067
Bug ID: 93067
Summary: diagnostics are not aware of -finput-charset
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55791
--- Comment #4 from Eric Gallager ---
For reference, clang catches this with its static analyzer:
$ clang --analyze 55791.c
55791.c:10:15: warning: Result of 'malloc' is converted to a pointer of type
'char', which is incompatible with sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #5 from Alexander Cherepanov ---
1. It should be noted that the idea of problems arising from `p == q ? p : q`
is from Chung-Kil Hur via bug 65752, comment 15.
2. clang bug -- https://bugs.llvm.org/show_bug.cgi?id=44374.
mp; ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191224 (experimental)
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #4 from Alexander Monakov ---
The attachment is edited to test insertion_sort, and doesn't call
accumulate_vector at all - looks like you attached a wrong file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #3 from Jan Hubicka ---
Created attachment 47546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47546=edit
preprocessed benchmark
I am attaching preprocessed source. I used -O3 -march=native
-fno-prefetch-loops-arrays (since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #2 from Alexander Monakov ---
Can you attach preprocessed source and double-check command-line flags? I can't
reproduce the problem with lea, and the code does not have explicit prefetch
instructions that I get with -O3 -march=bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066
Bug ID: 93066
Summary: libgomp/target.c:525:46: error: expected expression
before ')' token
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
--- Comment #4 from WHR ---
OK, I'm now fully understood what's happens.
If the loop breaks, 'p' must be 0, so the later '**p' will dereference a null
pointer.
Looks like this is actually a feature...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93065
Bug ID: 93065
Summary: libgomp: destructor missing to delete
goacc_cleanup_key
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061
Mutex changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
--- Comment #5 from Andrew Pinski ---
(In reply to Roman Zhuykov from comment #4)
> PS. Cfarm gcc117 and 118 are not available at the moment, and 113-116 have
> same hardware and old binutils 2.24.
Just compile your own new binutils first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
--- Comment #4 from Roman Zhuykov ---
Maybe this should be catched earlier in configure scripts?
Are there any simple workaround without patching the gcc source? I'm not
familiar with different armvN -march option values. Probably it can help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360
--- Comment #5 from Andrew Pinski ---
(In reply to Eric Botcazou from comment #4)
>
> it returns QImode. If it returned SImode as on SPARC, the code would be:
SLOW_BYTE_ACCESS set to 0 is the cause there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064
--- Comment #1 from Jan Engelhardt ---
Possibly a duplicate of #92496 (the automatic "Possible duplicates" in the New
Bug form was slow to load), but my preconditions are different: I don't have a
public data member, nor is a template used like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064
Bug ID: 93064
Summary: ICE on C++20 operator<=> use
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #8 from Marc Glisse ---
(In reply to fdlbxtqi from comment #6)
> void copy_char_vector_with_iter(std::vector::iterator
> out,std::vector const& bits)
> {
> std::copy_n(bits.begin(),bits.size(),out);
> }
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063
Bug ID: 93063
Summary: Loop distribution and NOP conversions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #7 from Marc Glisse ---
(In reply to fdlbxtqi from comment #6)
> > > clearly incorrect
> >
> > Please distinguish between what is wrong (generated code crashes, or returns
> > 3 instead of 2), and what is suboptimal.
>
> Suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #6 from fdlbxtqi ---
> What operation are you doing on vector? None of your testcases seem to use
> it.
void copy_char_vector_with_iter(std::vector::iterator
out,std::vector const& bits)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #5 from Marc Glisse ---
We could indeed relax a bit the "same type" condition. We could also make sure
that __restrict appears somewhere in the call chain when using copy or
uninitialized_*, which lets the compiler merge the 2
39 matches
Mail list logo
