avoiding extra .loc directives

2013-11-05 Thread shmeel gutl 
For my VLIW toolchain, I am not allowed to output .loc directives in the 
middle of a VLIW bundle. Following the lead of the bfin backend, I scan 
bundles during the machine reorg pass and ensure that all of the insns 
of a bundle have the same location. This solves most of the problems, 
but final.c will also output the .loc directive after encountering a 
NOTE_INSN_PROLOGUE_END. There are two obvious solutions to this:

1) eliminate the note in machine reorg.
2) eliminate the line "force_source_line = true;" from the appropriate 
line in final.c.


Would either of these alternatives cause a problem?
Is there a better way to avoid having .loc directives inside bundles?

Re: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Tom de Vries 
On 05/11/13 05:17, Iyer, Balaji V wrote:
> Is the following patch OK to fix this issue? 
> 

Balaji,

the patch fixes the problem for me, thanks.

I can't approve your patch, but it looks good to me.

FWIW, I stumbled upon this text at http://gcc.gnu.org/codingconventions.html
which is related to this patch, and also to the top-level part of your commit
r204173, which is missing at 'src':
...
Top-level configure.ac, configure, Makefile.in, config-ml.in, config.if and most
other top-level shell-scripts: Please try to keep these files in sync with the
corresponding files in the src repository at sourceware.org. Some people hope to
eventually merge these trees into a single repository; keeping them in sync
helps this goal. When you check in a patch to one of these files, please check
it in the src tree too, or ask someone else with write access there to do so.
...

Thanks,
- Tom

> Thanks,
> 
> Balaji V. Iyer.
> 
> Index: configure.ac
> ===
> --- configure.ac(revision 204381)
> +++ configure.ac(working copy)
> @@ -2061,7 +2061,7 @@
>  case ,${enable_languages}, in
>*,c++,*) ;;
>*)
> -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
> target-libvtv"
> +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
> target-libsanitizer target-libvtv"
>  ;;
>  esac
> 
> Index: ChangeLog
> ===
> --- ChangeLog   (revision 204381)
> +++ ChangeLog   (working copy)
> @@ -1,3 +1,9 @@
> +2013-11-04  Balaji V. Iyer  
> +
> +   * configure.ac: Added libcilkrts to noconfig list when C++ is not
> +   supported.
> +   * configure: Regenerated.
> +
>  2013-11-01  Trevor Saunders  
> 
>  * MAINTAINERS (Write After Approval): Add myself.
> Index: configure
> ===
> --- configure   (revision 204381)
> +++ configure   (working copy)
> @@ -6630,7 +6630,7 @@
>  case ,${enable_languages}, in
>*,c++,*) ;;
>*)
> -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
> target-libvtv"
> +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
> target-libsanitizer target-libvtv"
>  ;;
>  esac

RE: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Gopalasubramanian, Ganesh 
My non-bootstrap build fails with the following message

/bin/bash: ./libtool: No such file or directory
make: *** [cilk-abi-vla.lo] Error 127

I have my libtool installed in /usr/bin.

I configured the build with 
configure --prefix=../dailybuild/usr/Nov_05_2013 
--enable-languages=c,c++,fortran --disable-bootstrap

Am I missing something?

Regards
Ganesh

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Iyer, 
Balaji V
Sent: Tuesday, November 05, 2013 9:47 AM
To: Tom de Vries; gcc@gcc.gnu.org
Subject: [PATCH] RE: libcilkrts breaks non-bootstrap build



> -Original Message-
> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> Sent: Monday, November 4, 2013 2:15 PM
> To: gcc@gcc.gnu.org
> Cc: Iyer, Balaji V
> Subject: libcilkrts breaks non-bootstrap build
> 
> Hi,
> 
> When configuring a gcc build with "--disable-bootstrap --enable- 
> languages=c" I run into this error:
> ...
> libtool: compile:  g++
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/bin/
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/lib/
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/include
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/sys-include
> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
> -DPACKAGE_TARNAME=\"cilk-runtime-library\" - DPACKAGE_VERSION=\"2.0\"
> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
> DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. - 
> I/home/vries/gcc_versions/devel/src/libcilkrts
> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for - 
> fcilkplus -g3
> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c 
> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC 
> -DPIC - o .libs/bug.o
> g++: error: unrecognized command line option '-fcilkplus'
> make[2]: *** [bug.lo] Error 1
> make[2]: Leaving directory
> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
> gnu/libcilkrts'
> ...
> 
> The error occurs because the compiler doesn't support -fcilkplus.
> 
> Should configure disable libcilkplus when c++ is not enabled?
> 

Is the following patch OK to fix this issue? 

Thanks,

Balaji V. Iyer.

Index: configure.ac
===
--- configure.ac(revision 204381)
+++ configure.ac(working copy)
@@ -2061,7 +2061,7 @@
 case ,${enable_languages}, in
   *,c++,*) ;;
   *)
-noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
target-libvtv"
+noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
target-libsanitizer target-libvtv"
 ;;
 esac

