https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
jimis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84759
--- Comment #2 from jimis ---
*** Bug 54183 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
--- Comment #4 from jimis ---
Indeed, as showcased by this example:
https://godbolt.org/g/nsSTHG
The function calls __udivmoddi4, like you said. However, the call is inlined in
main, but there we see separate calls for __udivdi3 and __umoddi3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
--- Comment #2 from jimis ---
No, I still see the same behaviour with gcc 7.3 on my Fedora box.
Is the this link from godbolt showcasing it for you?
https://godbolt.org/g/dKEf39
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
jimis jimis at gmx dot net changed:
What|Removed |Added
CC||jimis at gmx dot net
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jimis at gmx dot net
For the following code, which was a typo from my side (full example attached):
pre
struct addrinfo query2 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #2 from jimis jimis at gmx dot net ---
(In reply to Marek Polacek from comment #1)
I see nothing surprising here; an assignment expression has the value of the
left operand after the assignment. So we 1) set query2.ai_flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #4 from jimis jimis at gmx dot net ---
Thanks Andreas, that's the reference I was looking for!
I guess since this code triggers unspecified behaviour, a warning would be even
more needed. :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #5 from jimis jimis at gmx dot net ---
Andreas: On a second thought, this paragraph only talks about the order
*within* the initialisation list. But no matter of that order, the
initialisation list is always evaluated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
Bug #: 54183
Summary: Generate __udivmoddi4 instead of __udivdi3 plus
__umoddi3
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54138
Bug #: 54138
Summary: configuring --without-cloog but executable links
against system cloog
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
--- Comment #3 from jimis jimis at gmx dot net 2012-07-30 12:18:49 UTC ---
Created attachment 27894
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27894
XPatch.cpp preprocessed source from xalanc
Hi thanks for your patience, I resurrected my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
Bug #: 54114
Summary: variable-tracking performance regression from
4.8-20120610 to 4.8-20120701
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
--- Comment #1 from jimis jimis at gmx dot net 2012-07-28 20:49:55 UTC ---
Sorry guys my machine died an ugly death, so the web interface for my profiling
runs is unfortunately offline. :-( From memory I remember that this regression
is more than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #12 from jimis jimis at gmx dot net 2012-07-09 09:52:52 UTC ---
(In reply to comment #10)
bug-libt...@gnu.org
FWIW I had sent this but got no reply:
http://lists.gnu.org/archive/html/bug-libtool/2011-08/msg3.html
Maybe we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
jimis jimis at gmx dot net changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #26 from jimis jimis at gmx dot net 2012-07-09 10:06:53 UTC ---
Created attachment 27765
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27765
fprint_w reinstated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #29 from jimis jimis at gmx dot net 2012-07-09 19:57:22 UTC ---
Thanks guys, sent to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00345.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #23 from jimis jimis at gmx dot net 2012-07-08 10:02:14 UTC ---
Iain, ro: Do you know of some darwin or solaris i386 machine where I can test
some changes to this patch?
Does the bug mentioned in comment #15 and comment #16 needs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53891
Bug #: 53891
Summary: CFLAGS set in configure don't propagate
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
jimis jimis at gmx dot net changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #7 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
jimis jimis at gmx dot net changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #14 from jimis jimis at gmx dot net 2012-06-27 22:58:50 UTC ---
Ping? Can someone review my last patch? I think it's clean enough to be applied
(minus the TODO notes) and extra fixes can come separately later.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
jimis jimis at gmx dot net changed:
What|Removed |Added
Attachment #27520|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #7 from jimis jimis at gmx dot net 2012-05-30 06:01:23 UTC ---
Now time for the most intrusive and problematic patches. I tried moving all
virt_locs, expanded, expanded_virt_locs to obstacks for allocation. After many
failures to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #8 from jimis jimis at gmx dot net 2012-05-30 06:06:16 UTC ---
Created attachment 27522
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27522
Introduce obstack_{mark,release} functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #9 from jimis jimis at gmx dot net 2012-05-30 06:10:38 UTC ---
Created attachment 27523
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27523
Move all location/expansion vectors to obstacks. Warning MEMLEAKS!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #10 from jimis jimis at gmx dot net 2012-05-30 06:23:56 UTC ---
Here is how this last patch (macro4) compares to trunk (TME) and to completely
disabling track-macro-expansion (noTME):
time M instr
noTME 0.744s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #12 from jimis jimis at gmx dot net 2012-05-30 15:55:19 UTC ---
I should probably explain where the problem is and why I've left a memory leak.
In tokens_buff_new() I can't use XOBNEWVEC() instead of XNEWVEC() because it is
not guarded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
Bug #: 53525
Summary: Performance regression due to enabling
track-macro-expansion
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
jimis jimis at gmx dot net changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #2 from jimis jimis at gmx dot net 2012-05-30 04:44:54 UTC ---
According to valgrind major overhead is due to numerous calls of
line-map.c:linemap_line_start() that actually allocate new line_maps. This
happens because we are resetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #3 from jimis jimis at gmx dot net 2012-05-30 04:52:20 UTC ---
Another simple one that my eye caught but does not effect performance.
Generally I don't get many things in macro.c, but am I correct to assume that
the following stands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #4 from jimis jimis at gmx dot net 2012-05-30 05:23:54 UTC ---
Another hotspot higlighted by valgrind is the multitude of malloc/free() calls
in comparison to the past. I'm attaching a slightly more intrusive patch that
uses obstacks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #5 from jimis jimis at gmx dot net 2012-05-30 05:28:31 UTC ---
Created attachment 27520
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27520
In macro.c:collect_args() use obstacks for virt_locs instead of malloc/realloc
vectors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #6 from jimis jimis at gmx dot net 2012-05-30 05:31:03 UTC ---
Created attachment 27521
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27521
Add some new obstack macros in libiberty.h.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #28 from jimis jimis at gmx dot net 2012-05-20 10:41:28 UTC ---
The issue seems to be resolved with these 3 defines, thanks for helping. I now
get an ICE at a much later phase which is probably unrelated. I'll try some
more recent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #19 from jimis jimis at gmx dot net 2012-05-18 12:46:43 UTC ---
Defining _GTHREAD_USE_MUTEX_INIT_FUNC in os/gnu-linx/os_defines.h didn't help.
See attached files for new error message and preprocessed source.
Also keep in mind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #21 from jimis jimis at gmx dot net 2012-05-18 12:48:53 UTC ---
Created attachment 27432
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27432
preprocessed source after defining _GTHREAD_USE_MUTEX_INIT_FUNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #20 from jimis jimis at gmx dot net 2012-05-18 12:48:05 UTC ---
Created attachment 27431
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27431
guard.cc error after defining _GTHREAD_USE_MUTEX_INIT_FUNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #25 from jimis jimis at gmx dot net 2012-05-18 17:17:13 UTC ---
Created attachment 27436
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27436
log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #26 from jimis jimis at gmx dot net 2012-05-18 17:17:53 UTC ---
Created attachment 27437
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27437
preprocessed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #24 from jimis jimis at gmx dot net 2012-05-18 17:16:08 UTC ---
Thanks, I'll leave that to you then since it's no big priority for me.
FYI defining _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC brought other problems. I'm
attaching related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #16 from jimis jimis at gmx dot net 2012-05-10 00:41:04 UTC ---
(In reply to comment #14)
I'm pretty sure we've already dealt with this failure elsewhere, IIRC the
linuxthreads pthread_mutex_t type has a volatile member causing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #17 from jimis jimis at gmx dot net 2012-05-10 00:42:15 UTC ---
Created attachment 27361
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27361
mutex.diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
jimis jimis at gmx dot net changed:
What|Removed |Added
Attachment #27335|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #6 from jimis jimis at gmx dot net 2012-05-08 06:38:08 UTC ---
Created attachment 27339
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27339
preprocessed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #7 from jimis jimis at gmx dot net 2012-05-08 06:38:45 UTC ---
Parallel compilation confused me, the error is for guard.cc, see the attached
log plus the preprocessed source.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #13 from jimis jimis at gmx dot net 2012-05-09 04:43:20 UTC ---
--disable-libstdcxx-threads doesn't help, I get the same error at exactly the
same point(guard.cc:33).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
Bug #: 53270
Summary: Error when bootstrapping gcc on
hppa2.0-unknown-linux-gcc
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #1 from jimis jimis at gmx dot net 2012-05-07 20:31:19 UTC ---
Created attachment 27335
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27335
hppa-gcc-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #3 from jimis jimis at gmx dot net 2012-05-07 23:22:50 UTC ---
I used the gcc-4.8-20120429 snapshot and the only configure option (besides
prefix and libraries) was --disable-libstdcxx-pch. The host I compiled on was
gcc61. I didn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51116
jimis jimis at gmx dot net changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #8 from jimis jimis at gmx dot net 2011-11-11 23:00:47 UTC ---
Created attachment 25800
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25800
Use libiberty's stpcpy()
Does the attached patch solve the stpcpy() issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #9 from jimis jimis at gmx dot net 2011-11-11 23:31:22 UTC ---
Created attachment 25801
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25801
fix for platforms not using GNU as
I redefined STRING_ASM_OP and changed ELF_STRING_LIMIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #10 from jimis jimis at gmx dot net 2011-11-11 23:34:55 UTC ---
Nevertheless, I'd prefer using ELF_STRING_LIMIT and ELF_STRING_ASM_OP names to
point out that they affect only elf_* functions. But this renaming would touch
various rare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #11 from jimis jimis at gmx dot net 2011-11-11 23:38:54 UTC ---
Created attachment 25802
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25802
STRING_LIMIT and STRING_ASM_OP usage in gcc
See attached file for platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
--- Comment #2 from jimis jimis at gmx dot net 2011-08-13 01:37:14 UTC ---
Created attachment 24996
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24996
Make cse.c:preferable() more readable, slightly faster, without affecting its
logic.
2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
jimis jimis at gmx dot net changed:
What|Removed |Added
CC||jimis at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49995
Summary: operand missing mode warning on sparc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
Summary: make prefix=... install doesn't work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #2 from jimis jimis at gmx dot net 2011-08-03 19:01:51 UTC ---
I use it casually for packages that use autotools to configure the build, it
always works fine. And for gcc it has worked for me plenty of times for i386
C-frontend only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #5 from jimis jimis at gmx dot net 2011-08-03 19:32:09 UTC ---
DESTDIR is supported just fine, but it is not prefix, it serves different
purposes. In particular it installs in /$DESTDIR/$prefix but installed package
would search
63 matches
Mail list logo
