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
jimis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=60809
--- Comment #5 from jimis ---
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 to:
{
.ai_fam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #4 from jimis ---
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 #2 from jimis ---
(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 to
> AI_PASSIVE, 2) use thi
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):
struct addrinfo query2 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
jimis changed:
What|Removed |Added
CC||jimis at gmx dot net
--- Comment #5 from jimis
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: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
--- Comment #3 from jimis 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 PC so now I have acc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
--- Comment #1 from jimis 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 0.5s overhead out of
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: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #29 from jimis 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 #26 from jimis 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
jimis changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment #25 from jimi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #12 from jimis 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 should open this or the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #23 from jimis 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 special configure
flags?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
jimis changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #8 from jimis 2012-07-08
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
jimis changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #7 from jimis 2012-07-08 03
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: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #14 from jimis 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 changed:
What|Removed |Added
Attachment #27520|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #12 from jimis 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 from the obstack_mar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #10 from jimis 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 2081
TME0.785s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #9 from jimis 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 #8 from jimis 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 #7 from jimis 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 with obstacks as they
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #6 from jimis 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=53525
--- Comment #5 from jimis 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 #4 from jimis 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 to allocate some of th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #3 from jimis 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?
=== modified file 'l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
--- Comment #2 from jimis 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 the max_column_hint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525
jimis changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
|
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=53270
--- Comment #28 from jimis 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 snapshot later and file a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #24 from jimis 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 info for the sake of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #26 from jimis 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 #25 from jimis 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 #20 from jimis 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 #21 from jimis 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 #19 from jimis 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 that gcc61 shows some stran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #17 from jimis 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
--- Comment #16 from jimis 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 the default
> assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #13 from jimis 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
--- Comment #7 from jimis 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 #6 from jimis 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
jimis changed:
What|Removed |Added
Attachment #27335|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #3 from jimis 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 know about the --enable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
--- Comment #1 from jimis 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
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=51116
jimis changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from jimi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #11 from jimis 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 that will need macro renaming.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #10 from jimis 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 archs. Should I try i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #9 from jimis 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 back to STRING_LIMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094
--- Comment #8 from jimis 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=19832
jimis changed:
What|Removed |Added
CC||jimis at gmx dot net
--- Comment #3 from jimis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
--- Comment #2 from jimis 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-08-13 Dimitrios Ap
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: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #5 from jimis 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 libraries in /$prefix.
jo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #2 from jimis 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 builds, and till not I'
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: unas
63 matches
Mail list logo