Index: ChangeLog
===
--- ChangeLog   (revision 204381)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2013-11-04  Balaji V. Iyer  
+
+   * configure.ac: Added libcilkrts to noconfig list when C++ is not
+   supported.
+   * configure: Regenerated.
+
 2013-11-01  Trevor Saunders  

 * MAINTAINERS (Write After Approval): Add myself.
Index: configure
===
--- configure   (revision 204381)
+++ configure   (working copy)
@@ -6630,7 +6630,7 @@
 case ,${enable_languages}, in
   *,c++,*) ;;
   *)
-noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
target-libvtv"
+noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
target-libsanitizer target-libvtv"
 ;;
 esac

Re: Report on the bounded pointers work

2013-11-05 Thread Yury Gribov 

> If you're referring to mudflap (Frank Eigler's work),
> ...
> It never reached a point where interoperability across objects with 
and without mudflap instrumentation worked


Jeff,

Could you add more details? E.g. I don't see how mudflap 
interoperability is different from AdressSanitizer which seems to be 
state of the art.


-Y

Re: Report on the bounded pointers work

2013-11-05 Thread Florian Weimer 

On 11/04/2013 05:43 PM, Joseph S. Myers wrote:

On Mon, 4 Nov 2013, Jeff Law wrote:


You might also be referring to Greg McGary's work on bounded pointers, I don't
think that ever got integrated or if it did, it got pulled long ago.


It was integrated in 2000, removed in 2002/2003 (I removed the relics from
glibc earlier this year).  By using fat pointers, it required the entire
program including all libraries it used to be built with bounded pointers
enabled (and associated changes to all assembly sources to handle them).


Yes, I was referring to Greg's work.  I'm wondering if the trade-offs 
have changed since then, considering that it's again en vogue to 
bootstrap new architectures.  It's difficult to tell without more 
details about that past effort, though.


--
Florian Weimer / Red Hat Product Security Team

Re: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Tom de Vries 
On 05/11/13 10:37, Gopalasubramanian, Ganesh wrote:
> My non-bootstrap build fails with the following message
> 
> /bin/bash: ./libtool: No such file or directory
> make: *** [cilk-abi-vla.lo] Error 127
> 
> I have my libtool installed in /usr/bin.
> 
> I configured the build with 
> configure --prefix=../dailybuild/usr/Nov_05_2013 
> --enable-languages=c,c++,fortran --disable-bootstrap
> 
> Am I missing something?

Ganesh,

I've just completed a build of r204382 with the same configure flags. I can't
reproduce that failure.

What is not clear from your message, is whether indeed ./libtool is missing, or
it can't be found while it's present.

If ./libtool is not present, it's supposed to be generated by configure.status,
so check your configure.log, perhaps there's a related error there?

Thanks,
- Tom

Re: Something wrong with bootstrap-lto, or lto itself:

2013-11-05 Thread Richard Biener 
On Tue, Nov 5, 2013 at 6:42 AM, Trevor Saunders  wrote:
> On Mon, Nov 04, 2013 at 01:29:10PM +0100, Richard Biener wrote:
>> On Wed, Oct 30, 2013 at 8:17 PM, Toon Moene  wrote:
>> > Consider this:
>> >
>> > http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02329.html
>> >
>> > and
>> >
>> > http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02258.html
>> >
>> > /scratch/toon/bd5894/./prev-gcc/xg++ -B/scratch/toon/bd5894/./prev-gcc/
>> > -B/home/toon/compilers/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
>> > -B/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
>> > -B/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
>> > -I/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
>> > -I/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
>> > -I/home/toon/compilers/gcc/libstdc++-v3/libsupc++
>> > -L/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
>> > -L/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
>> > -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC-fno-exceptions 
>> > -fno-rtti
>> > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
>> > -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
>> > -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
>> > -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1plus \
>> >   cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o
>> > cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o
>> > cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o
>> > cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o
>> > cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o
>> > cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o
>> > cp/cp-array-notation.o cp/lambda.o cp/vtable-class-hierarchy.o attribs.o
>> > incpath.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
>> > c-family/array-notation-common.o c-family/c-ubsan.o i386-c.o glibc-c.o
>> > cc1plus-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   ../libbacktrace/.libs/libbacktrace.a
>> > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lcloog-isl -lisl
>> > -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
>> > In function 'release',
>> > inlined from '_ZN7va_heap7reserveIbEEvRP3vecIT_S_8vl_embedEjb.part.95'
>> > at /home/toon/compilers/gcc/gcc/vec.h:288:7,
>> > inlined from 'reserve',
>> > inlined from '_ZN3vecIb7va_heap6vl_ptrE7reserveEjb.part.96' at
>> > /home/toon/compilers/gcc/gcc/vec.h:1367:3,
>> > inlined from 'reserve.constprop',
>> > inlined from 'reserve_exact' at
>> > /home/toon/compilers/gcc/gcc/vec.h:1387:45,
>> > inlined from 'safe_grow' at /home/toon/compilers/gcc/gcc/vec.h:1515:3,
>> > inlined from 'safe_grow_cleared' at
>> > /home/toon/compilers/gcc/gcc/vec.h:1529:3,
>> > inlined from 'vect_bb_vectorization_profitable_p' at
>> > /home/toon/compilers/gcc/gcc/tree-vect-slp.c:2027:0,
>> > inlined from 'vect_slp_analyze_bb_1' at
>> > /home/toon/compilers/gcc/gcc/tree-vect-slp.c:2174:55,
>> > inlined from 'vect_slp_analyze_bb' at
>> > /home/toon/compilers/gcc/gcc/tree-vect-slp.c:2229:44:
>> > /home/toon/compilers/gcc/gcc/vec.h:316:3: error: attempt to free a non-heap
>> > object 'life' [-Werror=free-nonheap-object]
>> >::free (v);
>> >^
>> > lto1: all warnings being treated as errors
>>
>> Obviously fallout of the stack-vector rewrite.
>>
>>   stack_vec life;
>>   life.safe_grow_cleared (SLP_INSTANCE_GROUP_SIZE (instance));
>>
>> doesn't make much sense anyway ...  why is the initial size only
>> allowed as a template parameter?  But then safe_grow shouldn't free
>> the stack storage.
>
> So, I'm still confused how exactly this happens, presumably we must be
> trying to reserve a vector of length zero and consequently hit that code
> in va_heap::reserve to free the vector if we're supposed to reserve 0
> elements, but that doesn't make sense because the first check in
> vec::reserve should have failed if that was the case.  Unfortunately I
> have no clue how to get dumps for optimization happening during lto or
> otherwise debug the compiler during lto.

