[Bug target/84759] Calculation of quotient and remainder with constant denominator uses __umoddi3+__udivdi3 instead of __udivmoddi4
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. ***
[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183 jimis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from jimis --- Thanks, closing ticket then! *** This bug has been marked as a duplicate of bug 84759 ***
[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3
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. Is it because in main the divisor is the same constant? If so I can close this bug and monitor bug 84759. Thanks!
[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __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
[Bug c/60809] C99 struct initialiser with embedded self assignment
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_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
AI_PASSIVE
};
The outer assignment to query2, should never set ai_flags, no matter what the
side-effects of the inner assignments are. Am I thinking right?
[Bug c/60809] C99 struct initialiser with embedded self assignment
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. :-)
[Bug c/60809] C99 struct initialiser with embedded self assignment
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 this value to initialize .ai_protocol.
if the outer assignment runs last, shouldn't it overwrite the inner assignment?
Then it should be equivalent to that:
struct addrinfo query3 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
1
Which means that ai_flags should be 0.
[Bug c/60809] New: C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
Bug ID: 60809
Summary: C99 struct initialiser with embedded self assignment
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
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,
query2.ai_flags = AI_PASSIVE
};
1. A warning would be nice, something like "suggest parentheses around
assignment"
2. What is the C99 mandated behaviour? I'm not sure GCC is behaving properly.
Currently it sets ai_protocol to 1 because it is the next field after
ai_socktype. But it also sets ai_flags to 1, which I'd expect to be 0 after the
outer struct initialiser is executed.
See discussion, full example program and output, at
http://gcc.gnu.org/ml/gcc-help/2014-04/msg00033.html
[Bug c/50584] No warning for passing small array to C99 static array declarator
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 --- I'm currently using this C99 feature. A warning would be nice if NULL or small arrays are passed.
[Bug rtl-optimization/54183] New: Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3
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
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ji...@gmx.net
CC: a...@gcc.gnu.org
As the subject says, see the following snippet as annotated from Callgrind. GCC
compiled with -O2 -march=i586, HOST_WIDE_INT is 8 bytes.
. static unsigned int
. _sprint_uw_rev (char *s, unsigned HOST_WIDE_INT value)
. {
21,838unsigned int i = 0;
177,348do
. {
709,392s[i] = "0123456789"[value % 10];
2,748,894 => libgcc2.c:__umoddi3 (88674x)
709,392value /= 10;
2,216,850 => libgcc2.c:__udivdi3 (88674x)
244,184i++;
. }
.while (value != 0);
.return i;
. }
[Bug other/54138] New: configuring --without-cloog but executable links against system cloog
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: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ji...@gmx.net CC: a...@gcc.gnu.org Steps to reproduce: Download snapshot gcc-4.8-20120729 configure --without-ppl --without-isl --without-cloog --enable-languages=c,c++ --disable-plugins --disable-bootstrap make ldd gcc/cc1 | grep cloo libcloog-isl.so.3 => /lib/libcloog-isl.so.3 (0xb7715000)
[Bug middle-end/54114] [4.8 Regression] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
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 access to my files, and the webinterface is up for anyone caring to see the function breakdown (just check footnote [6] in front page). Attached is the preprocessed source, I compile with $CC1PLUS -quiet -D_GNU_SOURCE -D LINUX -D _REENTRANT -D XALAN_INMEM_MSG_LOADER XPath.ii -g -O2 -fno-elide-constructors -fPIC -o /dev/null
[Bug middle-end/54114] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
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 ~5s. For more details I'll have to repair my equipment.
[Bug middle-end/54114] New: variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
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: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ji...@gmx.net Compiling the XPath.cpp from xalanc shows significant performance regression because of variable tracking, between GCC 4.8-20120610 to 4.8-20120701. Tracking it down is hard since var-tracking.c changed a lot in the past month, CC'ing lxo for better ideas. :-) It seems to apply mostly to C++ code, see the graph and the last annotation at http://teras-ics.mooo.com:8003/
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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 jimis 2012-07-09 10:03:37 UTC --- I attach a patch almost similar to yours that I think handles the max negative issue (but presumes 2's complement representation, and that HOST_WIDE_INT is always larger or equal type than long). Passed testing on i386, bootstrapped fine on x86_64 multilib, I'd appreciate testing on 32-bit multilib platform.
[Bug libfortran/49970] "make prefix=... install" doesn't work
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 other GCC PR so we can keep track of this unwanted behaviour?
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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? Maybe I can reproduce it on x86 somehow? (how to build 64-bit multilib on 32 bit host?)
[Bug libfortran/49970] "make prefix=... install" doesn't work
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 03:30:45 UTC --- It seems I can't reopen it, but this bug certainly isn't INVALID. It could be a bug in libtool, but it manifests itself clearly in GCC.
[Bug libfortran/49970] "make prefix=... install" doesn't work
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:26:07 UTC --- I'm really tired of invalidating whole builds by reconfiguring just to install in a separate dir. I'm reopening this as a wishlist. Joseph: where can I track this for upstream libtool? I remember I had pinged the libtool ML back then, but got no feedback.
[Bug other/53891] New: CFLAGS set in configure don't propagate
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: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ji...@gmx.net In a standard autotooled application it is only necessary to set CFLAGS on the ./configure command or in the environment. In gcc this is not enough, and at least BOOT_CFLAGS needs to be set on the make command line. For example the following is not enough: $ CFL="-O0 -g3 -fno-inline -march=i586" $ export -p | grep FLAG declare -x BOOT_CFLAGS="-O0 -g3 -fno-inline -march=i586" declare -x BOOT_CXXFLAGS="-O0 -g3 -fno-inline -march=i586" declare -x CFLAGS="-O0 -g3 -fno-inline -march=i586" declare -x CXXFLAGS="-O0 -g3 -fno-inline -march=i586" $ ~/path/to/gcc/configure --prefix=`pwd` --enable-checking=release --disable-multilib --disable-plugins --enable-languages=c,c++ CFLAGS="$CFL" BOOT_CFLAGS="$CFL" CXXFLAGS="$CFL" BOOT_CXXFLAGS="$CFL" $ make And I need this to actually get a final gcc compiled with my flags: $ make BOOT_CFLAGS="$CFL" BOOT_CXXFLAGS="$CFL" I think we should require setting the flags only on ./configure, and it would also be nice if CFLAGS propagated aumatically to CXXFLAGS.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 jimis changed: What|Removed |Added Attachment #27520|0 |1 is obsolete|| Attachment #27523|0 |1 is obsolete|| --- Comment #13 from jimis 2012-06-04 04:49:13 UTC --- Created attachment 27550 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27550 Diff of all changes versus the 20120513 snapshot. I think I'm closing to a final version of this fix. The attached patch contains all of the above mentioned changes, plus it fixes the memory leaks. This bootstraps fine and passes tests on x86 with no regression. Instruction count has been reduced from 2201M downto 2108M, which is only 30M higher than having track-macro-expansion (TME) turned off. Unfortunately actual runtime was improved less, so we gained back almost 50% of what we had lost by enabling TME. In short running the same test as above, with this (macro5) patch, gives: 2108 M instr 31692 KB RAM 0.760s In a few words, I introduced four (!) new obstacks inside struct cpp_reader for allocating the tokens from macro argument expansion, their virtual locations, the virtual locations of arguments, and the virtual locations of other macros. I'm not sure whether this is an elegant solution but growing obstacks for nested scopes is much more intuitive than reallocating arrays. I'd appreciate any comments on my "TODO" notes in this patch, which mostly concern whether I should move other allocations to obstacks as well. Finally, my patch still contains the additions to obstacks (obstack_mark, obstack_release). I'll try submitting them to glibc but since they are in the obstack.h header file, they work even when using the libc obstacks so I guess they can be committed in the gcc tree.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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_mark/release() calls in enter_macro_context() and it messes up previously allocated objects when going back in the recursion. The thing I don't get and so I can't figure out a solution, is where the virt_locs vector allocated inside tokens_buff_new() is freed. For example when it is called from the path cpp_get_token_1->paste_all_tokens->tokens_buff_new(), then when is the virt locs vector actually freed?
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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 2201 macro4 0.769s 2114
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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!
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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 are I had to introduce two new
functions, obstack_{mark,release}(), that allow me to continue growing an older
object by pushing and popping a special marker.
Previous patches are included with the following, but I'm submitting it
separately because it's WIP. Even though it is now stable, there is a bad
memory leak that I don't know how to handle since I'm kind of lost in the
macro-expansion code. I'd appreciate suggestions, just search for LEAK or TODO
in my comments. :-p
Please ignore whitespace changes (that are highlighted by emacs so I fix them)
or stylistic changes in parts that I rewrote so many times that lost completely
their initial style.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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 the virt_locs. It manages to save about 15 M instr or 2-3 ms, almost unnoticeable difference. Even though it seems to work fine it's not ready to commit, just an RFC for moving to obstacks. I'm also attaching some changes in libiberty.h that introduce some more XOB* macros.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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 'libcpp/macro.c'
--- libcpp/macro.c 2012-05-02 16:55:19 +
+++ libcpp/macro.c 2012-05-27 06:55:37 +
@@ -1897,10 +1897,9 @@ tokens_buff_new (cpp_reader *pfile, size
source_location **virt_locs)
{
size_t tokens_size = len * sizeof (cpp_token *);
- size_t locs_size = len * sizeof (source_location);
if (virt_locs != NULL)
-*virt_locs = XNEWVEC (source_location, locs_size);
+*virt_locs = XNEWVEC (source_location, len);
return _cpp_get_buff (pfile, tokens_size);
}
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
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 whenever we enter macro context in enter_macro_context()->linemap_enter_macro(). The following one-liner seems to resolve this, as run time is improved by about 7ms or 45 M Instr. === modified file 'libcpp/line-map.c' --- libcpp/line-map.c 2012-04-30 11:42:12 + +++ libcpp/line-map.c 2012-05-27 06:52:08 + @@ -331,7 +331,6 @@ linemap_enter_macro (struct line_maps *s num_tokens * sizeof (source_location)); LINEMAPS_MACRO_CACHE (set) = LINEMAPS_MACRO_USED (set) - 1; - set->max_column_hint = 0; return map; }
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 jimis changed: What|Removed |Added CC||abel at gcc dot gnu.org, ||amonakov at gcc dot ||gnu.org, dodji at gcc dot ||gnu.org, tromey at gcc dot ||gnu.org --- Comment #1 from jimis 2012-05-30 04:04:00 UTC --- I'll be posting some patches that try to improve CPU usage, some simple but most more complex that don't work properly so I'd appreciate advice. CC'ing mentors and tromey+Dodji who I think are the owners of the initial track-macro-expansion patch.
[Bug preprocessor/53525] New: Performance regression due to enabling track-macro-expansion
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 Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: ji...@gmx.net About 3% regression on cc1 -O0 compilation time has been noticed between gcc-4.8-20120429 and gcc-4.8-20120513. The culprit seems to be enabling by default -ftrack-macro-expansion (TME). Example time, instruction count and memory usage for compiling reload.c follow. timeM InstrKB RAM noTME0.744s208128608 TME0.785s220131672
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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 separate bug if it persists. The ICE is: configure:15628: ./gcc/gfortran -B./gcc/ -B./hppa2.0-unknown-linux-gnu/bin/ -B./hppa2.0-unknown-linux-gnu/lib/ -isystem ./hppa2.0-unknown-linux-gnu/include -isystem ./hppa2.0-unknown-linux-gnu/sys-include-c conftest.f >&5 init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t) ~(mpfr_uprec_t)0)>>1)) :0:0: internal compiler error: Aborted configure: failed program was: | | program foo | real, parameter :: bar = sin (12.34 / 2.5) | end program foo
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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 completeness.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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 strange message in its dmesg. Though unlikely, it might be that some kernel or hardware bug is involved...
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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 operator to be deleted. In the past we had faced a similar problem, I found the patch I think you had given me (attached). Could give a solution but doesn't apply cleanly now.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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).
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 jimis changed: What|Removed |Added Attachment #27335|0 |1 is obsolete|| --- Comment #5 from jimis 2012-05-08 06:37:21 UTC --- Created attachment 27338 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27338 guard.cc compile error
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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-threads=posix, but I'm sure a year ago I had bootstrapped without it.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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
[Bug libstdc++/53270] New: Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
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 Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ji...@gmx.net I get error while building guard_error.cc, see attached file for full details. Configure is done with --disable-libstdcxx-pch.
[Bug middle-end/51116] [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile
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 jimis 2011-11-13 05:27:54 UTC --- Does the following simple patch solve it? This undoes an optimisation, and there is an ongoing discussion about it so I expect it soon to be resolved one way on another: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01602.html I'm curious though: in pa64-hpux.h I can see that this part is in the GAS-specific part. Why are we emmiting HP-style labels? apinski, any pointers to that email about mips? === modified file 'gcc/config/elfos.h' --- gcc/config/elfos.h2011-10-30 01:45:46 + +++ gcc/config/elfos.h2011-11-12 02:51:39 + @@ -125,9 +125,6 @@ see the files COPYING3 and COPYING.RUNTI }\ while (0) -#undef TARGET_ASM_INTERNAL_LABEL -#define TARGET_ASM_INTERNAL_LABEL default_elf_internal_label - /* Output the label which precedes a jumptable. Note that for all svr4 systems where we actually generate jumptables (which is to say every svr4 target except i386, where we use casesi instead) we put the jump-
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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.
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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 it?
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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_LIMIT. Does this fix problems with Sun assembler?
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
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?
[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)
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 2011-08-13 01:39:23 UTC --- I think that the logic in this function is expressed in complicated manner. It took me some time to figure out what happens in various corner cases. The attached patch I think makes the code more readable/maintainable, hopefully it doesn't affect the function's logic at all. Runtime measured unaffected, if not a couple milliseconds faster. Bootstrapped and tested on x86_64. Thanks to Cristophe for pointing me here.
[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)
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 Apostolou * cse.c (preferable): Make it more readable and slightly faster, without affecting its logic.
[Bug target/49995] New: "operand missing mode" warning on sparc
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...@gcc.gnu.org ReportedBy: ji...@gmx.net Host: sparc-unknown-linux-gnu I get the following warnings while building gcc on a sparcstation: build/genrecog ../../gcc-trunk-109439-co/gcc/config/sparc/sparc.md \ insn-conditions.md > tmp-recog.c ../../gcc-trunk-109439-co/gcc/config/sparc/sync.md:82: warning: operand 1 missing mode? ../../gcc-trunk-109439-co/gcc/config/sparc/sync.md:94: warning: operand 1 missing mode? The relevant lines of sync.md are: 82 (define_insn "*sync_compare_and_swap" 83 [(set (match_operand:I48MODE 0 "register_operand" "=r") 84 (mem:I48MODE (match_operand 1 "register_operand" "r"))) 85(set (mem:I48MODE (match_dup 1)) 86 (unspec_volatile:I48MODE 87 [(match_operand:I48MODE 2 "register_operand" "r") 88(match_operand:I48MODE 3 "register_operand" "0")] 89 UNSPECV_CAS))] 90 "TARGET_V9 && (mode == SImode || TARGET_ARCH64)" 91 "cas\t[%1], %2, %0" 92 [(set_attr "type" "multi")]) 93 94 (define_insn "*sync_compare_and_swapdi_v8plus" 95 [(set (match_operand:DI 0 "register_operand" "=h") 96 (mem:DI (match_operand 1 "register_operand" "r"))) 97(set (mem:DI (match_dup 1)) 98 (unspec_volatile:DI 99 [(match_operand:DI 2 "register_operand" "h") 100(match_operand:DI 3 "register_operand" "0")] 101 UNSPECV_CAS))] 102 "TARGET_V8PLUS"
[Bug libfortran/49970] "make prefix=... install" doesn't work
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. joseph: Thanks for pointing me to that bug, hopefully this will be fixed in libtool, it's much needed functionality at least for me.
[Bug libfortran/49970] "make prefix=... install" doesn't work
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've only seen libgfortran failing.
Why it should be supported? Especially for GCC it is very handy, I build the
beast without configuring --prefix at all, and then install someplace. Then I
apply some patch, hit make and only relevant files are compiled, and install
some place elsewhere. If I had to reconfigure with a different --prefix, make
would build many more files, and I'd have to delete various config.cache files
because I reconfigured.
Quote from automake manual:
All these directory variables have values that start with either ‘${prefix}’ or
‘${exec_prefix}’ unexpanded. This works fine in Makefiles, but it makes these
variables hard to use in configure. This is mandated by the GNU coding
standards, so that the user can run ‘make prefix=/foo install’. The Autoconf
manual has a section with more details on this topic (see Installation
Directory Variables). See also Hard-Coded Install Paths.
[Bug libfortran/49970] New: "make prefix=... install" doesn't work
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: unassig...@gcc.gnu.org
ReportedBy: ji...@gmx.net
On a multilib x86_64 config, I tried doing "make prefix=$HOME/mydir install".
Installation failed in directory "x86_64-unknown-linux-gnu/32/libgfortran/"
because it tried writing to some dir under /usr/local. Looking into the
generated Makefile in that path I can see that the default prefix, /usr/local,
was hardcoded in several points.
Shouldn't it be ${prefix} instead of /usr/local?
