[Almacenes e Inventarios.] Administracion, Organizacion y Control - 21 y 22 dejunio de 2012
Dos dias COMPLETOS, 6 Expertos compartiendo con ud Informacion CLAVE Congreso de Administración de Almacenes y Control de Inventarios Mexico, D.F. 21 y 22 de Junio de 2012 Para poder descargar el folleto responda este correo con los siguientes datos: Nombre: Empresa: Telefono (Lada): ( ) Ext: Numero de Interesados: Haga extensiva esta invitacion a Todos sus Contactos Centro nacional de Atencion Telefonica: 01 800250 20 30 Para dar de Baja responda DELETEALMACENES
[testsuite] darwin leftover .dSYM dirs in the testsuite ?
Hi,
blindvt: BTW since you have looked at this piece of code, you
may give me some advice:
on darwin* all the tests compiled with -g generate *.dSYM
folders. I'ld like to clean them.
Perhaps something like the attached? I find it a bit difficult to fit
that into the testsuite properly, so this is not a patch proposal.
Rainer, Mike, can you please advise on how we could do this properly?
TIA && cheers,
Not a patch!
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 4666ede..7c704fc 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -425,6 +425,36 @@ proc remove-build-file { pat } {
}
}
+# Remove files matching the pattern from the build machine.
+# Same as remove-build-file except that it can delete directories, too..
+# AFAICS this would need fixing in dejagnu which explicitly checks
+# isfile, pity.
+proc remove-build-dir { pat } {
+rename standard_file saved-standard_file
+proc standard_file { dest op args } {
+set file [lindex $args 0]
+verbose "dest in proc repaired-standard_file is $dest" 3
+if { ![is_remote $dest] } {
+if ![string compare $op "delete"] { # "deletedir" ?
+ file delete -force -- $args
+ }
+} else {
+saved-standard_file $dest $op $args
+}
+}
+verbose "remove-build-dir `$pat'" 2
+set file_list "[glob -nocomplain $pat]"
+verbose "remove-build-dir `$file_list'" 2
+foreach output_file $file_list {
+ if [is_remote host] {
+ # Ensure the host knows the file is gone by deleting there
+ # first.
+ remote_file host delete $output_file
+ }
+ remote_file build delete $output_file
+}
+}
+
# Remove runtime-generated profile file for the current test.
proc cleanup-profile-file { } {
remove-build-file "mon.out"
diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp
index bb1763a..86996d4 100644
--- a/gcc/testsuite/lib/gcc.exp
+++ b/gcc/testsuite/lib/gcc.exp
@@ -127,7 +127,7 @@ proc gcc_target_compile { source dest type options } {
global GCC_UNDER_TEST
global TOOL_OPTIONS
global TEST_ALWAYS_FLAGS
-
+
if {[target_info needs_status_wrapper] != "" && \
[target_info needs_status_wrapper] != "0" && \
[info exists gluefile] } {
@@ -161,5 +161,20 @@ proc gcc_target_compile { source dest type options } {
lappend options "timeout=[timeout_value]"
lappend options "compiler=$GCC_UNDER_TEST"
set options [dg-additional-files-options $options $source]
+
+if [istarget *-*-darwin*] {
+# on darwin, files compiled with -g leave a .dSYM dir behind, nuke it
+# ??? probably additional_clean_{dir,file}s or the like?
+if {[lsearch -regexp $options "\[ \t=\]\-g"] >= 0} {
+upvar 2 dg-final-code finalcode
+if ![info exists finalcode] {
+upvar 3 dg-final-code finalcode
+}
+
+set dsym "[file rootname [file tail $dest]].dSYM"
+set finalcode [concat $finalcode "remove-build-dir $dsym{/\*,}\n"]
+}
+}
+
return [target_compile $source $dest $type $options]
}
IRA_COVER_CLASSES In gcc47
Hello, I am trying to find exactly what happened to IRA_COVER_CLASSES in gcc47. From what I have seen it seems that it was simply removed. Does the register allocator now automatically computes the cover classes? Cheers, -- PMatos
[gimplefe] Merge from trunk rev 185711
This merge brings the branch up to 4.8. Bootstrapped on x86_64.
Re: IRA_COVER_CLASSES In gcc47
On 03/23/2012 11:04 AM, Paulo J. Matos wrote: Hello, I am trying to find exactly what happened to IRA_COVER_CLASSES in gcc47. From what I have seen it seems that it was simply removed. Does the register allocator now automatically computes the cover classes? No. Before gcc4.7 we use coloring on non-intersected classes (so called cover classes). That was a classical approach with well known disadvantages for irregular register class architectures. Since 4.7 we use more sophisticated trivial coloring criteria which work well even on intersected register classes. To be more accurate, we calculate an approximation of an profitable hard regs for each pseudo. These approximations form a tree. The tree is used for find trivial colorability of the pseudos. It was a surprise that such approach is profitable even for architectures with regular register files like ppc. Here is an excerpt from comments on the top ira.c file: We also use a modification of Chaitin-Briggs algorithm which works for intersected register classes of allocnos. To figure out trivial colorability of allocnos, the mentioned above tree of hard register sets is used. To get an idea how the algorithm works in i386 example, let us consider an allocno to which any general hard register can be assigned. If the allocno conflicts with eight allocnos to which only EAX register can be assigned, given allocno is still trivially colorable because all conflicting allocnos might be assigned only to EAX and all other general hard registers are still free. To get an idea of the used trivial colorability criterion, it is also useful to read article "Graph-Coloring Register Allocation for Irregular Architectures" by Michael D. Smith and Glen Holloway. Major difference between the article approach and approach used in IRA is that Smith's approach takes register classes only from machine description and IRA calculate register classes from intermediate code too (e.g. an explicit usage of hard registers in RTL code for parameter passing can result in creation of additional register classes which contain or exclude the hard registers). That makes IRA approach useful for improving coloring even for architectures with regular register files and in fact some benchmarking shows the improvement for regular class architectures is even bigger than for irregular ones. Another difference is that Smith's approach chooses intersection of classes of all insn operands in which a given pseudo occurs. IRA can use bigger classes if it is still more profitable than memory usage.
Re: IRA_COVER_CLASSES In gcc47
Vladimir, Thanks for for the explanation. Cheers, Paulo Matos On 23/03/12 16:08, Vladimir Makarov wrote: On 03/23/2012 11:04 AM, Paulo J. Matos wrote: Hello, I am trying to find exactly what happened to IRA_COVER_CLASSES in gcc47. From what I have seen it seems that it was simply removed. Does the register allocator now automatically computes the cover classes? No. Before gcc4.7 we use coloring on non-intersected classes (so called cover classes). That was a classical approach with well known disadvantages for irregular register class architectures. Since 4.7 we use more sophisticated trivial coloring criteria which work well even on intersected register classes. To be more accurate, we calculate an approximation of an profitable hard regs for each pseudo. These approximations form a tree. The tree is used for find trivial colorability of the pseudos. It was a surprise that such approach is profitable even for architectures with regular register files like ppc. Here is an excerpt from comments on the top ira.c file: We also use a modification of Chaitin-Briggs algorithm which works for intersected register classes of allocnos. To figure out trivial colorability of allocnos, the mentioned above tree of hard register sets is used. To get an idea how the algorithm works in i386 example, let us consider an allocno to which any general hard register can be assigned. If the allocno conflicts with eight allocnos to which only EAX register can be assigned, given allocno is still trivially colorable because all conflicting allocnos might be assigned only to EAX and all other general hard registers are still free. To get an idea of the used trivial colorability criterion, it is also useful to read article "Graph-Coloring Register Allocation for Irregular Architectures" by Michael D. Smith and Glen Holloway. Major difference between the article approach and approach used in IRA is that Smith's approach takes register classes only from machine description and IRA calculate register classes from intermediate code too (e.g. an explicit usage of hard registers in RTL code for parameter passing can result in creation of additional register classes which contain or exclude the hard registers). That makes IRA approach useful for improving coloring even for architectures with regular register files and in fact some benchmarking shows the improvement for regular class architectures is even bigger than for irregular ones. Another difference is that Smith's approach chooses intersection of classes of all insn operands in which a given pseudo occurs. IRA can use bigger classes if it is still more profitable than memory usage. -- PMatos
Re: [testsuite] darwin leftover .dSYM dirs in the testsuite ?
Hi Bernhard,
Thanks for the "Not a patch!". I have started to play with it.
In order to get something working I had to add
rename standard_file ""
rename saved-standard_file standard_file
at the end of the proc remove-build-dir, otherwise I had only errors
ERROR: gcc.c-torture/compile/2105-2.c -O3 -g : error executing dg-final:
can't rename to "saved-standard_file": command already exists
I don't have any idea of the impact of this kludge on the time
taken by the test (I'll try to figure out that later).
AFAICT the number of *.dSYM directories for gcc is reduced from
over 1400 to less than 270, not too bad, but not perfect;-)
This may due to several errors I see. They are of two classes:
...
ERROR: gcc.dg/20040813-1.c: error executing dg-final: scan-assembler: too many
arguments
ERROR: gcc.dg/20060410.c: error executing dg-final: scan-assembler: too many
arguments
...
ERROR: c-c++-common/gomp/atomic-12.c: error executing dg-final: wrong # args:
should be "cleanup-tree-dump suffix"
ERROR: c-c++-common/gomp/atomic-13.c: error executing dg-final: wrong # args:
should be "cleanup-tree-dump suffix"
...
and
...
Running /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp ...
ERROR: tcl error sourcing
/opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
while executing
"error "torture-init: torture_without_loops is not empty as expected""
invoked from within
"if [info exists torture_without_loops] {
error "torture-init: torture_without_loops is not empty as expected"
}"
(procedure "torture-init" line 4)
invoked from within
"torture-init"
(file "/opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp" line 48)
invoked from within
"source /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
...
Although my Tcl is a little bit rusty, I think I can debug the first kind of
errors.
The second kind will require to understand why torture_without_loops is not
empty, hence some of the dejagnu machinery.
Before starting debugging, I wonder if it would not be simpler to execute a
"rm -rf *.sYM" in the *.lof directories at the end of each test class (gcc,
g++, ...).
Cheers,
Dominique
Re: IRA_COVER_CLASSES In gcc47
Hi Valdimir Le vendredi 23 mars 2012 à 12:08 -0400, Vladimir Makarov a écrit : > Since 4.7 we use more sophisticated trivial coloring criteria which work > well even on intersected register classes. To be more accurate, we > calculate an approximation of an profitable hard regs for each pseudo. > These approximations form a tree. The tree is used for find trivial > colorability of the pseudos. It was a surprise that such approach is > profitable even for architectures with regular register files like ppc. > Here is an excerpt from comments on the top ira.c file: I started porting an in house backend to GCC 4.7 and saw at least one huge regression relating to the IRA changes. The symptom in that benchmark is that all allocnos get pushed on the allocation stack as trivially colorable, but at unstacking time only the first ones get a hard reg and all others get spilled. AFAIU the CB coloring algorithm, all registers that get pushed as trivially colorable should get a hard reg when they are popped from the stack. Thus there must be some description issue in my backend that confuses the IRA. The register file is very regular. There are 64 SImode registers of which 3 are fixed. In order to store DImode values, 2 consecutive SImode registers are needed. The DImode pairs cannot be chosen anywhere in the register file, they need to start at even offset (however this still allows to have 32 DImode registers). In the testcase I'm looking at, we have ~32 DImode allocnos that are live from function start to the end. These registers conflict with (nearly) all other allocnos. These registers get pushed last, but strangely, they get pushed as trivially colorable. Of course, once the register file has been fully allocated to these long lived registers, nothing else can get a hard register anymore. In GCC 4.5, some of these DImode registers got marked as potential spill, and allowed the other pseudos to be correclty allocated. Do you have any idea what in my backend can confuse the trivial coloring criteria to mark all allocnos as trivially colorable ? Many thanks, Fred
Re: IRA_COVER_CLASSES In gcc47
On 12-03-23 3:47 PM, Frédéric RISS wrote: Hi Valdimir Le vendredi 23 mars 2012 à 12:08 -0400, Vladimir Makarov a écrit : Since 4.7 we use more sophisticated trivial coloring criteria which work well even on intersected register classes. To be more accurate, we calculate an approximation of an profitable hard regs for each pseudo. These approximations form a tree. The tree is used for find trivial colorability of the pseudos. It was a surprise that such approach is profitable even for architectures with regular register files like ppc. Here is an excerpt from comments on the top ira.c file: I started porting an in house backend to GCC 4.7 and saw at least one huge regression relating to the IRA changes. The symptom in that benchmark is that all allocnos get pushed on the allocation stack as trivially colorable, but at unstacking time only the first ones get a hard reg and all others get spilled. AFAIU the CB coloring algorithm, all registers that get pushed as trivially colorable should get a hard reg when they are popped from the stack. Thus there must be some description issue in my backend that confuses the IRA. It is not that definitely. There are some rare cases, when trivially colored pseudos do not get hard regs (e.g. mix of one and mult-reg pseudos or when the cost of regs for pseudos was changed during assinging pass). But the smaller number of such cases, the better implementation of coloring. The register file is very regular. There are 64 SImode registers of which 3 are fixed. In order to store DImode values, 2 consecutive SImode registers are needed. The DImode pairs cannot be chosen anywhere in the register file, they need to start at even offset (however this still allows to have 32 DImode registers). In the testcase I'm looking at, we have ~32 DImode allocnos that are live from function start to the end. These registers conflict with (nearly) all other allocnos. These registers get pushed last, but strangely, they get pushed as trivially colorable. Of course, once the register file has been fully allocated to these long lived registers, nothing else can get a hard register anymore. In GCC 4.5, some of these DImode registers got marked as potential spill, and allowed the other pseudos to be correclty allocated. Do you have any idea what in my backend can confuse the trivial coloring criteria to mark all allocnos as trivially colorable ? It might be because of situation of mult-regs pseudos requiring aligning. The best way to say something more definitely is to send me ira dump file for this case of course if it is ok for you (you could send it to me only). It would be even better if you send ira dump file for gcc 4.6 for the same test. Of course, it is possible. Many thanks, Fred
Should TLS symbols be in baseline_symbols.txt?
Hi, I saw alpha-linux-gnu/baseline_symbols.txt:TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 alpha-linux-gnu/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11 solaris2.10/amd64/baseline_symbols.txt:TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 solaris2.10/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11 solaris2.10/baseline_symbols.txt:TLS:4:_ZSt11__once_call@@GLIBCXX_3.4.11 solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11 solaris2.10/sparcv9/baseline_symbols.txt:TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 solaris2.10/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11 x86_64-linux-gnu/x32/baseline_symbols.txt:TLS:4:_ZSt11__once_call@@GLIBCXX_3.4.11 x86_64-linux-gnu/x32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11 If TLS symbols shouldn't be included, why aren't they filtered out by extract_symvers? -- H.J.
Built gcc 4.7.0 on OpenBSD x86_64
Hello, Following the recommendations on http://gcc.gnu.org/install/finalinstall.html, I'm reporting my success at building gcc 4.7.0 on amd64-unknown-openbsd4.8 because this platform is not listed in http://gcc.gnu.org/buildstat.html. My build is only "mostly" successful; I encountered and worked around several problems which I detail below. Help and suggestions are welcome. Here's gcc -v: Using built-in specs. COLLECT_GCC=gcc-4.7.0 COLLECT_LTO_WRAPPER=/storage/gcc470/usr/local/bin/../libexec/gcc/x86_64-unknown-openbsd4.8/4.7.0/lto-wrapper Target: x86_64-unknown-openbsd4.8 Configured with: ../gcc/configure --program-suffix=-4.7.0 --enable-threads --disable-werror Thread model: posix gcc version 4.7.0 (GCC) I have been unable so far to secure a release from my employer to contribute patches to GCC. So I'll just describe what I did as a reference for others. I configured with --disable-werror because on earlier releases of GCC I had trouble with the definition of NULL and functions expecting a sentinel. The switch is the easiest workaround, but might not be necessary anymore. I ran into two problems that have open PRs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52471 The first problem can be worked around most easily by killing the hung process. I do not have a "good" workaround for the second problem -- I bypassed the ICE by disabling some code in gcc/dwarf2cfi.c, which hobbles my ability to use a debugger. See my diffs below. On my platform I have an issue building libiberty. In libiberty/stack-limit.c I need to #include immediately before . I have also built GDB 7.4, which also uses libiberty, and it needs the identical workaround. While building GCC this command is eventually executed, and hangs on my system: ./gcj-dbtool -n classmap.db || touch classmap.db The command itself was a sufficient hint that this is optional. If I kill the hung gcj-dbtool process, everything continues nicely. Later, I get an error compiling ../../../gcc/boehm-gc/misc.c with a suggestive error message: In file included from /usr/include/xmmintrin.h:39:0, from /usr/include/emmintrin.h:34, from ../../../gcc/libitm/config/x86/target.h:77, from ../../../gcc/libitm/libitm_i.h:82, from ../../../gcc/libitm/aatree.cc:28: /usr/include/mmintrin.h: In function '__m64 _mm_add_si64(__m64, __m64)': /usr/include/mmintrin.h:312:72: error: cannot convert 'long long int' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_paddq(__vector(1) long long int, __vector(1) long long int)' Those header files should come from gcc/config/i386, not from /usr/include. If I symlink gcc/config/i386/*intrin.h into the build directory (obj/x86_64-unknown-openbsd4.8/libitm) and retry, it works. This may point to a bug in makefile generation that goes unnoticed on other platforms where the /usr/include headers and the gcc/config/i386 headers match. The resulting compiler works. The only trouble I've noticed so far is with std::thread. Any attempt to create a std::thread throws a std::system_error. I haven't been able to figure out what's wrong because the debugger doesn't work very well after my edit to gcc/dwarf2cfi.c. Here are my diffs. I do not warrant that any of these are correct, but they work well enough for me that I can make undebuggable single-threaded programs. Index: boehm-gc/include/private/gcconfig.h === --- boehm-gc/include/private/gcconfig.h (revision 185724) +++ boehm-gc/include/private/gcconfig.h (working copy) @@ -330,6 +330,11 @@ # define OPENBSD # define mach_type_known # endif +# if defined(__OpenBSD__) && (defined(__x86_64__)) +# define X86_64 +# define OPENBSD +# define mach_type_known +# endif # if defined(FREEBSD) && (defined(i386) || defined(__i386__)) # define I386 # define mach_type_known @@ -2065,6 +2070,12 @@ extern char etext[]; # define SEARCH_FOR_DATA_START # endif +# ifdef OPENBSD +# define OS_TYPE "OPENBSD" +# define HEURISTIC2 + extern char etext[]; +# define DATASTART ((ptr_t)(etext)) +# endif # ifdef SUNOS5 # define ELF_CLASS ELFCLASS64 # define OS_TYPE "SUNOS5" Index: libiberty/stack-limit.c === --- libiberty/stack-limit.c (revision 185724) +++ libiberty/stack-limit.c (working copy) @@ -39,6 +39,7 @@ #include #endif #ifdef HAVE_SYS_RESOURCE_H +#include #include #endif Index: libgcc/config.host === --- libgcc/config.host (revision 185724) +++ libgcc/config.host (working copy) @@ -538,6 +538,8 @@ ;; i[34567]86-*-openbsd*) ;; +x86_64-*-openbsd*) + ;; i[34567]86-*-linux*) extra_
