[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 Richard Biener changed: What|Removed |Added Keywords||documentation CC||mikestump at comcast dot net --- Comment #11 from Richard Biener --- I'm inclined to WONTFIX this bug given Snow Leopard is out of support, but maybe darwin people can test the latest OS-X version which still uses GCC as /usr/bin/g++ if it is affected by this bug? So we can at least document this issue in install.texi.
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #10 from Richard Biener ---
Note the function shouldn't ever be called since the call is guarded by:
if (set->trace_includes)
trace_include (set, map);
and the linemap should have set->trace_includes set to false. So
it would be interesting to look at (in the failing case) the assembly
of line-map.o:linemap_init which does
void
linemap_init (struct line_maps *set,
source_location builtin_location)
{
*set = line_maps ();
thus default-constructs line_maps and does an aggregate assignment.
Maybe sth goes wrong here and we can work around the bug by providing
a constructor initializing all members instead of relying on value-init.
Just in case you want to investigate some more ;)
Note that on the GCC 7 branch we instead do
linemap_init (struct line_maps *set,
source_location builtin_location)
{
memset (set, 0, sizeof (struct line_maps));
Martin - you changed this to assignment from default-construction. Was there
any good reason to do so?
Quickly checking compilers with the followign testcase shows
struct line_maps {
~line_maps ();
bool trace_includes;
};
void foo (line_maps *m)
{
*m = line_maps ();
}
GCC 4.2.4:
< = *(struct line_maps &) (struct line_maps *)
&TARGET_EXPR ) >>>
GCC 4.2.3:
;; Function line_maps::line_maps() (_ZN9line_mapsC1Ev *INTERNAL* )
;; enabled by -tree-original
{
}
;; Function void foo(line_maps*) (_Z3fooP9line_maps)
;; enabled by -tree-original
< = *(struct line_maps &) (struct line_maps *)
&TARGET_EXPR >>
>) >>>
>>;
so GCC 4.2.3 doesn't properly value-initialize for this expression (but 4.2.4
does). GCC 4.3.0 looks fine as well, so does 4.1.2 and 4.1.0 but not
4.2.{0,1,2} either.
Not sure what to suggest here but _not_ use unfixed 4.2.{0,1,2,3} as
host-compiler...
I suppose Apple isn't going to fix their GCC 4.2.x based compiler (IIRC
that's even gone for newer OS-X / XCode).
Eric - can you check Apple G++ on the above small testcase?
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #9 from rguenther at suse dot de --- On Wed, 14 Feb 2018, egallager at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 > > --- Comment #8 from Eric Gallager --- > (In reply to Eric Gallager from comment #7) > > It works when I use a previous version of gcc I built myself though. (8.0 > > from 20170525) > > Regardless of the fact that I was able to work around this bug, I'm still > wondering why those periods need to be printed in the first place? Would it > break anything to just remove that loop? I suspect so. I don't think the loop is in any way relevant - it just is the place where the stage1 miscompile manifests?
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > It works when I use a previous version of gcc I built myself though. (8.0 > from 20170525) Regardless of the fact that I was able to work around this bug, I'm still wondering why those periods need to be printed in the first place? Would it break anything to just remove that loop?
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #7 from Eric Gallager --- (In reply to Richard Biener from comment #6) > Hmm, somehow I remember reports similar to this on Darwin. Can you try > using clang for bootstrap? > > What X-Code version are you using on which OS version? > > The crash reporter suggests sth goes wrong with linking as it seems to crash > during init already. I'm using Xcode 3.2.6 on Snow Leopard. Using the system clang fails earlier in configure but I think that's because I screwed up my system headers on this system: configure: error: uint64_t or int64_t not found make[2]: *** [configure-stage1-gcc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 clang 5.0 from MacPorts fails in libbacktrace with: libtool: link: rm -fr .libs/libbacktrace.a .libs/libbacktrace.la libtool: link: ar rc .libs/libbacktrace.a .libs/atomic.o .libs/dwarf.o .libs/fileline.o .libs/posix.o .libs/print.o .libs/sort.o .libs/state.o .libs/backtrace.o .libs/simple.o .libs/unknown.o .libs/mmapio.o .libs/mmap.o ranlib: object: .libs/libbacktrace.a(dwarf.o) malformed object (unknown load command 1) ar: internal ranlib command failed make[4]: *** [libbacktrace.la] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-libbacktrace] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 ...which is probably an issue I should raise with MacPorts instead. It works when I use a previous version of gcc I built myself though. (8.0 from 20170525)
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #6 from Richard Biener --- Hmm, somehow I remember reports similar to this on Darwin. Can you try using clang for bootstrap? What X-Code version are you using on which OS version? The crash reporter suggests sth goes wrong with linking as it seems to crash during init already.
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > Created attachment 42594 [details] > genmatch crash report > > (In reply to Richard Biener from comment #3) > > Hmm, GCC 4.2 as host compiler and using non-standard flags (-Os). Can you > > try > > with standard flags? It's probably miscompiling libcpp and/or genmatch. > > When removing -Os it instead segfaults: > > build/genmatch --gimple ../../gcc/match.pd \ > > tmp-gimple-match.c > /bin/sh: line 1: 76756 Segmentation fault build/genmatch --gimple > ../../gcc/match.pd > tmp-gimple-match.c > make[3]: *** [s-match] Error 139 > make[2]: *** [all-stage1-gcc] Error 2 > make[1]: *** [stage1-bubble] Error 2 > make: *** [all] Error 2 > > Attaching the crash reporter log. I should probably also include the compilation warnings from a little above the crash: /usr/bin/g++-4.2 -c -g -DIN_GCC -fPIC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I/opt/local/include \ -o build/genmatch.o ../../gcc/genmatch.c ../../gcc/vec.h: In static member function ‘static size_t vec::embedded_size(unsigned int) [with T = c_expr::id_tab, A = va_heap]’: ../../gcc/vec.h:286: instantiated from ‘static void va_heap::reserve(vec*&, unsigned int, bool) [with T = c_expr::id_tab]’ ../../gcc/vec.h:1473: instantiated from ‘bool vec::reserve(unsigned int, bool) [with T = c_expr::id_tab]’ ../../gcc/vec.h:1582: instantiated from ‘T* vec::safe_push(const T&) [with T = c_expr::id_tab]’ ../../gcc/genmatch.c:1330: instantiated from here ../../gcc/vec.h:1075: warning: invalid access to non-static data member ‘vec::m_vecdata’ of NULL object ../../gcc/vec.h:1075: warning: (perhaps the ‘offsetof’ macro was used incorrectly) ../../gcc/vec.h: In static member function ‘static size_t vec::embedded_size(unsigned int) [with T = std::pair, A = va_heap]’: ../../gcc/vec.h:286: instantiated from ‘static void va_heap::reserve(vec*&, unsigned int, bool) [with T = std::pair]’ ../../gcc/vec.h:1473: instantiated from ‘bool vec::reserve(unsigned int, bool) [with T = std::pair]’ ../../gcc/vec.h:1493: instantiated from ‘bool vec::reserve_exact(unsigned int) [with T = std::pair]’ ../../gcc/vec.h:1556: instantiated from ‘void vec::safe_splice(const vec&) [with T = std::pair]’ ../../gcc/genmatch.c:1462: instantiated from here ../../gcc/vec.h:1075: warning: invalid access to non-static data member ‘vec, va_heap, vl_embed>::m_vecdata’ of NULL object ../../gcc/vec.h:1075: warning: (perhaps the ‘offsetof’ macro was used incorrectly)
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #4 from Eric Gallager --- Created attachment 42594 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42594&action=edit genmatch crash report (In reply to Richard Biener from comment #3) > Hmm, GCC 4.2 as host compiler and using non-standard flags (-Os). Can you > try > with standard flags? It's probably miscompiling libcpp and/or genmatch. When removing -Os it instead segfaults: build/genmatch --gimple ../../gcc/match.pd \ > tmp-gimple-match.c /bin/sh: line 1: 76756 Segmentation fault build/genmatch --gimple ../../gcc/match.pd > tmp-gimple-match.c make[3]: *** [s-match] Error 139 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 Attaching the crash reporter log.
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-13 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Hmm, GCC 4.2 as host compiler and using non-standard flags (-Os). Can you try with standard flags? It's probably miscompiling libcpp and/or genmatch.
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939
--- Comment #2 from Eric Gallager ---
(In reply to Marc Glisse from comment #1)
> Is that during stage 1 or in a later stage?
stage 1.
Backtraces, for reference:
(gdb) bt
#0 trace_include [inlined] () at
/Users/ericgallager/gcc/libcpp/line-map.c:1390
#1 0x00010003c105 in linemap_add (set=, reason=, sysp=,
to_file=0x100500f90 "../../gcc/match.pd", to_line=1) at
../../../libcpp/line-map.c:570
#2 0x00010002c33c in _cpp_do_file_change (pfile=0x100800400, reason=, to_file=, file_line=, sysp=) at ../../../libcpp/directives.c:1125
#3 0x000100033af7 in _cpp_stack_file (pfile=0x100800400, file=0x100500e80,
import=false, loc=0) at ../../../libcpp/files.c:932
#4 0x00010003556c in cpp_read_main_file (pfile=0x100800400,
fname=0x7fff5fbfb6e1 "../../gcc/match.pd") at ../../../libcpp/init.c:647
#5 0x000100011ead in main (argc=3, argv=0x7fff5fbfb208) at
../../gcc/genmatch.c:5002
(gdb) bt full
#0 trace_include [inlined] () at
/Users/ericgallager/gcc/libcpp/line-map.c:1390
map = (const line_map_ordinary *) #1 0x00010003c105 in linemap_add
(set=, reason=, sysp=, to_file=0x100500f90 "../../gcc/match.pd",
to_line=1) at ../../../libcpp/line-map.c:570
map = (const line_map_ordinary *) #2 0x00010002c33c in
_cpp_do_file_change (pfile=0x100800400, reason=, to_file=, file_line=, sysp=) at
../../../libcpp/directives.c:1125
map =
ord_map =
__FUNCTION__ = "_cpp_do_file_change"
#3 0x000100033af7 in _cpp_stack_file (pfile=0x100800400, file=0x100500e80,
import=false, loc=0) at ../../../libcpp/files.c:932
buffer =
sysp = 0
#4 0x00010003556c in cpp_read_main_file (pfile=0x100800400,
fname=0x7fff5fbfb6e1 "../../gcc/match.pd") at ../../../libcpp/init.c:647
No locals.
#5 0x000100011ead in main (argc=3, argv=0x7fff5fbfb208) at
../../gcc/genmatch.c:5002
r = (cpp_reader *) 0x100800400
gimple = true
input = 0x7fff5fbfb6e1 "../../gcc/match.pd"
cb = (cpp_callbacks *) 0x100800760
dir = (cpp_dir *) 0x100500e40
p = {
r = 0x0,
active_ifs = {
m_vec = 0x9
},
active_fors = {
m_vec = 0x7fff5fc005f8
},
oper_lists_set = 0x7,
oper_lists = {
m_vec = 0x7fff5fc3c028
},
capture_ids = 0x7fff5fbfb228,
last_id = 1606398432,
simplifiers = {
m_vec = 0x7fff5fc016de
},
user_predicates = {
m_vec = 0x7fff5fc00020
},
parsing_match_operand = false
}
dt = {
root = 0x7fff5fbfb208
}
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #1 from Marc Glisse --- Is that during stage 1 or in a later stage?
