Re: GCC build on darwin12.3
Are you using Mac ports for gmp/mpfr/mpc libraries? I see that you have "-L/opt/local/lib" on you path. I had the same issue and as I recall it was related to installing iconv mac port package and incompatibility of iconv.h header files. I switched to building gmp/mpfr/mpc from sources and not installing mac ports. Alternatively you can run contrib/download_prerequisites. Nenad On 3/28/13 6:32 AM, Gabriel Dos Reis wrote: Hi, Do we still support GCC on recent versions of mac os x? The reason I am asking is that I have been unable to build GCC, both 4.8 branch and trunk, for about 2 weeks now. The failure as of this morning is: g++ -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o i386-c.o darwin-c.o \ cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/opt/local/lib -lmpc -lmpfr -lgmp -L../zlib -lz Undefined symbols for architecture x86_64: "_iconv", referenced from: convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*)in libcpp.a(charset.o) (maybe you meant: __cpp_destroy_iconv, cpp_init_iconv(cpp_reader*) ) "_iconv_close", referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_convert_input in libcpp.a(charset.o) "_iconv_open", referenced from: init_iconv_desc(cpp_reader*, char const*, char const*)in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [cc1] Error 1 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2 Configuration flags: --disable-nls --disable-multilib --enable-languages=c++ The iconv library appears to be working with other programs just fine. -- Gaby
Re: gcc build on FC18 and automake 1.11
On 3/27/13 5:27 PM, Ian Lance Taylor wrote: You could install autoconf 2.64, which is the version used to build the configure files in the GCC tree. I am using 2.64 (installed from the source). I also installed automake 1.11.1 from the source, but 'aclocal' (part of automake) is a perl script and the systems perl package moved to 5.16.2 which is the cause of the warning. Or you could move the GCC tree forward to newer versions of these tools. At the moment I see that automake 1.11.1 is used everywhere except libgfortran that uses 1.11.3. boehm-gc/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libatomic/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libbacktrace/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libffi/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libgfortran/Makefile.in:# Makefile.in generated by automake 1.11.3 from Makefile.am. libgo/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libgomp/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libgupc/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libitm/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libjava/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libmudflap/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libquadmath/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libsanitizer/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libssp/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. libstdc++-v3/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. lto-plugin/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. zlib/Makefile.in:# Makefile.in generated by automake 1.11.1 from Makefile.am. I am not sure that I have enough insight into the autoconf/automake tools to move the GCC tree forward.
gcc build on FC18 and automake 1.11
The latest Fedora Core 18 comes with automake 1.12.1 and perl 5.16.2. I installed and tried to use automake 1.11.1 for one of the GCC libraries, but got a warning from aclocal: main::scan_file() called too early to check prototype at /usr/local/bin/aclocal line 617. The latest 1.11.6 has the same issue, but automake 1.12.1 fixed that warning by having subroutine prototypes early in the code. What would be the right way to go about this? Just put up with the warning? Nenad
gcc trunk target libraries do not build on Darwin 12.1
I am having trouble building the trunk om Mac OS X 10.8.1 (Darwin 12.1.0). Configuring target libraries fails with the following error (e.g. libatomic): configure:3477: checking for C compiler default output file name configure:3499: /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/xgcc -B/eng/upc/dev/nenad/gcc-trunk/bld/./gcc/ -B/usr/local/x86_64-apple-darwin12.1.0/bin/ -B/usr/local/x86_64-apple-darwin12.1.0/lib/ -isystem /usr/local/x86_64-apple-darwin12.1.0/include -isystem /usr/local/x86_64-apple-darwin12.1.0/sys-include-g -O2 conftest.c >&5 Undefined symbols for architecture x86_64: "start", referenced from: -u command line option ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status The above uses the following link lines: /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.1 -weak_reference_mismatches non-weak -o a.out -L/eng/upc/dev/nenad/gcc-trunk/bld/./gcc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//cc6kpstu.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v -idsym -dsym collect2 version 4.8.0 20120828 (experimental) /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/collect-ld -dynamic -arch x86_64 -macosx_version_min 10.8.1 -weak_reference_mismatches non-weak -o a.out -L/eng/upc/dev/nenad/gcc-trunk/bld/./gcc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//cc6kpstu.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v Test links if I add "-lcrt1.o" on the command line. I have the latest Xcode loaded and my Mac is up to date. Any idea? Nenad
Building gcc on Ubuntu 11.10
Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the following linking problem (no special configure switches): /usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: cannot find -lgcc /usr/bin/ld: cannot find -lgcc_s Noramly they under /usr/lib64, but 11.10 has them under /usr/lib/x86_64-linux-gnu. Thanks, Nenad
"-g" option enables var_tracking and long compilation on Darwin - x86_64-apple-darwin10.8.0
I have a test program written in UPC that takes a long time to compile on Mac OS X. This is caused by the var_tracking code that I think is getting erroneously enabled for no-optimization case - only "-g" option is used on a command line. When process_options (in toplevel.c) is called, flag_var_tracking has a value of 2 which is AUTODETECT_VALUE, and is getting set based on the optimization level: 1466 if (flag_var_tracking == AUTODETECT_VALUE) 1467 flag_var_tracking = optimize >= 1; For x86_64 on Linux box this would set flag_var_tracking to 0. However, for Darwin, "target_option.override" is used and darwin_override_options() is called at the beginning of the process_options() and this code is getting executed: 2929 if (flag_var_tracking 2930 && generating_for_darwin_version >= 9 2931 && (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE) 2932 : (debug_info_level >= DINFO_LEVEL_NORMAL)) 2933 && write_symbols == DWARF2_DEBUG) 2934 flag_var_tracking_uninit = 1; The above will set "flag_var_tracking_uninit" as all conditions are there: flag_var_tracking == 2 generating_for_darwin_version == 10 debug_info_level >= DINFO_LEVEL_NORMAL write_symbols == DWARF2_DEBUG Once code returns to process_options: 1460 /* If the user specifically requested variable tracking with tagging 1461 uninitialized variables, we need to turn on variable tracking. 1462 (We already determined above that variable tracking is feasible.) */ 1463 if (flag_var_tracking_uninit) 1464 flag_var_tracking = 1; 1465 1466 if (flag_var_tracking == AUTODETECT_VALUE) 1467 flag_var_tracking = optimize >= 1; flag_var_tracking is getting unconditionally set based debug level (not optimization). The net effect is that for Darwin, var_tracking is always enabled, even for the optim level of 0. If I specify "-g -fvar-tracking" on the Linux x86_64 box I also get long compile times on my test. What is the reason to enable var_tracking for -O0 on Darwin? Is var_tracking supposed to run at all on -O0. Thanks, Nenad
Re: adding an argument for test execution in testsuite
It is unfortunate that UPC program cannot use dg-additional-sources
as we would need to change our run-time to support this option. By the
time we reach "main" run-time is already initialized to support specified
number of threads. One of the options might be to define a default number
of threads to run if number is not specified.
Anyway, I spent a little bit more time on this and was able to create a
wrapper for "upc_load" function the same way it is done in gcc-dg.exp
(renaming the old upc_load into prev_upc_load). Wrapper adds the necessary
flags for dynamic environment. Notice that ${tool}_load already accepts
arguments that can be passed to the program.
Nenad
On 5/4/11 3:32 PM, Janis Johnson wrote:
On 05/04/2011 11:21 AM, Nenad Vukicevic wrote:
It seems that I fixed my problem by defining remote_spawn
procedure (and fixing the order of loading libraries :) ) in my
own upc-dg.exp file and adding a line to it that append
additional arguments to the command line: "append commandline
$upc_run_arguments".
global $upc_run_arguments is getting set before dg-test is being
called. I used a simple string compare to see if dynamic
threads are required. So far it works as expected.
Working "so far" shouldn't be good enough, especially if your test will
be run for a variety of targets.
Presumably you don't really need the number of threads to be specified
on the command line, you just need for it to look as if it were
specified at run time. You could, for example, define it in a second
source file included in the test via dg-additional-sources and use it
from a global variable or call a function to get it.
Janis
Re: adding an argument for test execution in testsuite
It seems that I fixed my problem by defining remote_spawn procedure (and fixing the order of loading libraries :) ) in my own upc-dg.exp file and adding a line to it that append additional arguments to the command line: "append commandline $upc_run_arguments". global $upc_run_arguments is getting set before dg-test is being called. I used a simple string compare to see if dynamic threads are required. So far it works as expected. Thank you. Nenad On 5/4/2011 10:18 AM, Ian Lance Taylor wrote: Nenad Vukicevic writes: Thank you for your response. I am trying to write some tests for GUPC that have two modes of compilation: static and dynamic. In static environment you specify number of threads you want to run in compile time, while in dynamic you specify it when you run the program (prog -n4 args). We have to test both modes and I was thinking of checking the compile arguments and passing -n4 to _load procedure for dynamic case. It could be that I can accomplish this with a new target in dejagnu. I tried defining upc_load() procedure (the same way gnat_load() is defined) and possible add all the necessary code to it, but was not successful in dejagnu calling it. Sorry, I can't help you there. DejaGNU is just awful. It has only one thing going for it, which is that it mostly works. In every other respect it is worse than having no test harness at all. Unfortunately that one advantage currently outweighs the disadvantages. Ian
Re: adding an argument for test execution in testsuite
On 5/3/2011 3:47 PM, Ian Lance Taylor wrote: There is no support for passing options to a test in the dg framework. You would have to write your own Tcl code to do that. Note that such tests are somewhat discouraged because not all remote execution environments support passing command line arguments. It's OK to do it if the command line argument is optional or if the test can never work on an embedded system anyhow. Ian Thank you for your response. I am trying to write some tests for GUPC that have two modes of compilation: static and dynamic. In static environment you specify number of threads you want to run in compile time, while in dynamic you specify it when you run the program (prog -n4 args). We have to test both modes and I was thinking of checking the compile arguments and passing -n4 to _load procedure for dynamic case. It could be that I can accomplish this with a new target in dejagnu. I tried defining upc_load() procedure (the same way gnat_load() is defined) and possible add all the necessary code to it, but was not successful in dejagnu calling it. Nenad
adding an argument for test execution in testsuite
Is it possible to add an argument to the test in the execution phase of the testsuite? I am looking into some test cases where number of threads to run must be provided on the invocation line of the test if not specified during the test compilation. Something that is similar to "dg-skip-if" syntax but would add a run-time option if there is a match. Thanks, Nenad
Re: Two debug entries for one local variables, is it a bug in GCC or GDB
I reported something similar back in January:
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
As I recall, GCC creates duplicates.
Nenad
On 7/8/10 7:33 PM, asmwarrior wrote:
I have post this message to both GCC and GDB, because I'm not sure it
is a bug in GDB or GCC.
Hi, I have just find two dwarf debug entries for one local variables.
For example, the sample code is just like:
-
wxString ParserThread::ReadAncestorList()
{
wxString ccc;
wxString templateArgument;
wxString aaa;
aaa = m_Tokenizer.GetToken(); // eat ":"
templateArgument = aaa;
while (!TestDestroy())
{
//Peek the next token
wxString next = m_Tokenizer.PeekToken();
if (next.IsEmpty()
|| next==ParserConsts::opbrace
|| next==ParserConsts::semicolon ) // here, we are at the
end of ancestor list
{
break;
}
else if (next==ParserConsts::lt) // class AAA : BBB<
int, float>
{
wxString arg = SkipAngleBraces();
if(!arg.IsEmpty()) // find a matching<>
{
templateArgument< find. Error!!!") );
}
}
...
---
But I found that GDG can show the wxString aaa correctly, but wxString
templateArgument incorrectly.
I have just check the debug information in the object file.
and found that there are two entries for local variable
"argumentTemplate", but only one entry for "aaa".
<2><40a9f>: Abbrev Number: 182 (DW_TAG_variable)
<40aa1>DW_AT_name: (indirect string, offset: 0x1095):
templateArgument
<40aa5>DW_AT_decl_file : 19
<40aa6>DW_AT_decl_line : 2593
<40aa8>DW_AT_type:<0xd168>
<40aac>DW_AT_accessibility: 3(private)
<40aad>DW_AT_location: 2 byte block: 53 6 (DW_OP_reg3;
DW_OP_deref)
<2><40ab0>: Abbrev Number: 164 (DW_TAG_lexical_block)
<40ab2>DW_AT_ranges : 0x168
<3><40ab6>: Abbrev Number: 165 (DW_TAG_variable)
<40ab8>DW_AT_name: ccc
<40abc>DW_AT_decl_file : 19
<40abd>DW_AT_decl_line : 2592
<40abf>DW_AT_type:<0xd168>
<40ac3>DW_AT_location: 2 byte block: 91 50 (DW_OP_fbreg: -48)
<3><40ac6>: Abbrev Number: 179 (DW_TAG_variable)
<40ac8>DW_AT_name: (indirect string, offset: 0x1095):
templateArgument
<40acc>DW_AT_decl_file : 19
<40acd>DW_AT_decl_line : 2593
<40acf>DW_AT_type:<0xd168>
<40ad3>DW_AT_location: 2 byte block: 91 4c (DW_OP_fbreg: -52)
<3><40ad6>: Abbrev Number: 165 (DW_TAG_variable)
<40ad8>DW_AT_name: aaa
<40adc>DW_AT_decl_file : 19
<40add>DW_AT_decl_line : 2594
<40adf>DW_AT_type:<0xd168>
<40ae3>DW_AT_location: 2 byte block: 91 48 (DW_OP_fbreg: -56)
<3><40ae6>: Abbrev Number: 170 (DW_TAG_lexical_block)
--
Also, you can see the screen shot in my Codeblocks forums' post:
http://forums.codeblocks.org/index.php/topic,12873.msg86906.html#msg86906
So, my question is:
Is this a bug in GCC or GDB? ( I have just test the MinGW GCC 4.5 and
MinGW 4.4.4, they get the same result)
Thanks
Asmwarrior (ollydbg from codeblocks' forum)
Re: dwarf2 - multiple DW_TAG_variable for global variable
We used GCC regression testing to pin point PR39563 when
multiple (but not equal) definitions started appearing in
dwarf code. We used the head version of GCC, gcc-4.5.20091224
to be precise, for testing this abnormally.
I also saw appearance of DIEs duplicates you mention in PR 39524
in the following example:
extern int x;
int main(){x=1;}
gcc 4.3.2 - does NOT have duplicates
gcc 4..4.1 20090725 (REDHAT 4.4.1-2) - does have duplicates
gcc 4.4.2 - does NOT have duplicates
gcc 4.5.20091224 - does have duplicates
Duplicates are in the form described in PR39524.
In the case of this code:
int x;
int main(){x=1;}
I see duplicates in the form of:
<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55> DW_AT_name: (indirect string, offset: 0x38): x
<59> DW_AT_decl_file : 1
<5a> DW_AT_decl_line : 1
<5b> DW_AT_type: <0x4d>
<5f> DW_AT_external: 1
<60> DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62> DW_AT_name: (indirect string, offset: 0x38): x
<66> DW_AT_decl_file : 1
<67> DW_AT_decl_line : 1
<68> DW_AT_type: <0x4d>
<6c> DW_AT_external: 1
<6d> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
in 4.4.1 and 4.5 releases.
Any idea if this is a correct dwarf? Or must be treated as a duplicate
somehow?
Thanks,
Nenad
On 1/9/10 1:18 PM, Jan Kratochvil wrote:
On Sat, 09 Jan 2010 22:01:54 +0100, Gary Funck wrote:
On 01/09/10 12:39:55, Nenad Vukicevic wrote:
This dwarf code started appearing since this patch:
Here's the GCC bug report that led to this patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
Such DIEs duplicities are being tracked at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
(Unaware how/if any were caused by the PR 39563.)
Regards,
Jan
Re: dwarf2 - multiple DW_TAG_variable for global variable
This dwarf code started appearing since this patch:
r145293 | jakub | 2009-03-30 14:35:03 + (Mon, 30 Mar 2009) | 11 lines
PR debug/39563
* c-decl.c (struct c_binding): Add locus field.
(bind): Add locus argument, set locus field from it.
(pop_scope): For b->nested VAR_DECL or FUNCTION_DECL,
add a DECL_EXTERNAL copy of b->decl to current BLOCK_VARS.
(push_file_scope, pushtag, pushdecl, pushdecl_top_level,
implicitly_declare, undeclared_variable, lookup_label,
declare_label, c_make_fname_decl, c_builtin_function,
c_builtin_function_ext_scope, store_parm_decls_newstyle): Adjust
bind callers.
Jan, can you confirm that this is indeed the correct DWARF that is being
generated.
Thank you,
Nenad
On 1/4/10 11:34 PM, Nenad Vukicevic wrote:
I installed gcc-4.5-20091224 snapshot and noticed that for simple
variable declaration
I get two DW_TAG_variable dies in the object file. For example, the
following
code
int x;
main()
{x=1;}
generates (with -g -gdwarf2 -O0 switches):
<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55> DW_AT_name: (indirect string, offset: 0x36): x
<59> DW_AT_decl_file : 1
<5a> DW_AT_decl_line : 1
<5b> DW_AT_type: <0x4d>
<5f> DW_AT_external: 1
<60> DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62> DW_AT_name: (indirect string, offset: 0x36): x
<66> DW_AT_decl_file : 1
<67> DW_AT_decl_line : 1
<68> DW_AT_type: <0x4d>
<6c> DW_AT_external: 1
<6d> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0
(DW_OP_addr: 0)
Is the above normal? 4.3.2 compiler generates only one die, the second
one with
DW_AT_location attribute, which is correct.
I also noticed that this example (were variable is not used):
int x;
main()
{}
generates only one DW_TAG_variable, the one with DW_AT_location,
which again
should be correct.
I ran into this problem by porting some GDB code that uses DWARF2 and
got surprised
to see this change from the previous version of gcc (4.3).
Thanks,
Nenad
dwarf2 - multiple DW_TAG_variable for global variable
I installed gcc-4.5-20091224 snapshot and noticed that for simple
variable declaration
I get two DW_TAG_variable dies in the object file. For example, the
following
code
int x;
main()
{x=1;}
generates (with -g -gdwarf2 -O0 switches):
<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55> DW_AT_name: (indirect string, offset: 0x36): x
<59> DW_AT_decl_file : 1
<5a> DW_AT_decl_line : 1
<5b> DW_AT_type: <0x4d>
<5f> DW_AT_external: 1
<60> DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62> DW_AT_name: (indirect string, offset: 0x36): x
<66> DW_AT_decl_file : 1
<67> DW_AT_decl_line : 1
<68> DW_AT_type: <0x4d>
<6c> DW_AT_external: 1
<6d> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
Is the above normal? 4.3.2 compiler generates only one die, the second
one with
DW_AT_location attribute, which is correct.
I also noticed that this example (were variable is not used):
int x;
main()
{}
generates only one DW_TAG_variable, the one with DW_AT_location, which
again
should be correct.
I ran into this problem by porting some GDB code that uses DWARF2 and
got surprised
to see this change from the previous version of gcc (4.3).
Thanks,
Nenad
