Re: Thread Sanitizer and GCC GOMP (OpenMP)
Hi Jeffrey, On Tue, Feb 26, 2013 at 8:42 PM, Jeffrey Walton wrote: > Hi All, > > This came up on another list (Automake). I'm going to quote Bob > Friesenhahn directly since my paraphrase won't do him justice: > > "I am curious if this ThreadSanitizer extension will work with the > normal build of GCC GOMP (for OpenMP) on GNU/Linux. Up to now, it has > been necessary for interested parties to build their own GCC in order > to build a libgomp which uses pthreads rather than Linux clone for > threading. This is because valgrind only supports threads created via > pthreads and pthread locking semantics." > > Does Thread Sanitizer work for non-pthread or OpenMP environments? [1] > and [2] don't discuss limitations. ThreadSanitizer works for pthread-based synchronization and atomic compiler builtins (the latter, only in the code that is instrumented by tsan). If the code uses something else, it could be possible to support that to, but we will need minimized test cases. I suggest you to talk to us at thread-saniti...@googlegroups.com. > > Jeff > > [1] http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options > [2] http://code.google.com/p/data-race-test/wiki/ThreadSanitizer This link refers to the old Valgrind-based ThreadSanitizer, which we have abandoned. See code.google.com/p/thread-sanitizer/ for the new compiler-base tool. --kcc
GSOC this year?
Hi, will GCC be a mentoring organization for Google Summer of Code this year? Has somebody already volunteered to administer this? Torvald
Re: GSOC this year?
Hi, Torvald Riegel wrote: will GCC be a mentoring organization for Google Summer of Code this year? Well, the application of the organizations only starts in about three weeks* and which orgs will be participating is only announced on April 8. However, it is very likely that GCC will participate. Has somebody already volunteered to administer this? Are you volunteering to become the org admin? Diego has indicated that he won't do it this year … (If/as no one else does it, I offered to accept the chore.) Tobias * http://www.google-melange.com/gsoc/homepage/google/gsoc2013
Re: GSOC this year?
On Wed, Feb 27, 2013 at 6:48 AM, Torvald Riegel wrote: > will GCC be a mentoring organization for Google Summer of Code this > year? Has somebody already volunteered to administer this? I used to administer GCC's participation, but I will not be doing it this year. Tobias (CCd) said he might be able to administer it if nobody else volunteers. So far, I have not been able to find anyone who would. Diego.
The Linux binutils 2.23.52.0.1 is released
This is the beta release of binutils 2.23.52.0.1 for Linux, which is
based on binutils 2013 0226 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.23.52.0.1 release, when creating executables, BFD
linker will issue an error for undefined weak reference which is
defined in a shared library from DT_NEEDED. Previously BFD linker
will silently include the shared library from DT_NEEDED.
Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:
http://sourceware.org/bugzilla/show_bug.cgi?id=12343
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.23.52.0.1 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.23.51.0.9:
1. Update from binutils 2013 0226.
2. Add Intel SAMP new instruction support.
3. Allow dynamic R_386_SIZE32, R_X86_64_SIZE32 and R_X86_64_SIZE64
relocations agaist TLS symbols.
4. Fix BFD linker to set STB_GNU_UNIQUE only for definition. PR 15167.
5. Fix BFD linker to set STB_GNU_UNIQUE only if symbol is defined in
regular object. PR 15107.
6. Don't add DT_NEEDED for references from the LTO IR input. PR 15146.
7. When creating executables, BFD linker will issue an error for undefined
weak
Re: MIPS & register allocation question
"Steve Ellcey " writes:
> I was looking at MIPS register allocation and I noticed an odd thing.
> There is a definition of REG_ALLOC_ORDER in mips.h but in
> mips_order_regs_for_local_alloc (mips.c), we do not use this ordering,
> we just have:
>
> for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> reg_alloc_order[i] = i;
>
> I was wondering why we don't use something like ARM has.
> I.e.:
>
> const int mips_reg_alloc_order[] = REG_ALLOC_ORDER;
> memcpy(reg_alloc_order, mips_reg_alloc_order, sizeof (reg_alloc_order));
Yeah, it's one of those historical accidents. Chung-Lin did some good
archaeology on it:
http://gcc.gnu.org/ml/gcc/2011-01/msg00093.html
FWIW, after seeing that, I tried the patch below. Disabling
ADJUST_REG_ALLOC_ORDER seemed to be a very mixed bag sizewise though --
certainly not the consistent win that I hoped -- and I wasn't set up to
do proper speed testing. In the end I'm afraid I just let it drop.
Thanks,
Richard
Index: gcc/config/mips/mips-protos.h
===
--- gcc/config/mips/mips-protos.h 2011-09-17 10:18:14.0 +0100
+++ gcc/config/mips/mips-protos.h 2011-09-17 19:22:49.0 +0100
@@ -248,7 +248,6 @@ extern bool mips_expand_ext_as_unaligned
extern bool mips_expand_ins_as_unaligned_store (rtx, rtx, HOST_WIDE_INT,
HOST_WIDE_INT);
extern bool mips_mem_fits_mode_p (enum machine_mode mode, rtx x);
-extern void mips_order_regs_for_local_alloc (void);
extern HOST_WIDE_INT mips_debugger_offset (rtx, HOST_WIDE_INT);
extern void mips_push_asm_switch (struct mips_asm_switch *);
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c 2011-09-17 08:59:21.0 +0100
+++ gcc/config/mips/mips.c 2011-09-17 19:22:49.0 +0100
@@ -15900,28 +15900,6 @@ mips_expand_vector_init (rtx target, rtx
emit_move_insn (target, mem);
}
-/* When generating MIPS16 code, we want to allocate $24 (T_REG) before
- other registers for instructions for which it is possible. This
- encourages the compiler to use CMP in cases where an XOR would
- require some register shuffling. */
-
-void
-mips_order_regs_for_local_alloc (void)
-{
- int i;
-
- for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
-reg_alloc_order[i] = i;
-
- if (TARGET_MIPS16)
-{
- /* It really doesn't matter where we put register 0, since it is
- a fixed register anyhow. */
- reg_alloc_order[0] = 24;
- reg_alloc_order[24] = 0;
-}
-}
-
/* Implement EH_USES. */
bool
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h 2011-09-17 08:51:17.0 +0100
+++ gcc/config/mips/mips.h 2011-09-17 10:18:04.0 +0100
@@ -1930,9 +1930,18 @@ #define REG_ALLOC_ORDER
\
of the extra accumulators available with -mdspr2. In some cases, \
it can also help to reduce register pressure. */ \
64, 65,176,177,178,179,180,181, \
- /* Call-clobbered GPRs. */ \
- 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, \
- 24, 25, 31, \
+ /* Call-clobbered GPRs. Put $24 first, because when M16_REGS and\
+ T_REG have equal cost, we prefer to use T_REG. In particular,\
+ it means that CMP+branch sequences will generally be preferred\
+ to XOR+branch sequences; the former are shorter, and using T_REG \
+ reduces the register pressure on the main MIPS16 registers. \
+ This does not seem to adversely affect non-MIPS16 code. \
+ \
+ Normally we'd keep register pairs together, but in this case, \
+ it's better not to. $25 is not a MIPS16 register, and in \
+ abicalls code, we'd prefer to leave it free for its ABI use. */ \
+ 24, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, \
+ 25, 1, 31, \
/* The global pointer. This is call-clobbered for o32 and o64 \
abicalls, call-saved for n32 and n64 abicalls, and a program \
invariant otherwise. Putting it between the call-clobbered \
@@ -1964,13 +1973,6 @@ #define REG_ALLOC_ORDER
\
182,183,184,185,186,187 \
}
-/* ADJUST_REG_ALLOC_ORDER is a macro which permits reg_alloc_order
- to be rearranged based on a particular function. On the mips16, we
- want to allocate $24 (T_REG) before other registers for
- instructions for which it is possible. */
-
-#define ADJUST_REG_ALLOC_ORDER mi
svn returning Access Denied
I've been doing some research and using your SVN repository. I have limited myself to just performing 'svn log' and 'svn ls' requests. However, as of late, I am no longer able to to perform this function from a server located at Wichita State University with an IP address of 156.26.10.10 (hostname is penang.cs.wichita.edu). Has this IP address been blocked? If so, I was not aware of any behavior that would take this course of action so is it possible to regain access? Thanks, Joe Shobe Grad Student - Computer Science
Re: MIPS & register allocation question
On Wed, 2013-02-27 at 22:28 +, Richard Sandiford wrote: > FWIW, after seeing that, I tried the patch below. Disabling > ADJUST_REG_ALLOC_ORDER seemed to be a very mixed bag sizewise though -- > certainly not the consistent win that I hoped -- and I wasn't set up to > do proper speed testing. In the end I'm afraid I just let it drop. > > Thanks, > Richard I'll try your patch on some of my benchmarks and see what happens. One interesting thing I have noticed (sizewise) is that not using t0-t7 at all in MIPS16 code resulted in a code size reduction of around 1%. Steve Ellcey
Re: svn returning Access Denied
On Wed, Feb 27, 2013 at 3:35 PM, Joseph F Shobe wrote: > I've been doing some research and using your SVN repository. I have limited > myself to just performing 'svn log' and 'svn ls' requests. > > However, as of late, I am no longer able to to perform this function from a > server located at Wichita State University with an IP address of 156.26.10.10 > (hostname is penang.cs.wichita.edu). Has this IP address been blocked? If > so, I was not aware of any behavior that would take this course of action so > is it possible to regain access? Please do not send e-mail to both gcc-h...@gcc.gnu.org and gcc@gcc.gnu.org. Pick one or the other. Thanks. As far as I can tell your IP address has not been blocked at gcc.gnu.org. However, it is possible that I missed something. I've CC'ed overseers for more information. In general gcc.gnu.org is used by hundreds of developers and the machine is often overloaded. If you hit it with a lot of connections, you are likely to be blocked. Don't do that. E.g., wait at least one minute between connections. Thanks. Ian