The backtrace suggests that the error may be from expanding code
that is dead at runtime but was not detected as so.  IPA-CP likely
propagated the storage object and partial inlining obfuscated the code
enough to hide the fact that it is dead ...

> However I think I've convinced myself this code to have
> vec_prefix::calculate_a

Re: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Richard Biener 
On Tue, Nov 5, 2013 at 5:17 AM, Iyer, Balaji V  wrote:
>
>
>> -Original Message-
>> From: Tom de Vries [mailto:tom_devr...@mentor.com]
>> Sent: Monday, November 4, 2013 2:15 PM
>> To: gcc@gcc.gnu.org
>> Cc: Iyer, Balaji V
>> Subject: libcilkrts breaks non-bootstrap build
>>
>> Hi,
>>
>> When configuring a gcc build with "--disable-bootstrap --enable-
>> languages=c" I run into this error:
>> ...
>> libtool: compile:  g++
>> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
>> gnu/bin/
>> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
>> gnu/lib/
>> -isystem
>> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
>> gnu/include
>> -isystem
>> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
>> gnu/sys-include
>> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
>> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -
>> DPACKAGE_VERSION=\"2.0\"
>> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
>> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
>> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
>> DHAVE_STRING_H=1
>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
>> DHAVE_STDINT_H=1
>> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
>> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -
>> I/home/vries/gcc_versions/devel/src/libcilkrts
>> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
>> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
>> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
>> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for -
>> fcilkplus -g3
>> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c
>> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC -DPIC -
>> o .libs/bug.o
>> g++: error: unrecognized command line option '-fcilkplus'
>> make[2]: *** [bug.lo] Error 1
>> make[2]: Leaving directory
>> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
>> gnu/libcilkrts'
>> ...
>>
>> The error occurs because the compiler doesn't support -fcilkplus.
>>
>> Should configure disable libcilkplus when c++ is not enabled?
>>
>
> Is the following patch OK to fix this issue?

Ok.

Thanks,
Richard.

> Thanks,
>
> Balaji V. Iyer.
>
> Index: configure.ac
> ===
> --- configure.ac(revision 204381)
> +++ configure.ac(working copy)
> @@ -2061,7 +2061,7 @@
>  case ,${enable_languages}, in
>*,c++,*) ;;
>*)
> -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
> target-libvtv"
> +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
> target-libsanitizer target-libvtv"
>  ;;
>  esac
>
> Index: ChangeLog
> ===
> --- ChangeLog   (revision 204381)
> +++ ChangeLog   (working copy)
> @@ -1,3 +1,9 @@
> +2013-11-04  Balaji V. Iyer  
> +
> +   * configure.ac: Added libcilkrts to noconfig list when C++ is not
> +   supported.
> +   * configure: Regenerated.
> +
>  2013-11-01  Trevor Saunders  
>
>  * MAINTAINERS (Write After Approval): Add myself.
> Index: configure
> ===
> --- configure   (revision 204381)
> +++ configure   (working copy)
> @@ -6630,7 +6630,7 @@
>  case ,${enable_languages}, in
>*,c++,*) ;;
>*)
> -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
> target-libvtv"
> +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
> target-libsanitizer target-libvtv"
>  ;;
>  esac
>

[C++] Optimizing dynamic_cast to a final C++ class

2013-11-05 Thread Florian Weimer 
I've looked at optimizing dynamic_cast to final C++ class.  In theory, 
it should be possible to load the vtable pointer, compare it to the 
expected value, and use the original pointer if it matches, or NULL 
otherwise (for pointers, references are similar but need the conditional 
throw).


