Binary packages for Solaris
Hi, I just noticed that on the page with the list for binary packages for Solaris at https://gcc.gnu.org/install/binaries.html the distributions „Blastwave“ and „SunFreeware“ are still listed. Blastwave has closed its doors some month ago and SunFreeware has gone commercial (now available as unixpackages.com). You may want to remove these two from the list. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 smime.p7s Description: S/MIME cryptographic signature
Re: build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set
Gerald Pfeifer writes: > build/genmodes -h > tmp-modes.h > build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be > set > build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be > set > build/genmodes: machmode.def:203: (DF) field format must not be set > build/genmodes: machmode.def:202: (SF) field format must not be set > build/genmodes: machmode.def:244: (TD) field format must not be set > build/genmodes: machmode.def:243: (DD) field format must not be set > build/genmodes: machmode.def:242: (SD) field format must not be set > gmake[3]: *** [s-modes-h] Error 1 > gmake[3]: Leaving directory `/scratch2/tmp/gerald/OBJ-0708-1821/gcc' > gmake[2]: *** [all-stage3-gcc] Error 2 > gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0708-1821' > gmake[1]: *** [stage3-bubble] Error 2 > gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0708-1821' > gmake: *** [bootstrap-lean] Error 2 This is probably broken everywhere, happens even on ia64. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
ivdep pragma not used in ddg.c?
Hi, I noticed recent GCC adds ivdep pragma support. We have our own implementation for ivdep for a couple of years now. As GCC implementation is much cleaner and we want to migrate to it. Ivdep is consumed in two places in our implementation, one is tree-vect-data-refs.c used by vectorizer, the other is in ddg.c, used by modulo scheduler. In GCC implementation, the former is the same, but ddg.c doesn't consume ivdep information at all. I think it is important not to draw redundant cross-iteration dependence if ivdep is specified in order to improve modulo scheduling performance. Looking at the code, I wonder whether loop->safelen still keep the correct information or whether loop structure still remain correct after so many tree/rtl passes. For example, in sms-schedule of modulo-sched.c loop_optimizer_init (LOOPS_HAVE_PREHEADERS | LOOPS_HAVE_RECORDED_EXITS); Does this mean loop structure is reinitialized? I know there is a flag (PROP_loops) which is supposed to preserve loop structure. But not sure what happens after all loop transformation (unrolling, peeling, etc). Is there a stage loop structure is rebuilt and we lost safelen (ivdep) information, or it is still safe to use in modulo scheduling pass? Thanks, Bingfeng
Re: Using BUILT_IN_ATOMIC_...
On 07/09/2014 02:17 AM, Tobias Burnus wrote:
Hello all,
I am trying to use BUILT_IN_ATOMIC_..., but it does not quite work. I
am calling them as:
tmp = builtin_decl_explicit (BUILT_IN_ATOMIC_LOAD_4);
tmp = build_call_expr_loc (input_location, tmp, 2, atom.expr, ...
That gives the following dump:
__atomic_store_n (&i, 5, 0);
__atomic_store_n (&i, (integer(kind=4)) *k, 0);
j = (integer(kind=4)) __atomic_load_4 (&i, 0);
__atomic_add_fetch (&i, 5, 0);
The "__atomic_load_4" works, but the "__atomic_store_n" and
"__atomic_add_fetch" lead to link-time errors:
fo4o.f90:(.text+0x44): undefined reference to `__atomic_store_n'
fo4o.f90:(.text+0x73): undefined reference to `__atomic_add_fetch'
The issue with `__atomic_store_n', I can solve by replacing it by,
e.g., BUILT_IN_ATOMIC_STORE_4. However, how does one properly use
__atomic_add_fetch alias BUILT_IN_ATOMIC_ADD_FETCH_N, given that there
is no _4 version of it?
A lot of the specialized processing is handled by the parser. I tried
to move this to the middle end once upon a time, and the various
frustrations leaded me to the frontend/middle end separation project.
so, all the _N variations do not exist as actual functions that can be
called. They are shorthand for the parser to determine the size of the
object at compile time and call the appropriate _1, _2, _4, _8 or _16
routine. From the middle end, you ought to be able to call the correct
one directly since you should know the size of the object.
Since the front end "handles" the resolving of type size for _N
variations of the functions, the middle end uses those symbols to
represent the generic versions of the function. The generic versions
are the ones which simply take a buffer and a size, and operate on an
arbitrary number bytes (ie a 32 byte structure for instance). These
are usually implemented in libatomic via locks.
There are _{1,2,4,8,16} variations of BUILT_IN_ATOMIC_ADD_FETCH...
There is no *generic* version tho which is what you get when you try
calling the function without any _N variation. Performing an integral
operation on non-integral sizes makes no sense and is not supported in
the middle end.
So you need to explicitly set your BUILT_IN size decl. The parser
(From c-family/c-common.c::resolve_overloaded_builtin) figures that out
via something like:
fncode = (enum built_in_function)((int)BUILT_IN_ATOMIC_ADD_FETCH_N +
exact_log2 (n) + 1);
new_function = builtin_decl_explicit (fncode);
Probably ought to be a small function to do this :-P
Additionally, if one wants to fetch the old value (e.g. with
__atomic_add_fetch), how does one properly use the function result?
The problem is that TREE_TYPE() doesn't automatically match the type
of the first argument. Ignoring the type issue in the front end and
simply calling MODIFY_EXPR will lead to a gimplify.c ICE.
The types of the builtin functions are explicitly unsigned integral
types, you probably need to convert the result to the type you want.
the arguments are also expected to be unsigned (The front end converts
them), except for the first one which needs to be a pointer to the
unsigned type. I expect you can get away without the parameter types
being exact as long as they are all the right size... sinc all the
checking is in the front end :-)
Hope that helps.
Andrew
Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM
Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM
Dear all, Do you have any results of GCC and LLVM performance comparisons of different versions (for *ARM* architecture)? It's not obvious question to find such comparisons in Web, since Phoronix usually publishes comparisons for x86 and x86_64, and last comparison for ARM was performed in 2012: LLVM/Clang vs. GCC On The ARM Cortex-A15 Preview (1 December 2012): http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_a15&num=1 GCC vs. LLVM/Clang Compilers On ARMv7 Linux (09 May 2012 ): http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM Did anybody ever try to measure the dynamics of performance changes of GCC and LLVM (i. e. 2 comparative graphs from version to version) - for arm architecture? Best regards, Ilya Palachev
Re: ivdep pragma not used in ddg.c?
On July 9, 2014 12:49:15 PM CEST, Bingfeng Mei wrote: >Hi, >I noticed recent GCC adds ivdep pragma support. We have our own >implementation for ivdep for a couple of years now. As GCC >implementation is much cleaner and we want to migrate to it. Ivdep is >consumed in two places in our implementation, one is >tree-vect-data-refs.c used by vectorizer, the other is in ddg.c, used >by modulo scheduler. In GCC implementation, the former is the same, but >ddg.c doesn't consume ivdep information at all. I think it is important >not to draw redundant cross-iteration dependence if ivdep is specified >in order to improve modulo scheduling performance. > >Looking at the code, I wonder whether loop->safelen still keep the >correct information or whether loop structure still remain correct >after so many tree/rtl passes. For example, in sms-schedule of >modulo-sched.c > > loop_optimizer_init (LOOPS_HAVE_PREHEADERS > | LOOPS_HAVE_RECORDED_EXITS); > >Does this mean loop structure is reinitialized? I know there is a flag >(PROP_loops) which is supposed to preserve loop structure. But not sure >what happens after all loop transformation (unrolling, peeling, etc). >Is there a stage loop structure is rebuilt and we lost safelen (ivdep) >information, or it is still safe to use in modulo scheduling pass? Currently loop information is discarded after RTL loop optimizers because there is no later consumer. You'd have to extend lifetime if you add later users. Richard. >Thanks, >Bingfeng
Re: Binary packages for Solaris
On 09/07/14 08:59, Dagobert Michelsen wrote: Hi, I just noticed that on the page with the list for binary packages for Solaris at https://gcc.gnu.org/install/binaries.html the distributions „Blastwave“ and „SunFreeware“ are still listed. Blastwave has closed its doors some month ago and SunFreeware has gone commercial (now available as unixpackages.com). You may want to remove these two from the list. I've posted a patch to do that here: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00652.html -tgc
gcc-4.9-20140709 is now available
Snapshot gcc-4.9-20140709 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 212413 You'll find: gcc-4.9-20140709.tar.bz2 Complete GCC MD5=be17cd2d656a473f8684dacf5ee84682 SHA1=421aeb030de78545a75576cdb8f64acfb708ce3a Diffs from 4.9-20140702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
obsolete targets
Hi, I've noticed that the following targets are built in config-list.mk with --enable-obsolete i686-interix3 - doesn't appear to actually require --enable-obsolete though, should it be marked as obsolete in config.gcc? score-* and picochip-* since atleast sept 2012, is there a reason they haven't been removed yet? Also I've noticed that all the vms targets in config-list.mk fail because they try to link vms-c.o into cc1plus, but a symbol needed by vms-c.o is only defined in cc1 (it has been this way since at least mid may). Does anyone care about vms, or should we recognize what seems to be the state of afairs and mark it as obsolete? thanks! Trev
LTO ICE in D Frontend
Hi,
I'm trying to get to the bottom of a bug when using the D front-end with -flto.
When compiling anything, it always ICEs at in
streamer_get_pickled_tree, at tree-streamer-in.c.
The of it appears to be that the LTO frontend seems to never retrieve
what it is expected to find. But I don't know what could be missing
from the code generation on my side to sort that out.
The following minimal test that yields an ICE.
---
extern(C) int test = void;
I had set a breakpoint at hash_tree and looked at debug_tree output
from an equivalent program in C++, but nothing stands out as wrong
here to me.
Any insight would be helpful.
// D
DECL_NAME:
DECL_CONTEXT: (null_tree)
DECL_SIZE:
constant 32>
DECL_SIZE_UNIT:
constant 4>
VAR_DECL:
unit size
align 32 symtab 0 alias set 0 canonical type 0x765505e8
precision 32 min max
pointer_to_this >
used public static tls-initial-exec SI file test.d line 1 col 0
size unit size
align 32
(mem/c:SI (symbol_ref:DI ("test") [flags 0x2a] ) [0 test+0 S4 A32])>
// C++
DECL_NAME:
local bindings <(nil)>>
DECL_CONTEXT:
DECL_SIZE:
constant 32>
DECL_SIZE_UNIT:
constant 4>
VAR_DECL:
unit size
align 32 symtab 0 alias set 0 canonical type 0x7655a5e8
precision 32 min max
pointer_to_this >
public static SI file test2.cc line 2 col 5 size unit size
align 32 context
(mem/c:SI (symbol_ref:DI ("test") [flags 0x2] ) [0 test+0 S4 A32]) chain >
Re: LTO ICE in D Frontend
On 10 July 2014 07:31, Iain Buclaw wrote: > Hi, > > I'm trying to get to the bottom of a bug when using the D front-end with > -flto. > > When compiling anything, it always ICEs at in > streamer_get_pickled_tree, at tree-streamer-in.c. > > The of it appears to be that the LTO frontend seems to never retrieve > what it is expected to find. But I don't know what could be missing > from the code generation on my side to sort that out. > > > The following minimal test that yields an ICE. > --- > extern(C) int test = void; > In this example, the LTO expects to find an IDENTIFIER_NODE, but retrieves an ERROR_MARK. Regards Iain.
