https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96127
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96849
Bug ID: 96849
Summary: [11 Regression] ICE: in extract_insn, at recog.c:2294
(error: unrecognizable insn)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96848
Bug ID: 96848
Summary: Inherited conditionally explicit constructors via
using declaration do not enforce explicitness if
dependent on template parameter
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96847
Bug ID: 96847
Summary: Code size increase +42% depending on memory size
allocated on stack for ARM Cortex-M3
Product: gcc
Version: unknown
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
--- Comment #4 from andysem at mail dot ru ---
(In reply to Jakub Jelinek from comment #3)
> mov edx, DWORD PTR [rdi]
> cmp edx, esi
> seteal
> cmp edx, r9d
> setedl
> or eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256
--- Comment #18 from Sergei Trofimovich ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
--- Comment #2 from andysem at mail dot ru ---
(In reply to Jakub Jelinek from comment #1)
In the godbolt link there is also a third case, which is similar to the second
one, but does not reuse the source register for comparison results.
unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88292
--- Comment #2 from Toby Brull ---
Probably (at least partly) a duplicate of PR 81880. Seems to be working now on
more recent versions (7.5, 8.4, 10.1), even though PR 81880 still persists.
Close?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
Toby Brull changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96845
--- Comment #2 from Andrew Pinski ---
(In reply to Bernhard Rosenkraenzer from comment #0)
> Some Linux distributions have a workaround for this in their gcc packaging -
> they replace libgcc_s.so with an ld script that pulls in libgcc if needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96845
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Toby Brull changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #4 from jvdelisle at charter dot net ---
An Update. I have the front end and runtime parsing for OUTPUT done and am now
looking at the actual implementation. We have the printf series of functions
available and can use the %A format s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96846
Bug ID: 96846
Summary: [x86] Prefer xor/test/setcc over test/setcc/movzx
sequence
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69775
Toby Brull changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96845
Bug ID: 96845
Summary: undefined reference to `__aarch64_ldadd4_acq_rel'
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135
Toby Brull changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96843
--- Comment #2 from Dominique d'Humieres ---
The code compiles with r11-2639 (2020-08-10), but gives the error with r11-2402
(2020-07-29). May be r11-2489 for pr96320.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96844
--- Comment #1 from Moritz Fischer ---
Created attachment 49155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49155&action=edit
python script to count number of different threads used for each worksharing
construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96844
Bug ID: 96844
Summary: OpenMP: two worksharing constructs with different
num_threads clauses break thread pooling
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
--- Comment #9 from H.J. Lu ---
(In reply to Florian Weimer from comment #8)
> (In reply to H.J. Lu from comment #7)
> > Give that the tcb field is setup by the C run-time on Linux/x86, should
> > it be provided by a run-time header file?
>
> Ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96843
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96843
Bug ID: 96843
Summary: gfortran rejects as shape mismatch rank one logical
array arguments
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96839
--- Comment #2 from William Clodius ---
I think so.
> On Aug 29, 2020, at 8:17 AM, dominiq at lps dot ens.fr
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96839
>
> Dominique d'Humieres changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
Language Lawyer changed:
What|Removed |Added
CC||language.lawyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96839
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842
Bug ID: 96842
Summary: enhancement: copy clang Wheader-guard
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92210
--- Comment #5 from David Binderman ---
Not only does clang detect that the control variable isn't changed,
it also detects when the control variable is changed too much.
Code like this gets warned:
for (int i = 0; i < 10; ++i)
{
// whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
--- Comment #8 from Florian Weimer ---
(In reply to H.J. Lu from comment #7)
> Give that the tcb field is setup by the C run-time on Linux/x86, should
> it be provided by a run-time header file?
Yes, it seems reasonable to me. Ideally, it would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92210
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
--- Comment #7 from H.J. Lu ---
(In reply to Florian Weimer from comment #6)
> (In reply to H.J. Lu from comment #4)
> > On Linux/i386 and Linux/x86-64, thread pointer access is done via syscall.
> > On Linux/x86-64, __builtin_thread_pointer and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96495
--- Comment #4 from Paul Thomas ---
The fix is submitted at:
https://gcc.gnu.org/pipermail/fortran/2020-August/054945.html
Regards
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to David Malcolm from comment #6)
> > > Thanks! The "memset" call has become a call to "__builtin___memset_ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> (In reply to David Malcolm from comment #6)
> > Thanks! The "memset" call has become a call to "__builtin___memset_chk"
> > (perhaps due to _FORTIFY_SOURCE, or somet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798
--- Comment #7 from Iain Sandoe ---
(In reply to David Malcolm from comment #6)
> Thanks! The "memset" call has become a call to "__builtin___memset_chk"
> (perhaps due to _FORTIFY_SOURCE, or something similar in Darwin's libc?),
(transitive in
38 matches
Mail list logo