But I remember a discussion on the cxxabi list that vtables are not 
deduplicated if they are contained in multiple libraries, so a simple 
pointer comparison won't do.  Is there anything else that could be used 
as a reliable marker?  If not, do you think it would be feasible to add 
a fast-path for final target classes to the __dynamic_cast implementation?


--
Florian Weimer / Red Hat Product Security Team

Re: [C++] Optimizing dynamic_cast to a final C++ class

2013-11-05 Thread Paolo Carlini 

On 11/05/2013 01:36 PM, Florian Weimer wrote:
I've looked at optimizing dynamic_cast to final C++ class.  In theory, 
it should be possible to load the vtable pointer, compare it to the 
expected value, and use the original pointer if it matches, or NULL 
otherwise (for pointers, references are similar but need the 
conditional throw).


But I remember a discussion on the cxxabi list that vtables are not 
deduplicated if they are contained in multiple libraries, so a simple 
pointer comparison won't do.  Is there anything else that could be 
used as a reliable marker?  If not, do you think it would be feasible 
to add a fast-path for final target classes to the __dynamic_cast 
implementation?
Just wanted to say that if you are going to work in this are you could 
consider also adding the warning per c++/12277 (/38557), which seems 
nice to have.


Paolo.

Re: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Joseph S. Myers 
On Tue, 5 Nov 2013, Tom de Vries wrote:

> FWIW, I stumbled upon this text at http://gcc.gnu.org/codingconventions.html
> which is related to this patch, and also to the top-level part of your commit
> r204173, which is missing at 'src':

Note there are now *three* repositories to keep in sync - GCC, src CVS and 
binutils-gdb git.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Something wrong with bootstrap-lto, or lto itself:

2013-11-05 Thread Trevor Saunders 
On Tue, Nov 05, 2013 at 12:56:39PM +0100, Richard Biener wrote:
> On Tue, Nov 5, 2013 at 6:42 AM, Trevor Saunders  wrote:
> > On Mon, Nov 04, 2013 at 01:29:10PM +0100, Richard Biener wrote:
> >> On Wed, Oct 30, 2013 at 8:17 PM, Toon Moene  wrote:
> >> > Consider this:
> >> >
> >> > http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02329.html
> >> >
> >> > and
> >> >
> >> > http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02258.html
> >> >
> >> > /scratch/toon/bd5894/./prev-gcc/xg++ -B/scratch/toon/bd5894/./prev-gcc/
> >> > -B/home/toon/compilers/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
> >> > -B/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
> >> > -B/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
> >> > -I/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
> >> > -I/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
> >> > -I/home/toon/compilers/gcc/libstdc++-v3/libsupc++
> >> > -L/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
> >> > -L/scratch/toon/bd5894/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
> >> > -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC-fno-exceptions 
> >> > -fno-rtti
> >> > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> >> > -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
> >> > -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
> >> > -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1plus \
> >> >   cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o
> >> > cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o
> >> > cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o
> >> > cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o
> >> > cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o
> >> > cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o
> >> > cp/cp-array-notation.o cp/lambda.o cp/vtable-class-hierarchy.o attribs.o
> >> > incpath.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
> >> > c-family/array-notation-common.o c-family/c-ubsan.o i386-c.o glibc-c.o
> >> > cc1plus-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   ../libbacktrace/.libs/libbacktrace.a
> >> > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lcloog-isl 
> >> > -lisl
> >> > -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
> >> > In function 'release',
> >> > inlined from 
> >> > '_ZN7va_heap7reserveIbEEvRP3vecIT_S_8vl_embedEjb.part.95'
> >> > at /home/toon/compilers/gcc/gcc/vec.h:288:7,
> >> > inlined from 'reserve',
> >> > inlined from '_ZN3vecIb7va_heap6vl_ptrE7reserveEjb.part.96' at
> >> > /home/toon/compilers/gcc/gcc/vec.h:1367:3,
> >> > inlined from 'reserve.constprop',
> >> > inlined from 'reserve_exact' at
> >> > /home/toon/compilers/gcc/gcc/vec.h:1387:45,
> >> > inlined from 'safe_grow' at 
> >> > /home/toon/compilers/gcc/gcc/vec.h:1515:3,
> >> > inlined from 'safe_grow_cleared' at
> >> > /home/toon/compilers/gcc/gcc/vec.h:1529:3,
> >> > inlined from 'vect_bb_vectorization_profitable_p' at
> >> > /home/toon/compilers/gcc/gcc/tree-vect-slp.c:2027:0,
> >> > inlined from 'vect_slp_analyze_bb_1' at
> >> > /home/toon/compilers/gcc/gcc/tree-vect-slp.c:2174:55,
> >> > inlined from 'vect_slp_analyze_bb' at
> >> > /home/toon/compilers/gcc/gcc/tree-vect-slp.c:2229:44:
> >> > /home/toon/compilers/gcc/gcc/vec.h:316:3: error: attempt to free a 
> >> > non-heap
> >> > object 'life' [-Werror=free-nonheap-object]
> >> >::free (v);
> >> >^
> >> > lto1: all warnings being treated as errors
> >>
> >> Obviously fallout of the stack-vector rewrite.
> >>
> >>   stack_vec life;
> >>   life.safe_grow_cleared (SLP_INSTANCE_GROUP_SIZE (instance));
> >>
> >> doesn't make much sense anyway ...  why is the initial size only
> >> allowed as a template parameter?  But then safe_grow shouldn't free
> >> the stack storage.
> >
> > So, I'm still confused how exactly this happens, presumably we must be
> > trying to reserve a vector of length zero and consequently hit that code
> > in va_heap::reserve to free the vector if we're supposed to reserve 0
> > elements, but that doesn't make sense because the first check in
> > vec::reserve should have failed if that was the case.  Unfortunately I
> > have no clue how to get dumps for optimization happening during lto or
> > otherwise debug the compiler during lto.
> 
> The backtrace suggests that the error may be from expan

