gcc/libcpp: non-UTF-8 source or execution encodings?
libcpp/charset.c has a helpful introductory comment describingcharacter
sets, including the source and execution character sets.
libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for the
source character set, via:
#if HOST_CHARSET == HOST_CHARSET_ASCII
#define SOURCE_CHARSET "UTF-8"
#define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0x7e
#elif HOST_CHARSET == HOST_CHARSET_EBCDIC
#define SOURCE_CHARSET "UTF-EBCDIC"
#define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0xFF
#else
#error "Unrecognized basic host character set"
#endif
though libiberty's safe-ctype.c has:
# if HOST_CHARSET == HOST_CHARSET_EBCDIC
#error "FIXME: write tables for EBCDIC"
so presumably we only effectively support UTF-8 as the source char set.
Do we support any hosts for which the source character set is *not* UTF
-8?
Similarly, do we support any targets for which the execution character
set is *not* UTF-8?
This relates to the locations-within-string-literals patch I posted
here:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
("[PATCH] RFC: On-demand locations within string-literals"); that patch
currently has an assumption that the source encoding == execution
encoding, and I'd appreciate knowing a configuration for which this
isn't the case so I can test accordingly.
Thanks
Dave
Re: gcc/libcpp: non-UTF-8 source or execution encodings?
On Tue, Jul 19, 2016 at 12:05 PM, David Malcolm wrote:
> libcpp/charset.c has a helpful introductory comment describingcharacter
> sets, including the source and execution character sets.
>
> libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for the
> source character set, via:
>
> #if HOST_CHARSET == HOST_CHARSET_ASCII
> #define SOURCE_CHARSET "UTF-8"
> #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0x7e
> #elif HOST_CHARSET == HOST_CHARSET_EBCDIC
> #define SOURCE_CHARSET "UTF-EBCDIC"
> #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0xFF
> #else
> #error "Unrecognized basic host character set"
> #endif
>
> though libiberty's safe-ctype.c has:
>
> # if HOST_CHARSET == HOST_CHARSET_EBCDIC
> #error "FIXME: write tables for EBCDIC"
>
> so presumably we only effectively support UTF-8 as the source char set.
>
> Do we support any hosts for which the source character set is *not* UTF
> -8?
>
> Similarly, do we support any targets for which the execution character
> set is *not* UTF-8?
>
> This relates to the locations-within-string-literals patch I posted
> here:
> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
> ("[PATCH] RFC: On-demand locations within string-literals"); that patch
> currently has an assumption that the source encoding == execution
> encoding, and I'd appreciate knowing a configuration for which this
> isn't the case so I can test accordingly.
I believe that the GCC z/TPF configuration uses EBCDIC. There also is
the on-again off-again i370 port.
Thanks, David
[llvm-dev] LLVM Cauldron 2016 (Sep 8th, Hebden Bridge, UK) registration and call for papers now open
We are pleased to announce the first LLVM Cauldron, to be held on Thursday September 8th 2016 in Hebden Bridge, UK. This is the day before the GNU Tools Cauldron being held at the same venue, so we hope to take advantage of the high concentration of compiler enthusiasts and to encourage lots of cross-pollination between communities. This will be a one-day conference with a single talks track and a space for breakout sessions, birds of a feather session, and tutorials. For those that want to give a brief description of their work, there will be lightning talks. The meeting is free to attend and open to anyone whether a hobbyist, from academia, or from industry, and regardless of previous experience with LLVM. We welcome proposals for: * technical presentations (25 minutes) * lightning talks (5 minutes) * birds of a feather sessions (~30 minutes) * tutorials (60 minutes) Please register to attend and consider submitting a talk. Links: * More information http://llvm.org/devmtg/2016-09/ * Registration http://goo.gl/forms/IqKzBtIYJIgEZf3G2 * Talk submission http://goo.gl/forms/iFEPwjjLhNHeFeru2 Best wishes, The LLVM Cauldron 2016 team
Re: [gimplefe] hacking pass manager
On 19 July 2016 at 11:04, Richard Biener wrote:
> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm
> wrote:
>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
>>> On 19 July 2016 at 00:25, Richard Biener
>>> wrote:
>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
>>> > prasad.ghan...@gmail.com> wrote:
>>> > > On 15 July 2016 at 16:13, Richard Biener <
>>> > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>> > > > wrote:
>>> > > > > On 8 July 2016 at 13:13, Richard Biener <
>>> > > > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>>> > > wrote:
>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener
>>> > > wrote:
>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>> > > wrote:
>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener
>>> > > wrote:
>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>> > > > > > > > > > wrote:
>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
>>> > > wrote:
>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
>>> > > > > > > > > > > > Prathamesh Kulkarni
>>> > > wrote:
>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
>>> > >
>>> > > > > > > > > > > > > wrote:
>>> > > > > > > > > > > > > > Hi,
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > I tried hacking pass manager to execute
>>> > > > > > > > > > > > > > only given passes.
>>> > > For this I
>>> > > > > > > > > > > > > > am adding new member as opt_pass
>>> > > > > > > > > > > > > > *custom_pass_list to the
>>> > > function
>>> > > > > > > > > > > > > > structure to store passes need to execute
>>> > > > > > > > > > > > > > and providing the
>>> > > > > > > > > > > > > > custom_pass_list to execute_pass_list()
>>> > > > > > > > > > > > > > function instead of
>>> > > all
>>> > > > > > > > > > > > > passes
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > for test case like-
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
>>> > > > > > > > > > > > > > -fre1")) foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > > a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will execute only given passes i.e. ccp1
>>> > > > > > > > > > > > > > and fre1 pass
>>> > > on the
>>> > > > > > > > > > > > > function
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > and for test case like -
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (startwith ("tree-ccp1"))
>>> > > > > > > > > > > > > > foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > > a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will act as a entry point to the
>>> > > > > > > > > > > > > > pipeline and will
>>> > > execute passes
>>> > > > > > > > > > > > > > starting from given pass.
>>> > > > > > > > > > > > > Bike-shedding:
>>> > > > > > > > > > > > > Would it make sense to have syntax for
>>> > > > > > > > > > > > > defining pass ranges
>>> > > to execute
>>> > > > > > > > > > > > > ?
>>> > > > > > > > > > > > > for instance:
>>> > > > > > > > > > > > > void __GIMPLE(execute (pass_start :
>>> > > > > > > > > > > > > pass_end))
>>> > > > > > > > > > > > > which would execute all the passes within
>>> > > > > > > > > > > > > range [pass_start,
>>> > > pass_end],
>>> > > > > > > > > > > > > which would be convenient if the range is
>>> > > > > > > > > > > > > large.
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > But it would rely on a particular pass
>>> > > > > > > > > > > > pipeline, f.e.
>>> > > pass-start appearing before pass-end.
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > Currently control doesn't work 100% as it only
>>> > > > > > > > > > > > replaces
>>> > > all_optimizations but not lowering passes or early opts, nor IPA
>>> > > opts.
>>> > > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > > > Each pass needs GIMPLE in some specific form. So
>>> > > > > > > > > > > I am letting
>>> > > lowering
>>> > > > > > > > > > > and early opt passes to execute. I think we have
>>> > > > > > > > > > > to execute
>>> > > some
>>> > > > > > > > > > > passes (like cfg) anyway to represent GIMPLE into
>>> > > > > > > > > > > proper form
>>> > > > > > > > > >
>>> > > > > > > > > > Yes, that's true. Note that early opt passes only
>>> > > > > > > > > > optimize but
>>> > > we need
>>> > > > > > > > > > pass_build_ssa_passes at least (for into-SSA). For
>>> > > > > > > > > > proper
>>> > > unit-testing
>>> > > > > > > > > > of GIMPLE passes we do need to guard off early opts
>>> > > > > > > > > > somehow
>>> > > > > > > > >
gcc-5-20160719 is now available
Snapshot gcc-5-20160719 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160719/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 238500 You'll find: gcc-5-20160719.tar.bz2 Complete GCC MD5=a6aec60301c2d5136b7b06645ca14661 SHA1=5269e79993ab1bddbccb9fb2c8b779cafad07f8c Diffs from 5-20160712 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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: gcc/libcpp: non-UTF-8 source or execution encodings?
On Tue, 2016-07-19 at 12:24 -0400, David Edelsohn wrote:
> On Tue, Jul 19, 2016 at 12:05 PM, David Malcolm
> wrote:
> > libcpp/charset.c has a helpful introductory comment
> > describingcharacter
> > sets, including the source and execution character sets.
> >
> > libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for
> > the
> > source character set, via:
> >
> > #if HOST_CHARSET == HOST_CHARSET_ASCII
> > #define SOURCE_CHARSET "UTF-8"
> > #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0x7e
> > #elif HOST_CHARSET == HOST_CHARSET_EBCDIC
> > #define SOURCE_CHARSET "UTF-EBCDIC"
> > #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0xFF
> > #else
> > #error "Unrecognized basic host character set"
> > #endif
> >
> > though libiberty's safe-ctype.c has:
> >
> > # if HOST_CHARSET == HOST_CHARSET_EBCDIC
> > #error "FIXME: write tables for EBCDIC"
> >
> > so presumably we only effectively support UTF-8 as the source char
> > set.
> >
> > Do we support any hosts for which the source character set is *not*
> > UTF
> > -8?
> >
> > Similarly, do we support any targets for which the execution
> > character
> > set is *not* UTF-8?
> >
> > This relates to the locations-within-string-literals patch I posted
> > here:
> > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
> > ("[PATCH] RFC: On-demand locations within string-literals"); that
> > patch
> > currently has an assumption that the source encoding == execution
> > encoding, and I'd appreciate knowing a configuration for which this
> > isn't the case so I can test accordingly.
>
> I believe that the GCC z/TPF configuration uses EBCDIC. There also
> is
> the on-again off-again i370 port.
>
> Thanks, David
Thanks. Looks like the triple for the former is "s390x-ibm-tpf"; I'm
experimenting with that as the target.
Is there any accessible hardware for these? I don't see them in the
gcc compile farm.
Dave
Re: gcc/libcpp: non-UTF-8 source or execution encodings?
Hi, David
I don't believe that hardware easily is available. We probably could
arrange for access, if it is necessary, but it is not accessible
through the IBM Community Development system for Linux on z Systems
because this isn't Linux-based. GCC on the system is not self-hosting
-- I believe that GCC only is used as a cross-compiler.
Thanks, David
On Tue, Jul 19, 2016 at 3:39 PM, David Malcolm wrote:
> On Tue, 2016-07-19 at 12:24 -0400, David Edelsohn wrote:
>> On Tue, Jul 19, 2016 at 12:05 PM, David Malcolm
>> wrote:
>> > libcpp/charset.c has a helpful introductory comment
>> > describingcharacter
>> > sets, including the source and execution character sets.
>> >
>> > libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for
>> > the
>> > source character set, via:
>> >
>> > #if HOST_CHARSET == HOST_CHARSET_ASCII
>> > #define SOURCE_CHARSET "UTF-8"
>> > #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0x7e
>> > #elif HOST_CHARSET == HOST_CHARSET_EBCDIC
>> > #define SOURCE_CHARSET "UTF-EBCDIC"
>> > #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0xFF
>> > #else
>> > #error "Unrecognized basic host character set"
>> > #endif
>> >
>> > though libiberty's safe-ctype.c has:
>> >
>> > # if HOST_CHARSET == HOST_CHARSET_EBCDIC
>> > #error "FIXME: write tables for EBCDIC"
>> >
>> > so presumably we only effectively support UTF-8 as the source char
>> > set.
>> >
>> > Do we support any hosts for which the source character set is *not*
>> > UTF
>> > -8?
>> >
>> > Similarly, do we support any targets for which the execution
>> > character
>> > set is *not* UTF-8?
>> >
>> > This relates to the locations-within-string-literals patch I posted
>> > here:
>> > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
>> > ("[PATCH] RFC: On-demand locations within string-literals"); that
>> > patch
>> > currently has an assumption that the source encoding == execution
>> > encoding, and I'd appreciate knowing a configuration for which this
>> > isn't the case so I can test accordingly.
>>
>> I believe that the GCC z/TPF configuration uses EBCDIC. There also
>> is
>> the on-again off-again i370 port.
>>
>> Thanks, David
>
> Thanks. Looks like the triple for the former is "s390x-ibm-tpf"; I'm
> experimenting with that as the target.
>
> Is there any accessible hardware for these? I don't see them in the
> gcc compile farm.
>
> Dave
Re: gcc/libcpp: non-UTF-8 source or execution encodings?
David Edelsohn writes: > GCC on the system is not self-hosting -- I believe that GCC only is > used as a cross-compiler. I can confirm this - GCC for TPF is always a cross compiler, it never runs *on* a TPF system.
ubsan and Dejagnu not having a big enough buffer in some cases
Hi, I noticed that ubsan testsuite sometimes has failures due to dejagnu buffer gets full and we no longer match on the output any more. As you can see from the .log file: /data1/jenkins/workspace/BuildThunderX_native_gcc_6/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c:88:3: runtime error: value iPASS: c-c++-common/ubsan/float-cast-overflow-1.c -O0 execution test This looks like I am using a much bigger path name than what most people use which is why I am seeing it fail. Is there a way to increase the buffer for dejagnu/expect so dg-output matches? Looks like it is limited to 500k (if I read dejagnu code correctly). Or can/should we split up float-cast-overflow-1.c instead? Thanks, Andrew Pinski
Re: ubsan and Dejagnu not having a big enough buffer in some cases
On July 20, 2016 2:01:18 AM GMT+02:00, Andrew Pinski wrote: >Hi, > I noticed that ubsan testsuite sometimes has failures due to dejagnu >buffer gets full and we no longer match on the output any more. >As you can see from the .log file: >/data1/jenkins/workspace/BuildThunderX_native_gcc_6/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c:88:3: >runtime error: value iPASS: c-c++-common/ubsan/float-cast-overflow-1.c > -O0 execution test > >This looks like I am using a much bigger path name than what most >people use which is why I am seeing it fail. Is there a way to >increase the buffer for dejagnu/expect so dg-output matches? Looks >like it is limited to 500k (if I read dejagnu code correctly). > >Or can/should we split up float-cast-overflow-1.c instead? I see this for some of the larger C frontend tests with lots of expected errors/warnings as well. Richard. > >Thanks, >Andrew Pinski
