https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
--- Comment #1 from Jonathan Wakely ---
The path type was rewritten for GCC 9, and now prints:
allocating 21 bytes
allocating 248 bytes
about to quit.
total allocated 269 bytes
freed 248 bytes
freed 21 bytes
The 21 bytes is for the native() str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90624
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628
--- Comment #2 from Jeremy ---
(In reply to Marc Glisse from comment #1)
> Thanks for the report.
> (next time, please include a complete, compilable example, with the
> #includes, int main, etc)
Sorry, here is a complete program:-
#include
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90605
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013
--- Comment #9 from krux ---
(In reply to ktkachov from comment #7)
> I tried current trunk (future GCC 9)
> GCC 9 learned to avoid excessive widening during vectorisation, which is
> what accounts for the large number of instructions you see.
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #20 from krux ---
Thanks your patch worked!
Just fyi: llvm-dwarfdump doesn't understand call-site info:
https://bugs.llvm.org/show_bug.cgi?id=41846
Not sure if it's relevant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
baltic <1000hz.radiowave at gmail dot com> changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #21 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636
Bug ID: 90636
Summary: [libbacktrace] Tests
edtest/edtest_alloc/ttest/ttest_alloc are failing on
x64 Linux
Product: gcc
Version: 9.1.1
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637
Bug ID: 90637
Summary: [10 Regression] ICE in vect_loop_versioning, at
tree-vect-loop-manip.c:3055
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #26 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 26 14:02:51 2019
New Revision: 271630
URL: https://gcc.gnu.org/viewcvs?rev=271630&root=gcc&view=rev
Log:
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
--- Comment #4 from baltic <1000hz.radiowave at gmail dot com> ---
besides the 269 bytes you have mentioned, is still x10 overhead for a 20 chars
string. and massively adds up, if you store a lot objects.
for example, when i go around home folder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
Jeff Snyder changed:
What|Removed |Added
CC||jeff-gcc at caffeinated dot
me.uk
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #22 from krux ---
I can also reproduce it without any linker script, simplified code:
int serial3_available() {}
struct HardwareSerial3 {
int available() { serial3_available(); }
};
HardwareSerial3 Serial3;
void yield()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #23 from krux ---
But it's so fragile, touch any part of the code and the error disappears.
Like change serial3_available to void and you also get an additional symbol:
4160 0003 T mainmain.cpp:8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #24 from krux ---
objdump -dCrS also prints these errors.
It definitely fails to find the entry for main which is present according to
objdump --dwarf:
<1>: Abbrev Number: 8 (DW_TAG_subprogram)
DW_AT_external: 1
DW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
--- Comment #5 from Jonathan Wakely ---
(In reply to baltic from comment #3)
> (In reply to Jonathan Wakely from comment #2)
>
> > I'm not sure where the repeated 72 allocations come from, and can't check
> > the code right now, but the new cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|9.0 |8.4
--- Comment #6 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #18 from Curtis Hamilton ---
Created attachment 46412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46412&action=edit
Patch to fix undefined types in sysinfo.go and runtime_sysinfo.go
This patch resolves many of the undefines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
Bug ID: 90638
Summary: Wrong results of pow(complex , T1) function when
the T1 type differs from T and from int
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
--- Comment #2 from Igor Smirnov ---
Strange... It came with freshiest available CentOS 7.6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639
Bug ID: 90639
Summary: Boostrap failure with recent trunk on POWER9
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|Boostrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639
Segher Boessenkool changed:
What|Removed |Added
Target||powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90381
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90407
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636
--- Comment #1 from Ian Lance Taylor ---
Try changing to the libbacktrace build directory, removing edtest.o, and
running "make edtest". Presumably then running "./edtest" will fail with the
"missing file name or function name" error. Paste the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #19 from Ian Lance Taylor ---
People build the gofrontend all the time on GNU/Linux systems. I don't know if
anyone has successful built it on a FreeBSD system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90399
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614
--- Comment #4 from ian at gcc dot gnu.org ---
Author: ian
Date: Mon May 27 00:10:22 2019
New Revision: 271637
URL: https://gcc.gnu.org/viewcvs?rev=271637&root=gcc&view=rev
Log:
PR go/90614
syscall: avoid unused parameter error if WI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614
--- Comment #5 from ian at gcc dot gnu.org ---
Author: ian
Date: Mon May 27 00:10:34 2019
New Revision: 271638
URL: https://gcc.gnu.org/viewcvs?rev=271638&root=gcc&view=rev
Log:
PR go/90614
syscall: avoid unused parameter error if WI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Mon May 27 00:14:02 2019
New Revision: 271640
URL: https://gcc.gnu.org/viewcvs?rev=271640&root=gcc&view=rev
Log:
PR go/90635
libgo: correct typo in USE_LIBFFI AM_CONDIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Mon May 27 00:13:52 2019
New Revision: 271639
URL: https://gcc.gnu.org/viewcvs?rev=271639&root=gcc&view=rev
Log:
PR go/90635
libgo: correct typo in USE_LIBFFI AM_CONDIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #20 from Curtis Hamilton ---
(In reply to Ian Lance Taylor from comment #19)
> People build the gofrontend all the time on GNU/Linux systems. I don't know
> if anyone has successful built it on a FreeBSD system.
My bad! I was referr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #18 from Qi Feng ---
I only learned gcc for about 2 months, and I have to say that I don't fully
understand what you guys were saying. Is match.pd the right place to fix this
issue? Am I in the wrong direction?
39 matches
Mail list logo