RE: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Iyer, Balaji V 


> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, November 5, 2013 7:08 AM
> To: Iyer, Balaji V
> Cc: Tom de Vries; gcc@gcc.gnu.org
> Subject: Re: [PATCH] RE: libcilkrts breaks non-bootstrap build
> 
> On Tue, Nov 5, 2013 at 5:17 AM, Iyer, Balaji V 
> wrote:
> >
> >
> >> -Original Message-
> >> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> >> Sent: Monday, November 4, 2013 2:15 PM
> >> To: gcc@gcc.gnu.org
> >> Cc: Iyer, Balaji V
> >> Subject: libcilkrts breaks non-bootstrap build
> >>
> >> Hi,
> >>
> >> When configuring a gcc build with "--disable-bootstrap --enable-
> >> languages=c" I run into this error:
> >> ...
> >> libtool: compile:  g++
> >> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/bin/
> >> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/lib/
> >> -isystem
> >> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/include
> >> -isystem
> >> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/sys-include
> >> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
> >> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -
> DPACKAGE_VERSION=\"2.0\"
> >> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
> >> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> >> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -
> DSTDC_HEADERS=1
> >> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
> >> DHAVE_STRING_H=1
> >> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> >> DHAVE_STDINT_H=1
> >> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
> >> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -
> >> I/home/vries/gcc_versions/devel/src/libcilkrts
> >> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
> >> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
> >> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
> >> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for -
> >> fcilkplus -g3
> >> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c
> >> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC
> >> -DPIC - o .libs/bug.o
> >> g++: error: unrecognized command line option '-fcilkplus'
> >> make[2]: *** [bug.lo] Error 1
> >> make[2]: Leaving directory
> >> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
> >> gnu/libcilkrts'
> >> ...
> >>
> >> The error occurs because the compiler doesn't support -fcilkplus.
> >>
> >> Should configure disable libcilkplus when c++ is not enabled?
> >>
> >
> > Is the following patch OK to fix this issue?
> 
> Ok.
> 
> Thanks,
> Richard.
> 

Committed as revision 204396.

Thanks,

Balaji V. Iyer.



> > Thanks,
> >
> > Balaji V. Iyer.
> >
> > Index: configure.ac
> >
> ==
> =
> > --- configure.ac(revision 204381)
> > +++ configure.ac(working copy)
> > @@ -2061,7 +2061,7 @@
> >  case ,${enable_languages}, in
> >*,c++,*) ;;
> >*)
> > -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer target-
> libvtv"
> > +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm target-
> libsanitizer target-libvtv"
> >  ;;
> >  esac
> >
> > Index: ChangeLog
> >
> ==
> =
> > --- ChangeLog   (revision 204381)
> > +++ ChangeLog   (working copy)
> > @@ -1,3 +1,9 @@
> > +2013-11-04  Balaji V. Iyer  
> > +
> > +   * configure.ac: Added libcilkrts to noconfig list when C++ is not
> > +   supported.
> > +   * configure: Regenerated.
> > +
> >  2013-11-01  Trevor Saunders  
> >
> >  * MAINTAINERS (Write After Approval): Add myself.
> > Index: configure
> >
> ==
> =
> > --- configure   (revision 204381)
> > +++ configure   (working copy)
> > @@ -6630,7 +6630,7 @@
> >  case ,${enable_languages}, in
> >*,c++,*) ;;
> >*)
> > -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer target-
> libvtv"
> > +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm target-
> libsanitizer target-libvtv"
> >  ;;
> >  esac
> >

Bootstrap issues in libsanitizer

2013-11-05 Thread Iyer, Balaji V 
Hello Everyone,
I am getting this weird bootstrap error in my SUSE machine with 
libsanitizer that didn't occur ~1.5 days ago. Is anyone else seeing this?

libtool: compile:  /export/users/gcc-svn/b-trunk-gcc/./gcc/xgcc -shared-libgcc 
-B/export/users/gcc-svn/b-trunk-gcc/./gcc -nostdinc++ 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 
-B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/bin/ 
-B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/lib/ 
-isystem 
/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/include
 -isystem 
