Re: [RFC] Apple Blocks extension
On 11/04/2013 06:10 AM, Ian Lance Taylor wrote: Clang's blocks are more powerful than GCC's nested functions, because blocks may be placed on the heap, and therefore returned from a function. And they don't need code generation at run time. -- Florian Weimer / Red Hat Product Security Team
Re: integer_onep vs. signed 1-bit bitfields
On Sat, 2 Nov 2013, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote: > >> What should integer_onep mean if we have a signed 1-bit bitfield in > >> which the bit is set? Seen as a 1-bit value it's "obviously" 1, > >> but seen as a value extended to infinite precision it's -1. > >> > >> Current mainline returns false while wide-int returns true. > > > > Then current mainline is correct. signed 1-bit bitfield has values > > 0 and -1, not 0 and 1. And, signed 1-bit -1 should be just > > integer_minus_onep and integer_all_onesp. > > OK, thanks. I should have realised this earlier, but we have: > > /* Return 1 if EXPR is the integer constant one or the corresponding >complex constant. */ > > int > integer_onep (const_tree expr) > ... > /* Return 1 if EXPR is the integer constant minus one. */ > > int > integer_minus_onep (const_tree expr) > > which makes them sound like a pair. But integer_minus_onep returns > true for any all-ones INTEGER_CST (regardless of sign): > > if (TREE_CODE (expr) == COMPLEX_CST) > return (integer_all_onesp (TREE_REALPART (expr)) > && integer_zerop (TREE_IMAGPART (expr))); > else > return integer_all_onesp (expr); > > So a nonzero 1-bit unsigned bitfield is both integer_onep and > integer_minus_onep, but a 1-bit signed bitfield is only > integer_minus_onep. Should integer_minus_onep be changed so > that it always returns false for unsigned types? I think so (but it was only introduced very recently, exactly because integer_minus_onep is not equal to integer_all_onesp in all cases). Richard.
Re: integer_onep vs. signed 1-bit bitfields
On Sat, 2 Nov 2013, Marc Glisse wrote: > On Sat, 2 Nov 2013, Jakub Jelinek wrote: > > > On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote: > > > OK, thanks. I should have realised this earlier, but we have: > > > > > > /* Return 1 if EXPR is the integer constant one or the corresponding > > >complex constant. */ > > > > > > int > > > integer_onep (const_tree expr) > > > ... > > > /* Return 1 if EXPR is the integer constant minus one. */ > > > > > > int > > > integer_minus_onep (const_tree expr) > > > > > > which makes them sound like a pair. But integer_minus_onep returns > > > true for any all-ones INTEGER_CST (regardless of sign): > > > > > > if (TREE_CODE (expr) == COMPLEX_CST) > > > return (integer_all_onesp (TREE_REALPART (expr)) > > > && integer_zerop (TREE_IMAGPART (expr))); > > > else > > > return integer_all_onesp (expr); > > > > > > So a nonzero 1-bit unsigned bitfield is both integer_onep and > > > integer_minus_onep, but a 1-bit signed bitfield is only > > > integer_minus_onep. Should integer_minus_onep be changed so > > > that it always returns false for unsigned types? > > > > Yeah, I was wondering about that too. I think integer_minus_onep > > is a fairly new thing, I guess if you want to change it, somebody has to go > > through all users and see what they want. > > Returning false for unsigned types is natural thing to do though. > > See the conversation around: > http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00053.html > for the introduction of this function. > > Richard already asked the same question then, and the patch renaming some > integer_all_onesp to integer_minus_onep was forgotten. Personnally, I am fine > with integer_minus_onep returning true on -1U. Without the renaming patch, > there is a single use of integer_minus_onep (in fold-const.c), so it shouldn't > be hard to check all users, and IIRC we want it to return true for -1U in this > case (turning x*-1 into -x). Well - it was introduced because integer_all_onesp was "wrong" for complex types. But now -1U is more integer_all_onesp than integer_one_p ... The single user doesn't care, so we either adjust the function comment to not say "minus one" but to relate it to the arithmetic operation it is supposed to be a complement / invariant of. Richard.
Re: [RFC] Apple Blocks extension
On 04/11/13 06:18, pins...@gmail.com wrote: > > >> On Nov 3, 2013, at 9:10 PM, Ian Lance Taylor >> wrote: >> >>> On Sun, Nov 3, 2013 at 8:49 PM, wrote: >>> >>> On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov wrote: Hi, I am considering a project to add Apple's blocks [*] extension to GCC. I am looking at adding blocks support to C, C++ and Obj-C/C++ front-ends. >>> >>> What benefits does blocks have over nested functions in C and >>> over lambas in C++? I think it is wrong to add another extension >>> if only to be compatible with clang. I also think the blocks >>> extension are less useful than nested functions and lambas. The >>> question really should be why support something which has no >>> advantage to them to what is already existing. I think it was >>> wrong for apple to add them in the first place. >> >> Clang's blocks are more powerful than GCC's nested functions, >> because blocks may be placed on the heap, and therefore returned >> from a function. > > Actually I think it is less powerful since it is a copy rather than a > reference. Then again lambas can be do both. > The point is that a function can create a block that refers to the function's local variables, pass a pointer to that block somewhere (such as by returning it), and everything will still work - the data required for the block will be put on the heap. You can't do that with a gcc nested function. As far as I can see (from the Wikipedia article and a brief google), "blocks" are a mixture of C++ lambdas and functors. Like functors, you can use the heap to preserve the data and let the block exist beyond the defining scope. Like lambdas, you can capture local data without having to define the details and manually copy the data. Whether or not this is useful enough to implement, I don't know. But the Wikipedia article refers to an Apple fork of gcc with block support - forks like that are generally not an ideal situation for gcc. > >> >> Ian >
Report on the bounded pointers work
More than a decade ago, there was some work in GCC and glibc about propagating bounds information for pointers. I could find the old web page on archive.org, but I'm wondering if there's a concise report how it actually worked and how much software could be ported over with what amount of effort. -- Florian Weimer / Red Hat Product Security Team
Re: Fwd: [RTL, ARM] subreg of partially invalid register, is it valid RTL?
> The question: > > The insn which causes the segfault is: > (debug_insn 1548 1547 1886 11 (var_location:V4HI __b (subreg:V4HI > (reg:V8HI 125 d31 [orig:657 vr ] [657]) 0)) upsampling_neon.c:850 -1 > (nil)) > > The variable vr is declared as a NEON vector of 8 16bit integers, and > -frename-registers has caused it to be separated into 2 64bit parts. > So the register allocation is ok, but if considered in isolation the > part which reads (reg:V8HI 125 d31 [orig:657 vr ] [657]) represents a > non-existent register, as the last physical register is d31 (regnos > 125,126). > > When this is processed by sched_analyze_2 in sched-deps.c, the subreg > is handled by treating it as the included (reg), and it therefore adds > dependencies on invalid physical registers, which leads to a segfault. > If the variable was not assigned to d31 (as in fsf 4.7), then it would > not crash, but would add false dependencies. > > So, my question is: Is the above RTL valid? In other words, should > sched-deps.c handle this, or should all reg RTL expressions represent > fully valid registers? If d31 cannot contain a V8HImode value, then (reg:V8HI 125 d31) should not be generated under normal circumstances. Here it's a var location so this might be less clear, but still. How are the REG and SUBREG generated exactly? -- Eric Botcazou
Re: Report on the bounded pointers work
On Mon, Nov 04, 2013 at 11:44:57AM +0100, Florian Weimer wrote: > More than a decade ago, there was some work in GCC and glibc about > propagating bounds information for pointers. I could find the old > web page on archive.org, but I'm wondering if there's a concise > report how it actually worked and how much software could be ported > over with what amount of effort. > One thing on my todo list is that you do not need these for bound functionality. For stack allocations _FORTIFY_SOURCE does good job. For heap just write allocator that will for given address give start and end of allocated area. This can be made effective by keeping a hash table that will for each page give list of allocated areas. This is in my todo list.
Re: Something wrong with bootstrap-lto, or lto itself:
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. Richard. > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: [RFC] Apple Blocks extension
On Mon, 2013-11-04 at 17:28 +1300, Maxim Kuvyrkov wrote: > I am considering a project to add Apple's blocks [*] extension to GCC. I am > looking at adding blocks support to C, C++ and Obj-C/C++ front-ends. > > There are many challenges (both technical and copyright) that require work > before any patches are ready for review, and I would appreciate indication > from front-end maintainers on whether a technically sound implementation of > Blocks extension would be a welcome addition to GCC front-ends. What is the status of this or similar features (eg, lambdas) in ISO C? IOW, what was the feedback on the blocks part of http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf, and are there any follow-ups? IMHO, it would be preferable to support what might have a chance of ending up in ISO C.
Re: Something wrong with bootstrap-lto, or lto itself:
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.
yeah :/
> 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.
Well, I suppose we could add a constructor that takes a number of
elements and if that is greater than the template arg calls malloc, but
the way stack vectors work you're going to use N * sizeof(T) space on
the stack anyway so its not entirely clear you want to use a stack
vector there at all.
I think its actually complaining about trying to free NUL, see this part
of vec::reserve
bool handle_auto_vec = m_vec && using_auto_storage ();
if (handle_auto_vec)
{
m_vec = NULL;
oldsize = oldvec->length ();
nelems += oldsize;
}
accept that va_heap::release bails out if v == NULL.
I'll try and look into this more today.
Trev
va_heap::reserve (m_vec, nelems, exact
PASS_MEM_STAT);
>
> Richard.
>
> > --
> > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Why doesn't gcc 4.6 show line numbers in error messages?
Hi I hope this isn't a silly question. I am running gcc 4.6.3 on Ubuntu 12. When I compile my source code I get compiler errors in a form that I don't expect. For example: EVD.cpp:(.text+0x1c6e): undefined reference to `Matrix >::Matrix()' Why is the location of the error shown relative to .text instead of as a simple line number? Best regards David
Re: Why doesn't gcc 4.6 show line numbers in error messages?
On 11/04/2013 02:56 PM, David Aldrich wrote: I hope this isn't a silly question. I am running gcc 4.6.3 on Ubuntu 12. When I compile my source code I get compiler errors in a form that I don't expect. For example: EVD.cpp:(.text+0x1c6e): undefined reference to `Matrix >::Matrix()' Why is the location of the error shown relative to .text instead of as a simple line number? Such questions should go to the gcc-help mailing list. This is a linker error message. The linker can only report line numbers in some cases if there is debugging information. -- Florian Weimer / Red Hat Product Security Team
Re: Why doesn't gcc 4.6 show line numbers in error messages?
On Monday 04 November 2013 13:56:46 David Aldrich wrote: > EVD.cpp:(.text+0x1c6e): undefined reference to `Matrix > >::Matrix()' Because it's the linker which is complaining, not the compiler. "Undefined reference" means you're referencing a library the linker can't find. -- Fidel Leon fidell...@mykolab.com 70FB 4F7C CE9C 6761 2AAB CDD6 8AD4 C51B C530 06A7
RE: Why doesn't gcc 4.6 show line numbers in error messages?
Thanks for your answer. Sorry I used the wrong list. David > -Original Message- > From: fidell...@mykolab.com [mailto:fidell...@mykolab.com] > Sent: 04 November 2013 14:34 > To: gcc@gcc.gnu.org > Cc: David Aldrich > Subject: Re: Why doesn't gcc 4.6 show line numbers in error messages? > > On Monday 04 November 2013 13:56:46 David Aldrich wrote: > > > EVD.cpp:(.text+0x1c6e): undefined reference to > > `Matrix > > >::Matrix()' > > Because it's the linker which is complaining, not the compiler. "Undefined > reference" means you're referencing a library the linker can't find. > > -- > Fidel Leon > fidell...@mykolab.com > 70FB 4F7C CE9C 6761 2AAB CDD6 8AD4 C51B C530 06A7 > > > Click > https://www.mailcontrol.com/sr/kNPQh9sIZsLGX2PQPOmvUuHxyFIItuEMfXhzL7 > 74zF8HR0h24dRIfMdcnSVTSLICD80j2WpbjaKqE4naC2k80A== to report this > email as spam.
Re: Report on the bounded pointers work
On 11/04/13 03:44, Florian Weimer wrote: More than a decade ago, there was some work in GCC and glibc about propagating bounds information for pointers. I could find the old web page on archive.org, but I'm wondering if there's a concise report how it actually worked and how much software could be ported over with what amount of effort. If you're referring to mudflap (Frank Eigler's work), then that was recently pulled. It never reached a point where interoperability across objects with and without mudflap instrumentation worked and it had been abandoned for some time. 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. Currently we're looking at Intel's MPX as the best solution in that space and trying to design a generic system that would be able to exploit the MPX capabilities as an accelerator for bounds checking. jeff
Re: [RFC] Apple Blocks extension
On Mon, 4 Nov 2013, Maxim Kuvyrkov wrote: > Joseph, Richard, as C front-end maintainers, would you be supportive of > Blocks extension implemented for C front-end? Yes. I believe the point (or one of the points) is that at least some system headers in current Darwin require this extension (more generally, there are existing bodies of code that require this feature)? (Also, if someone were to implement support for the OpenCL C language in GCC, OpenCL 2.0 requires blocks.) -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Apple Blocks extension
On Mon, 4 Nov 2013, Torvald Riegel wrote: > What is the status of this or similar features (eg, lambdas) in ISO C? > IOW, what was the feedback on the blocks part of > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf, and are there > any follow-ups? IMHO, it would be preferable to support what might have > a chance of ending up in ISO C. There was no consensus on addition for C11 (see N1451/N1457, and the Boulder minutes N1542). There is no current revision process for a new C standard version in which new features could be considered. But I would guess that to the extent such features are relevant for parallelism they might be considered in the CPLEX group. -- Joseph S. Myers jos...@codesourcery.com
Re: Report on the bounded pointers work
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). -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Apple Blocks extension
On Mon, 2013-11-04 at 16:39 +, Joseph S. Myers wrote: > On Mon, 4 Nov 2013, Torvald Riegel wrote: > > > What is the status of this or similar features (eg, lambdas) in ISO C? > > IOW, what was the feedback on the blocks part of > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf, and are there > > any follow-ups? IMHO, it would be preferable to support what might have > > a chance of ending up in ISO C. > > There was no consensus on addition for C11 (see N1451/N1457, and the > Boulder minutes N1542). Thanks for the pointers. > There is no current revision process for a new C > standard version in which new features could be considered. But I would > guess that to the extent such features are relevant for parallelism they > might be considered in the CPLEX group. Perhaps (it hasn't happened so far AFAIK) -- although what CPLEX is currently looking at are Cilk and OpenMP, both of which demarcate parallel task differently (eg, with cilk_spawn). Maybe that will change if/when CPLEX starts to also consider library interfaces for task-based parallelism or for concurrency.
Re: [RFC] Apple Blocks extension
On 11/04/2013 11:34 AM, Joseph S. Myers wrote: On Mon, 4 Nov 2013, Maxim Kuvyrkov wrote: Joseph, Richard, as C front-end maintainers, would you be supportive of Blocks extension implemented for C front-end? Yes. I believe the point (or one of the points) is that at least some system headers in current Darwin require this extension (more generally, there are existing bodies of code that require this feature)? (Also, if someone were to implement support for the OpenCL C language in GCC, OpenCL 2.0 requires blocks.) Yes, similarly. Jason
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? I see the same error with "--disable-bootstrap --enable-languages=c,c++". Should configure test the compiler for support of -fcilkplus and disable libcilkplus if not? Thanks, - Tom
RE: libcilkrts breaks non-bootstrap build
Hi Tom, Please see my response below: Thanks, Balaji V. Iyer. > -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? > Yes, I should do that. Thanks for catching this. > I see the same error with "--disable-bootstrap --enable-languages=c,c++". > Should configure test the compiler for support of -fcilkplus and disable > libcilkplus if not? > Hmm, I generally build using the two flags and it always works for me. Let me try it again and get back to you. > Thanks, > - Tom
RE: libcilkrts breaks non-bootstrap build
Hi Tom, This is what I tried for --enable-languages=c,c++ ../trunk-gcc/configure --disable-bootstrap --enable-languages="c,c++" --prefix=/home /install_dir/trunk-install-disable-bootstrap And it seem to compile fine. Did you any other tags to configure? Thanks, Balaji V. Iyer. > -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? > > I see the same error with "--disable-bootstrap --enable-languages=c,c++". > Should configure test the compiler for support of -fcilkplus and disable > libcilkplus if not? > > Thanks, > - Tom
[Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIME__
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?
Tobias
2013-11-04 Tobias Burnus
gcc/c-family/
* c.opt (-Wdate-time): New option
* c-opts.c (sanitize_cpp_opts): Pass on to libcpp.
gcc/
* doc/invoke.texi (-Wdate-time): Document.
gcc/fortran
* lang.opt (-Wdate-time): New option
* cpp.c (gfc_cpp_option_data): Add warn_date_time.
(gfc_cpp_init_options, gfc_cpp_handle_option,
gfc_cpp_post_options): Handle it and pass on to libcpp.
gcc/testsuite/
* g++.dg/warn/wdate-time.C: New.
* gcc.dg/wdate-time.c: New.
* gfortran.dg/wdate-time.F90: New.
libcpp/
* include/cpplib.h (CPP_W_DATE_TIME): Added.
(cpp_options): Add warn_date_time.
* init.c (cpp_create_reader): Init it.
* macro.c (_cpp_builtin_macro_text): Warn when
__DATE__/__TIME__/__TIMESTAMP__ is used.
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 702fe1a..2de5425 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1198,6 +1198,7 @@ sanitize_cpp_opts (void)
cpp_opts->unsigned_char = !flag_signed_char;
cpp_opts->stdc_0_in_system_headers = STDC_0_IN_SYSTEM_HEADERS;
+ cpp_opts->warn_date_time = cpp_warn_date_time;
/* Wlong-long is disabled by default. It is enabled by:
[-Wpedantic | -Wtraditional] -std=[gnu|c]++98 ; or
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index b862eb9..a5fe595 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -640,6 +640,10 @@ Wpragmas
C ObjC C++ ObjC++ Var(warn_pragmas) Init(1) Warning
Warn about misuses of pragmas
+Wdate-time
+Common Var(cpp_warn_date_time) Warning
+Warn about __TIME__, __DATE__ and __TIMESTAMP__ usage
+
Wproperty-assign-default
ObjC ObjC++ Var(warn_property_assign_default) Init(1) Warning
Warn if a property for an Objective-C object has no assign semantics specified
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e84bca3..5dae1fb 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -240,7 +240,7 @@ Objective-C and Objective-C++ Dialects}.
-Wno-attributes -Wno-builtin-macro-redefined @gol
-Wc++-compat -Wc++11-compat -Wcast-align -Wcast-qual @gol
-Wchar-subscripts -Wclobbered -Wcomment -Wconditionally-supported @gol
--Wconversion -Wcoverage-mismatch -Wdelete-incomplete -Wno-cpp @gol
+-Wconversion -Wcoverage-mismatch -Wdate-time -Wdelete-incomplete -Wno-cpp @gol
-Wno-deprecated -Wno-deprecated-declarations -Wdisabled-optimization @gol
-Wno-div-by-zero -Wdouble-promotion -Wempty-body -Wenum-compare @gol
-Wno-endif-labels -Werror -Werror=* @gol
@@ -4517,6 +4517,13 @@ types. @option{-Wconversion-null} is enabled by default.
Warn when a literal '0' is used as null pointer constant. This can
be useful to facilitate the conversion to @code{nullptr} in C++11.
+@item -Wdate-time
+@opindex Wdate-time
+@opindex Wno-date-time
+Warn when macros @code{__TIME__}, @code{__DATE__} or @code{__TIMESTAMP__}
+are encountered as they might prevent bit-wise-identical reproducable
+compilations.
+
@item -Wdelete-incomplete @r{(C++ and Objective-C++ only)}
@opindex Wdelete-incomplete
@opindex Wno-delete-incomplete
diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
index ea53681..8417ddc 100644
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -100,6 +100,7 @@ struct gfc_cpp_option_data
const char *deps_filename_user; /* -MF */
int deps_missing_are_generated; /* -MG */
int deps_phony; /* -MP */
+ int warn_date_time; /* -Wdate-time */
const char *multilib; /* -imultilib */
const char *prefix; /* -iprefix */
@@ -262,6 +263,7 @@ gfc_cpp_init_options (unsigned int decoded_options_count,
gfc_cpp_option.no_predefined = 0;
gfc_cpp_option.standard_include_paths = 1;
gfc_cpp_option.verbose = 0;
+ gfc_cpp_option.warn_date_time = 0;
gfc_cpp_option.deps = 0;
gfc_cpp_option.deps_skip_system = 0;
gfc_cpp_option.deps_phony = 0;
@@ -359,6 +361,9 @@ gfc_cpp_handle_option (size_t scode, const char *arg, int value ATTRIBUTE_UNUSED
gfc_cpp_option.verbose = value;
break;
+case OPT_Wdate_time:
+ gfc_cpp_option.warn_date_time = value;
+
case OPT_A:
case OPT_D:
case OPT_U:
@@ -469,6 +474,7 @@ gfc_cpp_post_options (void)
cpp_option->discard_comments_in_macro_exp = gfc_cpp_option.discard_comments_in_macro_exp;
cpp_option->print_include_names = gfc_cpp_option.print_include_names;
cpp_option->preprocessed = gfc_option.flag_preprocessed;
+ cpp_opti
Re: Warning about __DATE__ and __TIME__
On 28 October 2013 21:13, Ian Lance Taylor wrote: > On Sun, Oct 27, 2013 at 12:04 PM, 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__. >> >> Short of "interesting" changes to the environment or #defining these >> two, as soon as a program uses __DATE__ or __TIME__ at least once, >> builds of the program will differ for that reason alone. (There are >> others, but one step at a time; this is not the point of this mail). >> >> I was thinking a new warning -Wdate-time or similar could address >> this. > > I don't have any strong objection, but I'll note that it's even easier > to use -D options. > > CC='gcc -D__DATE__=today' It's undefined behaviour in both C and C++ to redefine pre-defined macros such as __DATE__ or __TIME__. The undefined behaviour study group of the C++ committee are considering making it ill-formed, which would require a diagnostic.
Re: Warning about __DATE__ and __TIME__
On Mon, 4 Nov 2013, Jonathan Wakely wrote: > On 28 October 2013 21:13, Ian Lance Taylor wrote: >> I don't have any strong objection, but I'll note that it's even easier >> to use -D options. >> >> CC='gcc -D__DATE__=today' > It's undefined behaviour in both C and C++ to redefine pre-defined > macros such as __DATE__ or __TIME__. > > The undefined behaviour study group of the C++ committee are > considering making it ill-formed, which would require a diagnostic. Also, that would not warn, but change the outcome of the program. (Which could be one way to address this, of course, but the request we had really was about warning.) Gerald
Re: libcilkrts breaks non-bootstrap build
On 04/11/13 21:23, Iyer, Balaji V wrote: > Hi Tom, > This is what I tried for --enable-languages=c,c++ > > ../trunk-gcc/configure --disable-bootstrap --enable-languages="c,c++" > --prefix=/home /install_dir/trunk-install-disable-bootstrap > > And it seem to compile fine. Did you any other tags to configure? > Balaji, I've just tried it myself again, and didn't manage to reproduce the error. I think I must have seen a side effect of a patch I was trying out to fix the other problem. Sorry for the confusion. Thanks, - Tom > Thanks, > > Balaji V. Iyer. > >> -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? >> >> I see the same error with "--disable-bootstrap --enable-languages=c,c++". >> Should configure test the compiler for support of -fcilkplus and disable >> libcilkplus if not? >> >> Thanks, >> - Tom
Re: [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIME__
The warning should say "macro" not "Macro" and I think "reproducing" not "reproduce". The c-family and libcpp changes are OK with that fixed. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Apple Blocks extension
On Nov 3, 2013, at 8:49 PM, pins...@gmail.com wrote: > What benefits does blocks have over nested functions in C and over lambas in > C++? The ability to compile existing code. The ability to compile code that uses system header files on macosx. The ability to use third party libraries on macosx. The ability to use system libraries on macosx. Though, the ability to compile code is maybe overrated by some.
Re: [RFC] Apple Blocks extension
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov wrote: > I am considering a project to add Apple's blocks [*] extension to GCC. I have a funny story about that one… I was just about ready to submit the work, the GPLv3 happened. Ah… life goes on.
Re: [RFC] Apple Blocks extension
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov wrote: > Mike, as Obj-C/C++ front-end maintainers, would you be supportive of Blocks > extension implemented for Obj-C/C++ front-ends? Sure. Though, I'd really love a front-end extension to allow one to implement Blocks as a pure library. :-) [ ducks ]
Re: Warning about __DATE__ and __TIME__
On 4 November 2013 22:26, Andreas Schwab wrote: > >> The undefined behaviour study group of the C++ committee are >> considering making it ill-formed, which would require a diagnostic. > > That still wouldn't cover command line arguments. Ah yes, as it would still be predefined, but to the value given on the command-line. So not a problem then, I just thought I should mention it.
[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: Something wrong with bootstrap-lto, or lto itself:
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. However I think I've convinced myself this code to have vec_prefix::calculate_allocation return 0 if !prefix & !reserve should never be hit, so I think we can remove it and infact that seems to get me through atleast one round of lto. I'll run a full lto bootstrap and standard bootstrap on x86_64-linux-gnu with test suite, assuming those are ok is the below ok? Trev 2013-11-4 Trevor Saunders * vec.c (vec_prefix::calculate_allocation): Don't try to handle the
