dwarf2out & var-tracking & cond_exec call
Hi,
I'm still porting my private backing from gcc 4.5.2 to gcc 4.7.3.
When compiling the following code with -g option, I encountered "internal
compiler error: in dwarf2out_var_location, at dwarf2out.c:20883"
void toto(int* , float);
void foo(int a, float b, int * c) {
if (b)
toto(c, b);
}
I don't know well what should contain NOTES but when I look at the gcc_assert
at dwarf2out.c:20883 :
gcc_assert (prev
&& (CALL_P (prev)
|| (NONJUMP_INSN_P (prev)
&& GET_CODE (PATTERN (prev)) == SEQUENCE
&& CALL_P (XVECEXP (PATTERN (prev), 0, 0);
I would say that COND_EXEC(CALL(..)) handling is missing. Is It right or
something went wrong on previous pass (var-tracking pass for example ...)
Here is my conditional call pattern :
(define_insn "call_cond"
[(cond_exec (match_operator 3 "comparison_operator"
[(match_operand 4 "cc_register" "") (const_int 0)])
(parallel[
(call (mem:SI (match_operand:SI 0 "call_address_op" " i,r"))
(match_operand:SI 1 "immediate_operand" " X,X"))
(clobber (match_operand:SI 2 "register_operand" "=r,r"))]))]
Regards,
Selim
RE: dwarf2out & var-tracking & cond_exec call
I found my problem totally elsewhere (sorry to bother)
I was loosing proper NOTES during a COND_EXEC((..)(CALL(..))) split ...
Selim
-Message d'origine-
De : gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] De la part de
BELBACHIR Selim
Envoyé : vendredi 29 novembre 2013 14:29
À : gcc@gcc.gnu.org
Objet : dwarf2out & var-tracking & cond_exec call
Hi,
I'm still porting my private backing from gcc 4.5.2 to gcc 4.7.3.
When compiling the following code with -g option, I encountered "internal
compiler error: in dwarf2out_var_location, at dwarf2out.c:20883"
void toto(int* , float);
void foo(int a, float b, int * c) {
if (b)
toto(c, b);
}
I don't know well what should contain NOTES but when I look at the gcc_assert
at dwarf2out.c:20883 :
gcc_assert (prev
&& (CALL_P (prev)
|| (NONJUMP_INSN_P (prev)
&& GET_CODE (PATTERN (prev)) == SEQUENCE
&& CALL_P (XVECEXP (PATTERN (prev), 0, 0);
I would say that COND_EXEC(CALL(..)) handling is missing. Is It right or
something went wrong on previous pass (var-tracking pass for example ...)
Here is my conditional call pattern :
(define_insn "call_cond"
[(cond_exec (match_operator 3 "comparison_operator"
[(match_operand 4 "cc_register" "") (const_int 0)])
(parallel[
(call (mem:SI (match_operand:SI 0 "call_address_op" " i,r"))
(match_operand:SI 1 "immediate_operand" " X,X"))
(clobber (match_operand:SI 2 "register_operand" "=r,r"))]))]
Regards,
Selim
Re: infrastructure to detect whether code originates from macro expansion
Hello Robert, Robert Schiele a écrit: > in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Manuel > López-Ibáñez mentioned that starting with gcc 4.7 there is supposed to > be infrastructure to figure out for diagnostics whether the location > of an error was created by macro expansion and that this can be used > to disable a warning in that case. Indeed. > Can anyone point me to the name of a function/macro I should use to > check that or another example in the code that already does this? I think you want to use the function linemap_location_from_macro_expansion_p() from libcpp/line-map.c. The pointer to struct line_maps set you pass is usually the global variable named 'line_table'. > I mean I can see how maybe_unwind_expanded_macro_loc figures out > whether it needs to unwind macro expansions but I am not sure whether > this linemap_lookup/linemap_macro_expansion_map_p stuff is what I am > supposed to use in the place where I check for the diagnostics to emit > or whether there is a higher level abstraction of this functionality. You are right, linemap_macro_expansion_map_p is a tad lower level than what you want. I hope this helps. Cheers. -- Dodji
Ada Indefinite_Holders
Hello, Would you mind to implement the function Ada.Containers.Indefinite_Holders.Reference (Container : aliased in out Holder) return Reference_Type; please? Best regards Christian Morgenroth
Getting LD warnings on Mac OS X
Hello there! I am trying to compile GCC using Apple’s latest tools. The reason is that I am building an own, redistributable, toolchain. Everything goes quite well (except a ton of warnings about redeclarations and c99 standart), untill it tries to link cc1. A rough rip-off of the warnings is: ld: warning: ignoring file ../libcpp/libcpp.a, file was built for archive which is not the architecture being linked (x86_64): ../libcpp/libcpp.a ld: warning: ignoring file libbackend.a, file was built for archive which is not the architecture being linked (x86_64): libbackend.a ld: warning: ignoring file ../libdecnumber/libdecnumber.a, file was built for archive which is not the architecture being linked (x86_64): ../libdecnumber/libdecnumber.a ld: warning: ignoring file ../libbacktrace/.libs/libbacktrace.a, file was built for archive which is not the architecture being linked (x86_64): ../libbacktrace/.libs/libbacktrace.a ld: warning: ignoring file ../zlib/libz.a, file was built for archive which is not the architecture being linked (x86_64): ../zlib/libz.a Im attaching what I get on STDOUT and STDERR when re-running make after this happens. Specs: Mac OS X 10.9 Developer tools: Latest Version of GCC to compile: 4.8.2 Configuration flags: ../gcc-4.8.2/configure \ --quiet \ --build=x86_64-apple-darwin13.0.0 \ --host=x86_64-apple-darwin13.0.0 \ --target=x86_64-apple-darwin13.0.0 \ --x-includes=/opt/X11/include \ --x-libraries=/opt/X11/lib \ --with-mpfr=/opt/GNUstep \ --with-gmp=/opt/GNUstep \ --with-mpc=/opt/GNUstep \ --enable-objc-gc \ --prefix=/opt/GNUstep/ \ --disable-werror \ --enable-languages=c,objc,c++,obj-c++ Kind regards, Ingwie make.stderr Description: Binary data make.stdin Description: Binary data