/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/sys-include
 -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I. -I../../../../trunk-gcc/libsanitizer/sanitizer_common 
-I ../../../../trunk-gcc/libsanitizer/include -Wall -W -Wno-unused-parameter 
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions 
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros 
-I../../libstdc++-v3/include 
-I../../libstdc++-v3/include/x86_64-unknown-linux-gnu 
-I../../../../trunk-gcc/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 
-D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF 
.deps/sanitizer_platform_limits_posix.Tpo -c 
../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
  -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
In file included from /usr/include/sys/vt.h:1:0,
 from 
../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:49:
/usr/include/linux/vt.h:74:15: error: expected unqualified-id before ânewâ
  unsigned int new;  /* New console (if changing) */
   ^

configured with: ../trunk-gcc/configure 
--prefix=/export/users/gcc-svn/install_dir/trunk-install

Thanks,

Balaji V. Iyer.

Re: Bootstrap issues in libsanitizer

2013-11-05 Thread Jonathan Wakely 
On 5 November 2013 15:27, Iyer, Balaji V wrote:
> In file included from /usr/include/sys/vt.h:1:0,
>  from 
> ../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:49:
> /usr/include/linux/vt.h:74:15: error: expected unqualified-id before ânewâ
>   unsigned int new;  /* New console (if changing) */
>^

'new' is a keyword in C++, so your linux/vt.h header is not usable in C++ files.

This is not a problem in libsanitizer.  Have you recently updated a
kernel-headers package on your machine?

Re: Bootstrap issues in libsanitizer

2013-11-05 Thread Jonathan Wakely 
On 5 November 2013 15:32, Jonathan Wakely wrote:
> On 5 November 2013 15:27, Iyer, Balaji V wrote:
>> In file included from /usr/include/sys/vt.h:1:0,
>>  from 
>> ../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:49:
>> /usr/include/linux/vt.h:74:15: error: expected unqualified-id before ânewâ
>>   unsigned int new;  /* New console (if changing) */
>>^
>
> 'new' is a keyword in C++, so your linux/vt.h header is not usable in C++ 
> files.
>
> This is not a problem in libsanitizer.  Have you recently updated a
> kernel-headers package on your machine?

With kernel 3.11.6 I see that field is called newev, so it looks as
though newer kernels fix the problem.

Maybe libsanitizer needs to do some ugly dance around that header:

#define new renamed_new
#include 
#undef new

Re: Bootstrap issues in libsanitizer

2013-11-05 Thread Jonathan Wakely 
On 5 November 2013 15:38, Jonathan Wakely wrote:
> On 5 November 2013 15:32, Jonathan Wakely wrote:
>> On 5 November 2013 15:27, Iyer, Balaji V wrote:
>>> In file included from /usr/include/sys/vt.h:1:0,
>>>  from 
>>> ../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:49:
>>> /usr/include/linux/vt.h:74:15: error: expected unqualified-id before ânewâ
>>>   unsigned int new;  /* New console (if changing) */
>>>^
>>
>> 'new' is a keyword in C++, so your linux/vt.h header is not usable in C++ 
>> files.
>>
>> This is not a problem in libsanitizer.  Have you recently updated a
>> kernel-headers package on your machine?
>
> With kernel 3.11.6 I see that field is called newev, so it looks as
> though newer kernels fix the problem.

http://lkml.indiana.edu/hypermail/linux/kernel/0911.2/01720.html
implies the "new" field never made it into an actual release, so it
might be a problem for SuSE kernels only.

Re: Report on the bounded pointers work

2013-11-05 Thread Jeff Law 

On 11/05/13 03:35, Florian Weimer wrote:

On 11/04/2013 05:43 PM, Joseph S. Myers wrote:

On Mon, 4 Nov 2013, Jeff Law wrote:


You might also be referring to Greg McGary's work on bounded
pointers, I don't
think that ever got integrated or if it did, it got pulled long ago.


It was integrated in 2000, removed in 2002/2003 (I removed the relics
from
glibc earlier this year).  By using fat pointers, it required the entire
program including all libraries it used to be built with bounded pointers
enabled (and associated changes to all assembly sources to handle them).


Yes, I was referring to Greg's work.  I'm wondering if the trade-offs
have changed since then, considering that it's again en vogue to
bootstrap new architectures.  It's difficult to tell without more
details about that past effort, though.
Not really, IMHO.  If anything as software complexity continues to 
increase (specifically pulling in more and more libraries from various 
sources), the problem of mixing instrumented and uninstrumented code has 
actually gotten worse.


jeff

Re: Report on the bounded pointers work

