Re: testing that a Gimple call argument is a string...
On Thu, Oct 18, 2012 at 10:33 PM, Basile Starynkevitch
wrote:
> Hello
>
> I'm coding in MELT the ex06/ of https://github.com/bstarynk/melt-examples/
> which should typecheck calls to variadic functions json_pack & json_unpack
> from http://www.digip.org/jansson (a JSON library in C).
>
> I'm working on a MELT pass on Gimple/SSA after phiopt (maybe that place is
> wrong?)
>
> I don't understand well how to check that a given Gimple argument is a string.
> I was thinking of using useless_type_conversion_p or types_compatible_p on
> the TREE_TYPE of some POINTER_TYPE with char_type_node, but it seems to not
> work as I would expect
>
> How would you (in C++ or C for a 4.6) code such a test (that argument 2 of
> some GIMPLE_CALL is a string, ie. a char* in C parlance)?
You would look at the function signature of the function called, not at its
argument. The argument can be a void * and still be a "string" (well, a pointer
to a string). GIMPLE doesn't care about the actual type pointed to.
> (I'm coding in MELT, but I am not asking a MELT specific question; I have
> hard time understanding how that should be coded in C++).
>
> Or where is the typechecking for __attribute__((format(printf))) functions
> done in the GCC source tree?
> Regards.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
RE: Inconsistency between code and docs
> > I think the bug is in the documentation, and that > TARGET_ASM_NAMED_SECTION should accept an IDENTIFIER_NODE. > > Ian I will be reporting this with bugzilla then. Thanks for the clarification, Paulo Matos
Re: Inconsistency between code and docs
On Fri, Oct 19, 2012 at 10:28 AM, Paulo Matos wrote: >> >> I think the bug is in the documentation, and that >> TARGET_ASM_NAMED_SECTION should accept an IDENTIFIER_NODE. >> >> Ian > > I will be reporting this with bugzilla then. Can you instead produce a patch? > Thanks for the clarification, > > Paulo Matos >
Re: testing that a Gimple call argument is a string...
On Fri, Oct 19, 2012 at 10:26:58AM +0200, Richard Biener wrote:
> On Thu, Oct 18, 2012 at 10:33 PM, Basile Starynkevitch
> wrote:
> > Hello
> >
> > I'm coding in MELT the ex06/ of https://github.com/bstarynk/melt-examples/
> > which should typecheck calls to variadic functions json_pack & json_unpack
> > from http://www.digip.org/jansson (a JSON library in C).
> >
> > I'm working on a MELT pass on Gimple/SSA after phiopt (maybe that place is
> > wrong?)
> >
> > I don't understand well how to check that a given Gimple argument is a
> > string.
> > I was thinking of using useless_type_conversion_p or types_compatible_p on
> > the TREE_TYPE of some POINTER_TYPE with char_type_node, but it seems to not
> > work as I would expect
> >
> > How would you (in C++ or C for a 4.6) code such a test (that argument 2 of
> > some GIMPLE_CALL is a string, ie. a char* in C parlance)?
>
> You would look at the function signature of the function called, not at its
> argument. The argument can be a void * and still be a "string" (well, a
> pointer
> to a string). GIMPLE doesn't care about the actual type pointed to.
GCC is using the syntactic type of the argument for printf. The following code
void f (char *s)
{ printf ("%s\n", (void *) s); }
gives when compiled with gcc -Wall
f.c:4:1: warning: format ‘%s’ expects argument of type ‘char *’, but argument
2 has type ‘void *’ [-Wformat]
and we are in the case where the argument is a string casted to (void*); I
don't want to give more clever warnings.
So I don't follow you. I want to typecheck (at least in the common simple
cases) the calls to that variadic function.
I don't care that much about its signature.
To be concrete, declares
json_t *json_pack(const char *fmt, ...);
and the documentation
http://www.digip.org/jansson/doc/2.4/apiref.html#building-values
suggests that
/* Create the JSON integer 42 */
json_pack("i", 42);
/* Create the JSON array ["foo", "bar", true] */
json_pack("[ssb]", "foo", "bar", 1);
I just want to extend GCC (thru a MELT extension, but that could be a GCC
plugin in C++) to detect
incorrect calls like
json_pack("i", /*that should be an int:*/ 3.14);
or
json_pack("[ss]", "foo", /* that should be a string*/ 3
/*and the arity is wrong an argument is missing*/);
I believe I should use
extern bool useless_type_conversion_p (tree, tree);
from gcc/gimple.h (it is funny that function is in gimple.h, I would expected
it to be in tree.h)
with one of the argument being char_type_node
But I might have trouble in using it.
Thanks for reading. Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: testing that a Gimple call argument is a string...
On Fri, Oct 19, 2012 at 10:59 AM, Basile Starynkevitch
wrote:
> On Fri, Oct 19, 2012 at 10:26:58AM +0200, Richard Biener wrote:
>> On Thu, Oct 18, 2012 at 10:33 PM, Basile Starynkevitch
>> wrote:
>> > Hello
>> >
>> > I'm coding in MELT the ex06/ of https://github.com/bstarynk/melt-examples/
>> > which should typecheck calls to variadic functions json_pack & json_unpack
>> > from http://www.digip.org/jansson (a JSON library in C).
>> >
>> > I'm working on a MELT pass on Gimple/SSA after phiopt (maybe that place is
>> > wrong?)
>> >
>> > I don't understand well how to check that a given Gimple argument is a
>> > string.
>> > I was thinking of using useless_type_conversion_p or types_compatible_p on
>> > the TREE_TYPE of some POINTER_TYPE with char_type_node, but it seems to
>> > not work as I would expect
>> >
>> > How would you (in C++ or C for a 4.6) code such a test (that argument 2 of
>> > some GIMPLE_CALL is a string, ie. a char* in C parlance)?
>>
>> You would look at the function signature of the function called, not at its
>> argument. The argument can be a void * and still be a "string" (well, a
>> pointer
>> to a string). GIMPLE doesn't care about the actual type pointed to.
>
> GCC is using the syntactic type of the argument for printf. The following code
> void f (char *s)
> { printf ("%s\n", (void *) s); }
> gives when compiled with gcc -Wall
> f.c:4:1: warning: format ‘%s’ expects argument of type ‘char *’, but
> argument 2 has type ‘void *’ [-Wformat]
> and we are in the case where the argument is a string casted to (void*); I
> don't want to give more clever warnings.
The format warnings are output from the frontend which does not have GIMPLE.
> So I don't follow you. I want to typecheck (at least in the common simple
> cases) the calls to that variadic function.
> I don't care that much about its signature.
>
> To be concrete, declares
>json_t *json_pack(const char *fmt, ...);
>
> and the documentation
> http://www.digip.org/jansson/doc/2.4/apiref.html#building-values
> suggests that
>/* Create the JSON integer 42 */
>json_pack("i", 42);
>/* Create the JSON array ["foo", "bar", true] */
>json_pack("[ssb]", "foo", "bar", 1);
>
> I just want to extend GCC (thru a MELT extension, but that could be a GCC
> plugin in C++) to detect
> incorrect calls like
>
>json_pack("i", /*that should be an int:*/ 3.14);
> or
>json_pack("[ss]", "foo", /* that should be a string*/ 3
> /*and the arity is wrong an argument is missing*/);
>
> I believe I should use
>extern bool useless_type_conversion_p (tree, tree);
> from gcc/gimple.h (it is funny that function is in gimple.h, I would expected
> it to be in tree.h)
> with one of the argument being char_type_node
the predicate is only valid on GIMPLE, not on GENERIC. GIMPLE ignores
all non-value-changing conversions while GENERIC does not.
> But I might have trouble in using it.
Indeed you will experience that it might do something sensible for simple
testcases. But as I said above, you will not reliably be able to distinguish
a valid char * pointer from an invalid int * pointer just by looking at the
pointer type.
Richard.
> Thanks for reading. Regards.
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
Re: cse_process_notes_1 issue ?
> In the following RTL, the hardware (reg:HI r2), whose natural mode is
> HImode, is set to 0, but when analysing the REG_EQUAL notes of the MULT
> insn during CSE pass, the (reg:SI r2) is computed to be equivalent to 0,
> which is wrong (the target is big endian).
>
> (insn 51 9 52 3 (set (reg:HI 2 r2)
> (const_int 0 [0])) gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
> (expr_list:REG_DEAD (reg:HI 31)
> (expr_list:REG_EQUAL (const_int 0 [0])
> (nil
>
> (insn 52 51 12 3 (set (reg:HI 3 r3 [orig:2+2 ] [2])
> (reg/v:HI 20 [ number_of_digits_to_use ]))
> gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
> (expr_list:REG_DEAD (reg/v:HI 20 [ number_of_digits_to_use ])
> (nil)))
>
> (insn 12 52 13 3 (set (reg:SI 0 r0)
> (const_int 3321928 [0x32b048]))
> gcc.c-torture/execute/pr27364.c:5 19 {movsi}
> (nil))
>
> (insn 13 12 16 3 (parallel [
> (set (reg:SI 0 r0)
> (mult:SI (reg:SI 2 r2)
> (reg:SI 0 r0)))
> (clobber (reg:SI 2 r2))
> ]) gcc.c-torture/execute/pr27364.c:5 54 {*mulsi3_call}
> (expr_list:REG_EQUAL (mult:SI (reg:SI 2 r2)
> (const_int 3321928 [0x32b048]))
> (expr_list:REG_DEAD (reg:HI 3 r3)
> (expr_list:REG_UNUSED (reg:SI 2 r2)
> (nil)
>
>
> I think a mode size check is missing when processing REG code in
> cse_process_notes_1. Adding such a check prevents the CSE pass from
> elimintating the MULT instruction.
It looks like such a check is indeed missing in cse_process_notes_1 (and
probably equiv_constant as well). There is one in insert_regs with a comment
explaining the issue with hard registers.
> But then this MULT insn is simplified during the combine pass:
>
> Trying 12 -> 13:
> ...
> Successfully matched this instruction:
> (set (reg:SI 0 r0)
> (const_int 0 [0]))
> deferring deletion of insn with uid = 12.
> deferring deletion of insn with uid = 52.
> modifying insn i313 r0:SI=0
> deferring rescan insn with uid = 13.
>
>
> So double middle-end bug or do I miss something?
Probably a similar issue. I guess the code expects to have subregs of pseudos
here and isn't prepared for (arithmetic) operations on double-word hard regs.
--
Eric Botcazou
Re: New dump infrastructure
On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai wrote: >> You still have the issue that // regular stuff may appear to possibly >> clobber any_dump_enabled_p and thus repeated any_dump_enabled_p >> checks are not optimized by the compiler (we don't have predicated >> value-numbering (yet)). > >> So I prefer the guard. I suppose after this discussion I prefer >> a any_dump_enabled_p () guard instead of one with (repeated) flags. > > I have updated 'dump_enabled_p ()' a little bit in > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01690.html to avoid > checking of flags. If this looks better, I can update the guard > conditions in vectorization passes from 'if (dump_kind_p (...))' to > 'if (dump_enabled_p ())'. In the patch dump_enabled_p still has an integer argument. But yes, after this discussion please make it argument-less and work towards dropping dump_kind_p (from the public interface at least). Thanks, Richard. > Thanks, > Sharad
RE: Inconsistency between code and docs
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 19 October 2012 09:29 > To: Paulo Matos > Cc: Ian Lance Taylor; gcc@gcc.gnu.org > Subject: Re: Inconsistency between code and docs > > On Fri, Oct 19, 2012 at 10:28 AM, Paulo Matos > wrote: > >> > >> I think the bug is in the documentation, and that > >> TARGET_ASM_NAMED_SECTION should accept an IDENTIFIER_NODE. > >> > >> Ian > > > > I will be reporting this with bugzilla then. > > Can you instead produce a patch? > Sure.
RE: Inconsistency between code and docs
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 19 October 2012 09:29 > To: Paulo Matos > Cc: Ian Lance Taylor; gcc@gcc.gnu.org > Subject: Re: Inconsistency between code and docs > > Can you instead produce a patch? > Patch sent to gcc-patches. Cheers, -- Paulo Matos
AIX compile fail on trunk
If there is a better list, please point me to it.
I am using the git mirror with my branch set to origin/trunk. It was set to
"master". The last "git pull" was an hour or so ago. (It failed, I did a git
pull, and it still fails).
I'm on AIX 6.1 TL07 SP03 using a GCC 4.5.2 that I built. No changes to trunk
yet.
I passed these flags to configure:
"--with-gmp=${PUBLIC_BASE}" \
"--with-mpfr=${PUBLIC_BASE}" \
"--with-mpc=${PUBLIC_BASE}" \
"--disable-nls" \
"--enable-threads=aix" \
"--with-libiconv-prefix=/usr" \
"--enable-languages=c,c++"
The compile failed with:
> /usr/work/build/gcc.git/./gcc/xgcc -B/usr/work/build/gcc.git/./gcc/
> -B/gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/bin/
> -B/gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/lib/ -isystem
> /gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/include -isystem
> /gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/sys-include-g -O2
> -pthread -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
> ./include -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc
> -fno-stack-protector -mlong-double-128 -I. -I. -I../../.././gcc
> -I/usr/work/src/gcc.git/libgcc -I/usr/work/src/gcc.git/libgcc/.
> -I/usr/work/src/gcc.git/libgcc/../gcc
> -I/usr/work/src/gcc.git/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
> _fixunssfsi.o -MT _fixunssfsi.o -MD -MP -MF _fixunssfsi.dep -DL_fixunssfsi -c
> /usr/work/src/gcc.git/libgcc/libgcc2.c
> Assembler:
> /tmp//cc0k10sX.s: line 478: Instruction stfiwx is not implemented in the
> current assembly mode PPC.
> /tmp//cc0k10sX.s: line 489: Instruction stfiwx is not implemented in the
> current assembly mode PPC.
(stage_current has 'stage1' in it)
A few questions:
1) Am I on the right branch? I want to be on whatever you guys call "the
trunk". Is that origin/trunk or master?
2) After a git pull, do I need to completely blow away my build tree and start
completely over or can I just do configure and make?
3) Anyone have suggestions about the above error?
Thank you,
Perry Smith
[asan] Merge from trunk rev 192612
No big surprises. I will keep merging the branch from trunk weekly until we are ready to send the branch for trunk review. Diego.
Re: New dump infrastructure
The one taking argument is changed to dump_enabled_phase (Sharad, should it be dump_enabled_phase_p ?). Sharad, it may be better to throwing first a trivial patch that introduces dump_enabled_p () without argument, and leave the clean up of vectorizer code as a separate one. Do this earlier so that other contributors have time to cleanup the dumps. Please also resend to the email list to summarize the new standard way of debug/msg dump. thanks, David On Fri, Oct 19, 2012 at 3:11 AM, Richard Biener wrote: > On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai wrote: >>> You still have the issue that // regular stuff may appear to possibly >>> clobber any_dump_enabled_p and thus repeated any_dump_enabled_p >>> checks are not optimized by the compiler (we don't have predicated >>> value-numbering (yet)). >> >>> So I prefer the guard. I suppose after this discussion I prefer >>> a any_dump_enabled_p () guard instead of one with (repeated) flags. >> >> I have updated 'dump_enabled_p ()' a little bit in >> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01690.html to avoid >> checking of flags. If this looks better, I can update the guard >> conditions in vectorization passes from 'if (dump_kind_p (...))' to >> 'if (dump_enabled_p ())'. > > In the patch dump_enabled_p still has an integer argument. But yes, after > this discussion please make it argument-less and work towards dropping > dump_kind_p (from the public interface at least). > > Thanks, > Richard. > >> Thanks, >> Sharad
Re: New dump infrastructure
On Fri, Oct 19, 2012 at 12:03 PM, Xinliang David Li wrote: > The one taking argument is changed to dump_enabled_phase (Sharad, > should it be dump_enabled_phase_p ?). Yes, I renamed the old method to dump_enabled_phase. I would rename it further to dump_enabled_p to make it clear. > > Sharad, it may be better to throwing first a trivial patch that > introduces dump_enabled_p () without argument, and leave the clean up > of vectorizer code as a separate one. Do this earlier so that other > contributors have time to cleanup the dumps. Please also resend to the > email list to summarize the new standard way of debug/msg dump. Yes, I would do that. Thanks, Sharad > > thanks, > > David > > On Fri, Oct 19, 2012 at 3:11 AM, Richard Biener > wrote: >> On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai wrote: You still have the issue that // regular stuff may appear to possibly clobber any_dump_enabled_p and thus repeated any_dump_enabled_p checks are not optimized by the compiler (we don't have predicated value-numbering (yet)). >>> So I prefer the guard. I suppose after this discussion I prefer a any_dump_enabled_p () guard instead of one with (repeated) flags. >>> >>> I have updated 'dump_enabled_p ()' a little bit in >>> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01690.html to avoid >>> checking of flags. If this looks better, I can update the guard >>> conditions in vectorization passes from 'if (dump_kind_p (...))' to >>> 'if (dump_enabled_p ())'. >> >> In the patch dump_enabled_p still has an integer argument. But yes, after >> this discussion please make it argument-less and work towards dropping >> dump_kind_p (from the public interface at least). >> >> Thanks, >> Richard. >> >>> Thanks, >>> Sharad
Re: thumb2 support
Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo. If I try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get: arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2' This post indicates that mainline gcc does not currently support thumb2: https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ However, this indicates that thumb2 has been supported since 4.3: http://gcc.gnu.org/gcc-4.3/changes.html Can anyone clear this up? >>> >>> The errors are coming from an assembler file that is not part of the >>> GCC sources. Are those instructions valid for Thumb2? I don't know. >>> If they are valid, then the issue is with the assembler, which is not >>> part of GCC; check the version of the GNU binutils that you have >>> installed. If those instructions are not valid, then you need to >>> change your source. >> >> Thanks Ian. I'm using binutils-2.22-r1. Do you happen to know which >> version of binutils should support thumb2? > > Hi Grant. I'm pretty sure this was fixed by: > > commit c0d796cf810a84f10703c0390f7b1c5887b837c9 > Author: Nick Clifton > Date: Wed Jun 13 14:18:59 2012 + > > PR gas/12698 > * config/tc-arm.c (do_t_mrs): Do not require an m-profile > architecure when assembling for all archiectures. > (do_t_msr): Likewise. > > which will be in the upcoming binutils 2.23. Debian/Ubuntu carry this > as a patch on top of their 2.22. > > -- Michael Thanks a lot Michael. I'm having trouble compiling 2.23 on Gentoo but I'm working on it. - Grant
asan library
Dear steering committee, To support address-sanitizer feature: http://code.google.com/p/address-sanitizer/ in gcc, we need to drop in a foreign library into gcc repository. The attached is the README.gcc and a copy of the license file. A sample library source file head is also shown here. Does it look ok ? thanks, David //===-- asan_globals.cc ---===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // //===--===// // // This file is a part of AddressSanitizer, an address sanity checker. // // Handle globals. //===--===// #include "asan_interceptors.h" #include "asan_interface.h" #include "asan_internal.h" #include "asan_lock.h" #include "asan_mapping.h" #include "asan_stack.h" #include "asan_stats.h" #include "asan_thread.h" #include Index: libasan/LICENSE.TXT === --- libasan/LICENSE.TXT (revision 0) +++ libasan/LICENSE.TXT (revision 0) @@ -0,0 +1,97 @@ +== +compiler_rt License +== + +The compiler_rt library is dual licensed under both the University of Illinois +"BSD-Like" license and the MIT license. As a user of this code you may choose +to use it under either license. As a contributor, you agree to allow your code +to be used under both. + +Full text of the relevant licenses is included below. + +== + +University of Illinois/NCSA +Open Source License + +Copyright (c) 2009-2012 by the contributors listed in CREDITS.TXT + +All rights reserved. + +Developed by: + +LLVM Team + +University of Illinois at Urbana-Champaign + +http://llvm.org + +Permission is hereby granted, free of charge, to any person obtaining a copy of +this software and associated documentation files (the "Software"), to deal with +the Software without restriction, including without limitation the rights to +use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies +of the Software, and to permit persons to whom the Software is furnished to do +so, subject to the following conditions: + +* Redistributions of source code must retain the above copyright notice, + this list of conditions and the following disclaimers. + +* Redistributions in binary form must reproduce the above copyright notice, + this list of conditions and the following disclaimers in the + documentation and/or other materials provided with the distribution. + +* Neither the names of the LLVM Team, University of Illinois at + Urbana-Champaign, nor the names of its contributors may be used to + endorse or promote products derived from this Software without specific + prior written permission. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS +FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE +SOFTWARE. + +== + +Copyright (c) 2009-2012 by the contributors listed in CREDITS.TXT + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. + +== +Copyrights and Licenses for Third Party Software Distributed with LLVM: +===
gcc-4.6-20121019 is now available
Snapshot gcc-4.6-20121019 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121019/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 192623 You'll find: gcc-4.6-20121019.tar.bz2 Complete GCC MD5=d54898c9837f89292dd31bb32e1db5e1 SHA1=0eccc2ce29a82bf3dea50a638d655d88798684f7 Diffs from 4.6-20121012 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote:
>
> [Crossposted to both GCC and Clang dev lists]
>
> Hi,
>
> One issue facing library authors wanting to use C++11's constexpr feature is
> that the same implementation must be provided for both the case of function
> invocation substitution and for execution at runtime. Due to the constraints
> on constexpr function definitions, this can force an implementation of a
> library function to be inefficient. To counteract this, I'd like to propose
> the addition of a builtin:
>
> bool __builtin_constexpr_p()
>
> This builtin would only be supported within constexpr function definitions.
> If the containing function is undergoing function invocation substitution, it
> returns true. Otherwise, it returns false. Hence we can implement library
> functions with a pattern like:
>
> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
> q+1, n-1);
> }
> __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
> const char *q, size_t n) {
> return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) : strncmp(p,
> q, n);
> }
>
> Does this seem reasonable?
Yes, especially the primary functionality. However, I have some
concerns about the interface. Let me hypothesize a different
interface:
This stays the same...
> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1,
> n-1);
> }
But here we do something different on the actual declaration:
>
> [[constexpr_alias(constexpr_strncmp)]]
> int strncmp(const char *p, const char *q, size_t n);
When parsing the *declaration* of this function, we lookup the
function name passed to constexpr_alias. We must find a constexpr
function with an identical signature. Then, at function invocation
substitution of strncmp, we instead substitute the body of
constexpr_strncmp.
This seems more direct (no redirection in the code), and it also
provides a specific advantage of allowing this to be easily added to
an existing declaration in a declaration-only header file without
impacting or changing the name of the runtime executed body or
definition.
-Chandler
PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail client.
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Fri, Oct 19, 2012 at 10:53 PM, Chandler Carruth wrote:
>
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith
> wrote:
> >
> > [Crossposted to both GCC and Clang dev lists]
> >
> > Hi,
> >
> > One issue facing library authors wanting to use C++11's constexpr
> > feature is that the same implementation must be provided for both the case
> > of function invocation substitution and for execution at runtime. Due to the
> > constraints on constexpr function definitions, this can force an
> > implementation of a library function to be inefficient. To counteract this,
> > I'd like to propose the addition of a builtin:
> >
> > bool __builtin_constexpr_p()
> >
> > This builtin would only be supported within constexpr function
> > definitions. If the containing function is undergoing function invocation
> > substitution, it returns true. Otherwise, it returns false. Hence we can
> > implement library functions with a pattern like:
> >
> > constexpr int constexpr_strncmp(const char *p, const char *q, size_t
> > n) {
> > return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 :
> > constexpr_strncmp(p+1, q+1, n-1);
> > }
> > __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
> > const char *q, size_t n) {
> > return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) :
> > strncmp(p, q, n);
> > }
> >
> > Does this seem reasonable?
>
>
> Yes, especially the primary functionality. However, I have some
> concerns about the interface. Let me hypothesize a different
> interface:
>
> This stays the same...
> > constexpr int constexpr_strncmp(const char *p, const char *q, size_t n)
> > {
> > return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
> > q+1, n-1);
> > }
>
>
> But here we do something different on the actual declaration:
> >
> > [[constexpr_alias(constexpr_strncmp)]]
> > int strncmp(const char *p, const char *q, size_t n);
>
>
> When parsing the *declaration* of this function, we lookup the
> function name passed to constexpr_alias. We must find a constexpr
> function with an identical signature. Then, at function invocation
> substitution of strncmp, we instead substitute the body of
> constexpr_strncmp.
>
> This seems more direct (no redirection in the code), and it also
> provides a specific advantage of allowing this to be easily added to
> an existing declaration in a declaration-only header file without
> impacting or changing the name of the runtime executed body or
> definition.
I really like this approach.
> -Chandler
>
> PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail
> client.
(Likewise)
Re: C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Saturday, October 20, 2012 7:50 AM, Chandler Carruth wrote:
[...snip...] Let me hypothesize a different interface:
This stays the same...
constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
q+1, n-1);
}
But here we do something different on the actual declaration:
[[constexpr_alias(constexpr_strncmp)]]
int strncmp(const char *p, const char *q, size_t n);
When parsing the *declaration* of this function, we lookup the function
name passed to constexpr_alias. We must find a constexpr function with an
identical signature. Then, at function invocation substitution of strncmp,
we instead substitute the body of constexpr_strncmp.
This seems more direct (no redirection in the code), and it also provides
a specific advantage of allowing this to be easily added to an existing
declaration in a declaration-only header file without impacting or
changing the name of the runtime executed body or definition.
I'd be very happy with this solution. I come across precisely the problem
raised by Richard on a very regular basis and have different workarounds
for both gcc and clang. I'd love to see something "standard" emerging!
For my side, I'd still like some way of declaring a function to be used
only in a constexpr environment, meaning that the compiler gives an error
up front when a function is then used in a non-constexpr environment. The
above proposal will provide a link-time error if the non-constexpr function
is not defined, which is half-way there. Perhaps using the "unavailable"
attribute in conjunction with "constexpr_alias" would be the compile-time
solution...
Cheers
Andy
