https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90586
Bug ID: 90586
Summary: [gdb] gdb wrongly set the breakpoint as expected
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90585
--- Comment #1 from Matthias Klose ---
looks like libgomp/configure.ac always sets -Werror, not respecting the
--disable-werror configure option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144
--- Comment #6 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #3)
> Maybe -Wdeprecated or -Wdeprecated-declarations
I think clang puts this under -Wgnu-designator:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90547
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 23 04:55:40 2019
New Revision: 271537
URL: https://gcc.gnu.org/viewcvs?rev=271537=gcc=rev
Log:
Backported from mainline
2019-05-21 Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90547
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90585
Bug ID: 90585
Summary: libgomp hsa plugin ftbfs in the x32 multilib variant
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78388
Eric Gallager changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #9 from Qi Feng ---
And there's another problem. Take `x > y && x != 0 --> x > y' for
example, I would also like to do
x < y && y != 0 --> x < y
x != 0 && x > y --> x > y
y != 0 && x < y --> x < y
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
--- Comment #3 from Rafael Avila de Espindola ---
I see now that the corresponding commit on trunk was
31011b9a94fed33170c009292e82558336d1c4d7 (r261146).
At that revision, the test in this bug passes. There was a more recent
regression on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90584
Bug ID: 90584
Summary: [gdb] gdb is not stopped at a breakpoint in an
executed line of code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90462
--- Comment #4 from David Malcolm ---
r271535 should fix the ICE on trunk, but it doesn't fix the missing "finish"
location for the warning described in comment #2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90583
Bug ID: 90583
Summary: Implement DR 1722, lambda to function pointer
conversion should be noexcept
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90462
--- Comment #3 from David Malcolm ---
Author: dmalcolm
Date: Thu May 23 00:42:03 2019
New Revision: 271535
URL: https://gcc.gnu.org/viewcvs?rev=271535=gcc=rev
Log:
Bulletproof -fdiagnostics-format=json against bad locations (PR c++/90462)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #14 from Steve Kargl ---
On Wed, May 22, 2019 at 11:21:52PM +, j.ravens.nz at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
>
> --- Comment #13 from Jonathan Ravens ---
> Thanks everyone for your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231
--- Comment #8 from Martin Sebor ---
(In reply to Martin Liška from comment #7)
> Can we do such an optimization without GAS information about size of every
> function?
My thought was that we could use alignment alone if we didn't know the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #13 from Jonathan Ravens ---
Thanks everyone for your input on this issue. I hadn't realised that it could
cause such dissent.
As a software developer, my major driver is to manage the users' expectations.
In that respect,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83237
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90582
--- Comment #1 from Andrew Pinski ---
> I assume EOR / CBNZ is as at least as efficient as SUBS / BNE on
> all/most AArch64 microarchitectures, but someone should check.
It is similar as x86 with that respect on some cores (Marvell's cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90547
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 22 22:50:39 2019
New Revision: 271529
URL: https://gcc.gnu.org/viewcvs?rev=271529=gcc=rev
Log:
Backported from mainline
2019-05-21 Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
--- Comment #6 from Jonathan Wakely ---
This bug also affects 32-bit GNU/Linux with older versions of glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90582
Bug ID: 90582
Summary: AArch64 stack-protector wastes an instruction on
address-generation
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Wed May 22 22:36:21 2019
New Revision: 271528
URL: https://gcc.gnu.org/viewcvs?rev=271528=gcc=rev
Log:
PR libstdc++/90557 fix path assignment that alters source
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed May 22 22:14:34 2019
New Revision: 271527
URL: https://gcc.gnu.org/viewcvs?rev=271527=gcc=rev
Log:
PR libstdc++/90557 fix path assignment that alters source
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #16 from dave.anglin at bell dot net ---
On 2019-05-22 5:23 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #15 from The Written Word com> ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Comment #22 from Jason Merrill ---
Author: jason
Date: Wed May 22 21:39:08 2019
New Revision: 271523
URL: https://gcc.gnu.org/viewcvs?rev=271523=gcc=rev
Log:
PR c++/20408 - unnecessary code for empty struct.
Here initializing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90549
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71924
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
Bug ID: 90581
Summary: provide an option to adjust the maximum depth of
nested #include
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #15 from The Written Word
---
(In reply to dave.anglin from comment #12)
> It might help to compile stage1 with -O2 or -Os.
How does one do this? After ./configure, "gmake CFLAGS=-Os"? BOOT_CFLAGS
applies to stage2/3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557
Jonathan Wakely changed:
What|Removed |Added
Known to work||8.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90580
Bug ID: 90580
Summary: error: ‘offsetof’ undeclared when it is declared, but
used with the wrong number of arguments
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #39 from Jonathan Wakely ---
(In reply to dave.anglin from comment #37)
> I believe I changed the glibc value because of the pthread mutex issue.
Aha.
> MALLOC_ABI_ALIGNMENT is defined in pa32-linux.h as follows:
> #define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #38 from Jonathan Wakely ---
Author: redi
Date: Wed May 22 20:29:39 2019
New Revision: 271522
URL: https://gcc.gnu.org/viewcvs?rev=271522=gcc=rev
Log:
PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs
Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #37 from dave.anglin at bell dot net ---
On 2019-05-22 3:41 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
>
> --- Comment #36 from Jonathan Wakely ---
> Interesting. Yes, definitely similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #14 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Matt Thompson from comment #12)
> > (In reply to Iain Sandoe from comment #11)
> > > (In reply to Matt Thompson from comment #10)
> > > > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #22 from Thomas Koenig ---
I've been trying out some things, and I cannot construct a failing
test case.
A sane way to build such an interface would be
cat tst.f90
module x
use, intrinsic :: iso_c_binding, only : c_double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Wed May 22 19:48:05 2019
New Revision: 271521
URL: https://gcc.gnu.org/viewcvs?rev=271521=gcc=rev
Log:
PR c++/86485 - simple_empty_class_p
Yet another tweak that would have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568
--- Comment #5 from Peter Cordes ---
And BTW, this only helps if the SUB and JNE are consecutive, which GCC
(correctly) doesn't currently optimize for with XOR.
If this sub/jne is different from a normal sub/branch and won't already get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #36 from Jonathan Wakely ---
Interesting. Yes, definitely similar ideas. It looks like it was solved
differently though, as config/pa/pa.h has
#define MALLOC_ABI_ALIGNMENT (TARGET_64BIT ? 128 : 64)
which should get used by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90565
--- Comment #2 from seurer at gcc dot gnu.org ---
Also possibly gcc.dg/pr67512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
Bug ID: 90579
Summary: Huge store forward stall due to vectorizer
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88483
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed May 22 18:53:37 2019
New Revision: 271517
URL: https://gcc.gnu.org/viewcvs?rev=271517=gcc=rev
Log:
x86: Don't allocate stack frame nor align stack if not needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90547
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 22 18:49:22 2019
New Revision: 271516
URL: https://gcc.gnu.org/viewcvs?rev=271516=gcc=rev
Log:
Backported from mainline
2019-05-21 Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-apple-darwin*,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
--- Comment #2 from Rafael Avila de Espindola ---
The bug is still present on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
Rafael Avila de Espindola changed:
What|Removed |Added
CC||jason at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578
Dominique d'Humieres changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578
Bug ID: 90578
Summary: Wrong code with LSHIFT and optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568
--- Comment #3 from Peter Cordes ---
(In reply to Jakub Jelinek from comment #2)
> The xor there is intentional, for security reasons we do not want the stack
> canary to stay in the register afterwards, because then it could be later
> spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
Bug ID: 90577
Summary: [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with
-O(2|3) and -flto
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
--- Comment #16 from Iain Sandoe ---
Created attachment 46398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46398=edit
testsuite patch
Will post this later, tested on x86_64-linux and x86_64-darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Rainer, the change to gcc/cp/init.c would allow you to do:
>
> #define MALLOC_ABI_ALIGNMENT 8
Oops, it's in bits not bytes, so that should be
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485
Giulio Benetti changed:
What|Removed |Added
CC||giulio.benetti@micronovasrl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #35 from dave.anglin at bell dot net ---
On 2019-05-22 11:03 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
>
> --- Comment #34 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90576
Bug ID: 90576
Summary: [10 regression] SPEC CPU2006 450.soplex miscompiled
with -Os -flto after r271413
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #34 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #33)
> The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__
> on targets where malloc doesn't agree with GCC's alignof(max_align_t).
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
--- Comment #4 from Jonathan Wakely ---
Rainer, the change to gcc/cp/init.c would allow you to do:
#define MALLOC_ABI_ALIGNMENT 8
in gcc/config/i386/sol2.h and that would cause std::allocator to know that it
can't rely on malloc for 16-byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90575
Bug ID: 90575
Summary: -gsplit-dwarf leaves behind .dwo file in cwd
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #21 from Thomas Koenig ---
OK, if the callee is a C function... what is its declaration
on the Fortran side? Is there any interface, bind(c) or otherwise?
I suppose there must be something, otherwise nf_put_vara_double would
have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90574
Bug ID: 90574
Summary: [gdb] gdb wrongly stopped at a breakpoint in an
unexecuted line of code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90573
--- Comment #1 from Thomas Schwinge ---
Probably some of these transformation should come with compiler diagnostics,
especially for explicit clauses.
For example, need to relate this to 'OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT': PR70550
(r234779,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476
Giulio Benetti changed:
What|Removed |Added
CC||giulio.benetti@micronovasrl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90573
Bug ID: 90573
Summary: Avoid unnecessary data transfer into OMP construct
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570
Martin Liška changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570
--- Comment #4 from Martin Liška ---
(In reply to Jakub Jelinek from comment #3)
> Given the TREE_STATIC on:
> static const int C.0[2] = {1, 2};
> I don't understand why there is ASAN_UNPOISON/ASAN_POISON for C.0, shouldn't
> that be applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570
--- Comment #3 from Jakub Jelinek ---
Given the TREE_STATIC on:
static const int C.0[2] = {1, 2};
I don't understand why there is ASAN_UNPOISON/ASAN_POISON for C.0, shouldn't
that be applied solely to automatic variables, not block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571
--- Comment #3 from Richard Biener ---
Turning indirect calls into direct ones might be important enough to also
handle
int x, y;
int f() { return x; }
int g() { return y; }
int t0(bool b) { int (*i)() = b ? : x = 1; return i(); }
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71124
--- Comment #4 from Giulio Benetti ---
Previous Comment was wrong.
This duplicates bug:
*** This bug has been marked as a duplicate of bug 85180 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71124
Giulio Benetti changed:
What|Removed |Added
CC||giulio.benetti@micronovasrl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #38 from Marc Glisse ---
(In reply to Marc Glisse from comment #37)
> If you protect even constants, the current effects of -frounding-math become
> redundant.
Oops, forget that, the hack is too late for this sentence to be true,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #37 from Marc Glisse ---
(In reply to Richard Biener from comment #36)
> Created attachment 46396 [details]
> poor mans solution^Whack
>
> So this is what a hack looks like, basically sprinkling those asm()s
> throughout the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #20 from Martin Liška ---
(In reply to Thomas Koenig from comment #19)
> Thanks.
>
> A bit more:
>
> What are the declarations of the actual srgument,
> of the dummy argument (on the callee side),
> and what is the argument in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572
Bug ID: 90572
Summary: Wrong disambiguation in friend declaration as implicit
typename context
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #19 from Thomas Koenig ---
Thanks.
A bit more:
What are the declarations of the actual srgument,
of the dummy argument (on the callee side),
and what is the argument in the call list?
Ill try to construct a test case tonight
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #22 from Richard Biener ---
The code in question was originally added with r202721 by Vlad and likely
became more costly after making the target macro a hook (no inlining
anymore).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571
Bug ID: 90571
Summary: Missed optimization opportunity when returning
function pointers based on run-time boolean
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
--- Comment #18 from Thomas De Schampheleire ---
Second version of patch, fixing testsuite failures, was posted:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01403.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231
--- Comment #6 from Martin Liška ---
(In reply to Andi Kleen from comment #4)
> I'm not sure it's a good idea to do this. Often the goal is not to get the
> absolute smallest code, but to get code that minimizes cache line usage.
> This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570
Bug ID: 90570
Summary: AddressSanitizer: stack-use-after-scope
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543
--- Comment #8 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #6)
> Neither uintptr_t nor PRIxPTR (nor long long nor uint64_t) is part of C++98,
> which GCC still requires. I do see existing uses of intptr_t and uintptr_t
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100
--- Comment #12 from Janne Blomqvist ---
Author: jb
Date: Wed May 22 11:56:01 2019
New Revision: 271511
URL: https://gcc.gnu.org/viewcvs?rev=271511=gcc=rev
Log:
fortran/89100: Default widths with -fdec-format-defaults
gcc/fortran ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543
--- Comment #6 from Jonathan Wakely ---
Neither uintptr_t nor PRIxPTR (nor long long nor uint64_t) is part of C++98,
which GCC still requires. I do see existing uses of intptr_t and uintptr_t in
gcc/cp/*.c though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #21 from Richard Biener ---
Ick.
static inline void
check_pseudos_live_through_calls (int regno,
HARD_REG_SET last_call_used_reg_set,
rtx_insn *call_insn)
{
...
1 - 100 of 151 matches
Mail list logo