2013-11-05 Thread Ondřej Bílka 
On Tue, Nov 05, 2013 at 08:55:21AM -0700, Jeff Law wrote:
> On 11/05/13 03:35, Florian Weimer wrote:
> >On 11/04/2013 05:43 PM, Joseph S. Myers wrote:
> >>On Mon, 4 Nov 2013, Jeff Law wrote:
> >>
> >>>You might also be referring to Greg McGary's work on bounded
> >>>pointers, I don't
> >>>think that ever got integrated or if it did, it got pulled long ago.
> >>
> >>It was integrated in 2000, removed in 2002/2003 (I removed the relics
> >>from
> >>glibc earlier this year).  By using fat pointers, it required the entire
> >>program including all libraries it used to be built with bounded pointers
> >>enabled (and associated changes to all assembly sources to handle them).
> >
> >Yes, I was referring to Greg's work.  I'm wondering if the trade-offs
> >have changed since then, considering that it's again en vogue to
> >bootstrap new architectures.  It's difficult to tell without more
> >details about that past effort, though.
> Not really, IMHO.  If anything as software complexity continues to
> increase (specifically pulling in more and more libraries from
> various sources), the problem of mixing instrumented and
> uninstrumented code has actually gotten worse.
> 
Also it is doing useless work, allocator already knows bounds so all you
need to do is ask.

A query can be made O(1) with bit of work, I attached a proof of concept
allocator that checks memcpy where queries are unoptimized O(n).

As it is this will not get bounds on static and stack allocations. For
static allocations you could extract bounds by reading debug information
as gdb does.

For stack allocations it takes more work, it could be done by
compiler/compiler plugin/custom frontend inserting bound_add (from, to)
and bound_remove (from, to) calls for each stack variable that escaped.

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define log(...) fprintf (stderr, __VA_ARGS__)

#ifndef TRACE
# define TRACE 4
#endif

typedef struct left_sentinel
{
  void *origin[TRACE];
  uint64_t res2;
  uint64_t iteration;
  struct left_sentinel *previous, *next;
  uint64_t size;
  uint64_t sentinel;
} left_sentinel;

#define ALIGN_UP(x, no) uintptr_t) x) + no - 1) - (((uintptr_t) x) + no - 
1) % no)
#define SENTINEL5877815476798078077UL
#define BIG_SENTINEL1204925723299285449UL
#define DOUBLE_FREE 10943064412161398437UL

static pthread_mutex_t mutex;
static int inited;
size_t page_size;
static void
init ()
{
  page_size = sysconf (_SC_PAGE_SIZE);
  pthread_mutex_init (&mutex, NULL);
  inited = 1;
}
static void verify_sentinel ();

void *
malloc (size_t len)
{
  void *ptr;
  posix_memalign (&ptr, 16, len);
  return ptr;
}
void *
calloc (size_t nmemb, size_t size)
{
  if (!nmemb | !size)
return NULL;

  if (SIZE_MAX / nmemb < size)
{
  log ("allocation overflow in calloc(%i, %i)\n", nmemb, size);
  abort ();
}
  void *ptr = malloc (nmemb * size);
  if (ptr != NULL)
memset (ptr, 0, nmemb * size);
  return ptr;
}

void *
valloc (size_t size)
{
  void *ret;
  posix_memalign (&ret, page_size, size);
  return ret;
}
void *
pvalloc (size_t size)
{
  void *ret;
  posix_memalign (&ret, page_size, size);
  return ret;
}
void *
memalign (size_t alignment, size_t size)
{
  void *ret;
  posix_memalign (&ret, alignment, size);
  return ret;
}
void *
realloc (void *ptr, size_t size)
{
  if (!ptr)
return malloc (size);

  left_sentinel *cur = (left_sentinel *) (((char *) ptr) - sizeof 
(left_sentinel));

  verify_sentinel (cur);

  size_t old_size = cur->size;  

  if (old_size > size)
return ptr;

  char *new = malloc (size);
  if (!new)
return NULL;

  memcpy (new, ptr, old_size);
  free (ptr);
  return new;
}

static char *
wrap_mmap (size_t size)
{
  char *ret = mmap (NULL, ALIGN_UP (size, page_size) + 2 * page_size,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (!ret)
abort;
  munmap (ret, page_size);
  munmap (ret + page_size + ALIGN_UP (size, page_size), page_size);
  return ret + page_size;
}

static void **bucket[64];

static void
return_bucket (char *ptr, size_t size)
{
  int pow;
  for (pow = 0; 1UL << pow < size; pow++)
;
  char *old = (char *) bucket[pow];
  bucket[pow] = (void **) ptr;
  *bucket[pow] = old;
}


static void
add_bucket (size_t size)
{
  int i, pow;
  for (pow = 0; 1UL << pow < size; pow++)
;
  if (1UL << pow >= page_size)
{ /* tighter checks.  */
  char *ptr = wrap_mmap ((1UL << pow));
  return_bucket (ptr, size);
}
  else
{
  char *ptr = wrap_mmap (page_size);
  for (i = 0; i < page_size; i += 1UL << pow)
{
  return_bucket (ptr + i, size);
}
}
}

static void *
get_bucket (size_t size)
{
  int pow;
  for (pow = 0; 1UL << pow < size; pow++)
;
  if (!bucket[pow])
add_bucket (size);
  void **ret = bucket[pow];
  bucket[pow] = *ret;
  return (void *) ret;
}

static left_sentinel *previous = NULL;

int
posix_memalign (v

Re: Report on the bounded pointers work

2013-11-05 Thread Jeff Law 

On 11/05/13 03:11, Yury Gribov wrote:

 > If you're referring to mudflap (Frank Eigler's work),
 > ...
 > It never reached a point where interoperability across objects with
and without mudflap instrumentation worked

Jeff,

Could you add more details? E.g. I don't see how mudflap
interoperability is different from AdressSanitizer which seems to be
state of the art.
I haven't looked at AddressSanitizer, so I can't really comment on 
if/how it handles code interoperability.


I would recommend reviewing the work Intel is doing on MPX.

jeff

Re: Report on the bounded pointers work

2013-11-05 Thread Jakub Jelinek 
On Tue, Nov 05, 2013 at 09:54:31AM -0700, Jeff Law wrote:
> On 11/05/13 03:11, Yury Gribov wrote:
> > > If you're referring to mudflap (Frank Eigler's work),
> > > ...
> > > It never reached a point where interoperability across objects with
> >and without mudflap instrumentation worked

> >Could you add more details? E.g. I don't see how mudflap
> >interoperability is different from AdressSanitizer which seems to be
> >state of the art.
> I haven't looked at AddressSanitizer, so I can't really comment on
> if/how it handles code interoperability.

Asan is conservative, you can mix instrumented and uninstrumented code.
There are some issues if you don't link the binary with -fsanitize=address
(both that the library may be initialized too late to work properly and that
it's entry points that are meant to override libc/libpthread/libstdc++ entry
points aren't early enough in symbol search scope), but some libraries are
instrumented, but other than that it should work fine.  Also, one issue is
the large address space requirements (so you can't use too low RLIMIT_AS).

As for speed, I guess it remains to be measured which of asan vs. MPX is
faster (and, if MPX grows some variant without HW support, also how well
that one works compared to asan).

Jakub

Re: Report on the bounded pointers work

2013-11-05 Thread Frank Ch. Eigler 
Yury Gribov  writes:

>[...]
>> [mudflap] never reached a point where interoperability across objects with
> and without mudflap instrumentation worked
>
> Could you add more details? E.g. I don't see how mudflap
> interoperability is different from AdressSanitizer which seems to be
> state of the art.

My sense is that asan and mudflap are comparable with respect to
support of interoperation between instrumented and uninstrumented
code.  The trick is how to handle pointers arriving from the latter.
libmudflap handled this issue in two ways: by attempting to intercept
all heap allocations from libraries (at the glibc/dlsym level), and by
heuristics for recognizing addresses that might have come from
unintercepted static/auto allocations.  The former is tricky and was
an uphill battle trying to catch everything, so in practice heuristics
were almost always necessary.

(There are of course many differences.  They have different tradeoffs
as to speed versus memory-consumption - asan is hard-coded in the
opposite direction than libmudflap's (configurable) default.  asan's
multi-threading support may be superior.  mudflap's tuning/features
were not completed.  asan sports more recent developers.)

- FChE

Re: [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIME__

2013-11-05 Thread Steve Kargl 
On Mon, Nov 04, 2013 at 09:58:30PM +0100, Tobias Burnus wrote:
> Tobias Burnus wrote:
> > Gerald Pfeifer wrote:
> >> To make it easier to reproduce builds of software and entire GNU/Linux
> >> distributions, RMS had the idea of adding a warning to GCC that warns
> >> about the use of __DATE__ and __TIME__.
> >
> > I assume that he also likes to have a warning for __TIMESTAMP__.
> >
> >> I was thinking a new warning -Wdate-time or similar could address
> >> this. Any volunteers implementing this?
> > Do you mean something like the attached patch? (Only lightly tested.)
> 
> Updated version attached ? after bootstrapping and regtesting on 
> x86-64-gnu-linux
> OK?
> 

Fortran bits are OK.

-- 
Steve

Adding dependencies without rule in Makefile.am

2013-11-05 Thread FX 
Hi,

I’m trying to patch libgfortran’s Makefile.am but I’m running into trouble to 
express some chain of dependencies.

I have two new files: a.F90 and b.F90. I’m adding them to 
libgfortran_la_SOURCES. These will thus generate a.o and b.o object files, 
which will be linked into libgfortran. So far, so good.

But these files also generate Fortran module files (i.e., compiling a.F90 will 
generate a file a.mod in addition to a.o). It so happens that compiling b.F90 
depends on a.mod being available. I cannot, however, manage to enter that 
information into the Makefile.am. I first tried to add this simple dependency 
in terms of object files:

a.lo: b.lo

with no rule. Turns out that automake then says:

> Makefile.am:882: user target `ieee_arithmetic.lo' defined here...
> /opt/automake-1.11.1/share/automake-1.11/am/depend2.am: ... overrides 
> Automake target `ieee_arithmetic.lo' defined here


So: is it possible to add a dependency without overriding the rule? I like 
automake’s compilation line fine, I just want to add a dependency.


Thanks for any help, this is driving me nuts and preventing completion of my 
patch…

FX