Re: Question about bitsizetype
On Wed, May 9, 2012 at 10:52 PM, William J. Schmidt
wrote:
> On Wed, 2012-05-09 at 13:47 -0700, Andrew Pinski wrote:
>> On Wed, May 9, 2012 at 1:36 PM, William J. Schmidt
>> wrote:
>> > Greetings,
>> >
>> > I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
>> > ran into an issue with bitsizetype. I have a patch that fixes the
>> > problem, but I'm not yet convinced it's the right fix. I'm hoping
>> > someone here can help me sort it out.
>> >
>> > The problem occurs when compiling some Java code at -O3. The symptom is
>> > a segv during predictive commoning. The problem comes when analyzing a
>> > data dependence between two field references. The access functions for
>> > the data refs are determined in tree-data-ref.c: dr_analyze_indices ():
>> >
>> > else if (TREE_CODE (ref) == COMPONENT_REF
>> > && TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) ==
>> > RECORD_TYPE)
>> > {
>> > /* For COMPONENT_REFs of records (but not unions!) use the
>> > FIELD_DECL offset as constant access function so we can
>> > disambiguate a[i].f1 and a[i].f2. */
>> > tree off = component_ref_field_offset (ref);
>> > off = size_binop (PLUS_EXPR,
>> > size_binop (MULT_EXPR,
>> > fold_convert (bitsizetype, off),
>> > bitsize_int (BITS_PER_UNIT)),
>> > DECL_FIELD_BIT_OFFSET (TREE_OPERAND (ref, 1)));
>> > VEC_safe_push (tree, heap, access_fns, off);
>> > }
>> >
>> > Note the use of bitsizetype. On a 64-bit target that defines TImode,
>> > this is apparently set to a 128-bit unsigned type, verified in gdb:
>> >
>> > (gdb) ptr bitsizetype
>> > > > size > > bitsizetype> constant 128>
>> > unit size > > 0xfffb5d7 sizetype> constant 16>
>> > align 128 symtab 0 alias set -1 canonical type 0xfffb5d700a8
>> > precision 128 min max > > 0xfffb5c82360 -1>>
>> >
>> > The problem arises in tree-data-ref.c: analyze_ziv_subscript:
>> >
>> > type = signed_type_for_types (TREE_TYPE (chrec_a), TREE_TYPE (chrec_b));
>> > chrec_a = chrec_convert (type, chrec_a, NULL);
>> > chrec_b = chrec_convert (type, chrec_b, NULL);
>> > difference = chrec_fold_minus (type, chrec_a, chrec_b);
>> >
>> > Both input types are bitsizetype of mode TImode. This call reduces to a
>> > call to tree.c: signed_or_unsigned_type_for ():
>> >
>> > return lang_hooks.types.type_for_size (TYPE_PRECISION (t), unsignedp);
>>
>> And that was fixed by not calling type_for_size with the following patch:
>> r185226 | rguenth | 2012-03-12 06:04:43 -0700 (Mon, 12 Mar 2012) | 9 lines
>>
>> 2012-03-12 Richard Guenther
>>
>> * tree.c (signed_or_unsigned_type_for): Use
>> build_nonstandard_integer_type.
>> (signed_type_for): Adjust documentation.
>> (unsigned_type_for): Likewise.
>> * tree-pretty-print.c (dump_generic_node): Use standard names
>> for non-standard integer types if available.
>> Thanks,
>> Andrew Pinski
>>
>>
> Ah, Andrew, you're a life-saver. Thanks!
The above is of course not exactly safe backporting ... (well, maybe it is,
I'm not sure ;)).
Another possibility would be to not use bitsizetype here and truncate
the result to sizetype (in case it fits, if it doesn't fit, give up - unlikely).
But well, maybe we should backport the above.
Richard.
> Bill
>
>>
>> >
>> > So this is the interesting point. We are calling back to the front end
>> > to find a type having the same precision as bitsizetype, in this case
>> > 128. The C lang hook handles this fine, but the Java one does not:
>> >
>> > tree
>> > java_type_for_size (unsigned bits, int unsignedp)
>> > {
>> > if (bits <= TYPE_PRECISION (byte_type_node))
>> > return unsignedp ? unsigned_byte_type_node : byte_type_node;
>> > if (bits <= TYPE_PRECISION (short_type_node))
>> > return unsignedp ? unsigned_short_type_node : short_type_node;
>> > if (bits <= TYPE_PRECISION (int_type_node))
>> > return unsignedp ? unsigned_int_type_node : int_type_node;
>> > if (bits <= TYPE_PRECISION (long_type_node))
>> > return unsignedp ? unsigned_long_type_node : long_type_node;
>> > return 0;
>> > }
>> >
>> > This returns zero, causing the first call to chrec_convert in
>> > analyze_ziv_subscript to segfault.
>> >
>> > I can cause the build to succeed with the following patch...
>> >
>> > Index: gcc/java/typeck.c
>> > ===
>> > --- gcc/java/typeck.c (revision 187158)
>> > +++ gcc/java/typeck.c (working copy)
>> > @@ -189,6 +189,12 @@ java_type_for_size (unsigned bits, int unsignedp)
>> > return unsignedp ? unsigned_int_type_node : int_type_node;
>> > if (bits <= TYPE_PRECISION (long_type_node))
>> > return unsignedp ? unsigned_long_type_node : long_type_node;
>> > + /* A 64-bit target with TImode requires 128-bit type defin
Re: Deprecate 32-bits HP-PA for GCC 4.8?
On Monday 07 May 2012 20:14:07 John David Anglin wrote: > On 5/7/2012 2:29 PM, Jeff Law wrote: > > On 05/07/2012 12:25 PM, John David Anglin wrote: > >> There is also a 32-bit netbsd port that a limited number of users are > >> still using. > > > > Do you know if they're using the open-sourced SOM linker or the 32 bit > > ELF stuff? > > ELF. yeah, we are using ELF. iirc, binutils is up-to-date wrt NetBSD on PA. The GCC stuff has never been contributed back. I'll try and fix that. Nick NetBSD/hp700 portmaster
Re: Merging gdc (GNU D Compiler) into gcc
On 11 April 2012 15:12, Iain Buclaw wrote: > On 4 October 2011 08:08, Iain Buclaw wrote: >> Hi, >> >> I've have received news from Walter Bright that the license of the D >> frontend has been assigned to the FSF. As the current maintainer of >> GDC, I would like to get this moved forward, starting with getting the >> ball rolling. What would need to be done? And what are the processes >> required? (ie: passing the project through to technical review.) >> >> The current home of GDC is here: https://bitbucket.org/goshawk/gdc >> > > > This has been rather long wait from my side of the pond (moving has > taken away quite some time from my side). But I'll be in a position > to begin discussion on arrangements this weekend for patches to be > submitted for GCC 4.8. > > I would be grateful if we could start and maintain discussions on > making this happen, and I hope some sort of agreement could be reached > by the end of the month. > I would like to give a gentle reminder of this. Where should I be posting the proposed patches to? The frontend and runtime library alone would be a few megabytes in size. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Merging gdc (GNU D Compiler) into gcc
On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw wrote: > On 11 April 2012 15:12, Iain Buclaw wrote: >> On 4 October 2011 08:08, Iain Buclaw wrote: >>> Hi, >>> >>> I've have received news from Walter Bright that the license of the D >>> frontend has been assigned to the FSF. As the current maintainer of >>> GDC, I would like to get this moved forward, starting with getting the >>> ball rolling. What would need to be done? And what are the processes >>> required? (ie: passing the project through to technical review.) >>> >>> The current home of GDC is here: https://bitbucket.org/goshawk/gdc >>> >> >> >> This has been rather long wait from my side of the pond (moving has >> taken away quite some time from my side). But I'll be in a position >> to begin discussion on arrangements this weekend for patches to be >> submitted for GCC 4.8. >> >> I would be grateful if we could start and maintain discussions on >> making this happen, and I hope some sort of agreement could be reached >> by the end of the month. >> > > I would like to give a gentle reminder of this. Where should I be > posting the proposed patches to? The frontend and runtime library > alone would be a few megabytes in size. Patches should be posted to gcc-patc...@gcc.gnu.org - for large drop-ins (sub-)tarballs are prefered. I suppose one way would be to merge GDC to a branch in the GCC SVN repository first. Note that gcc-patches has a size limit (not sure how large it was though), hosting files somewhere and providing links would be another way of providing them. Richard. > > Regards > > -- > Iain Buclaw > > *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Merging gdc (GNU D Compiler) into gcc
On 10 May 2012 10:48, Richard Guenther wrote: > On Thu, May 10, 2012 at 11:37 AM, Iain Buclaw wrote: >> On 11 April 2012 15:12, Iain Buclaw wrote: >>> On 4 October 2011 08:08, Iain Buclaw wrote: Hi, I've have received news from Walter Bright that the license of the D frontend has been assigned to the FSF. As the current maintainer of GDC, I would like to get this moved forward, starting with getting the ball rolling. What would need to be done? And what are the processes required? (ie: passing the project through to technical review.) The current home of GDC is here: https://bitbucket.org/goshawk/gdc >>> >>> >>> This has been rather long wait from my side of the pond (moving has >>> taken away quite some time from my side). But I'll be in a position >>> to begin discussion on arrangements this weekend for patches to be >>> submitted for GCC 4.8. >>> >>> I would be grateful if we could start and maintain discussions on >>> making this happen, and I hope some sort of agreement could be reached >>> by the end of the month. >>> >> >> I would like to give a gentle reminder of this. Where should I be >> posting the proposed patches to? The frontend and runtime library >> alone would be a few megabytes in size. > > Patches should be posted to gcc-patc...@gcc.gnu.org - for large > drop-ins (sub-)tarballs are prefered. I suppose one way would be > to merge GDC to a branch in the GCC SVN repository first. Note > that gcc-patches has a size limit (not sure how large it was though), > hosting files somewhere and providing links would be another > way of providing them. > > Richard. > Thanks, would it be best to split the frontend, library, and patches to gcc proper into three parts? To provide links provisionally, the current development repository is here: https://github.com/D-Programming-GDC/GDC -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Merging gdc (GNU D Compiler) into gcc
On 10 May 2012 11:52, Iain Buclaw wrote: > > Thanks, would it be best to split the frontend, library, and patches > to gcc proper into three parts? >From observing how other big projects got merged, I think it is better: 1) If you have anything that can be committed independently of gdc (like bug-fixes, cleanups, etc.), send those first as individual self-contained patches. This will reduce the delta. This will also give you a sense of the stylistic changes reviewers are more likely to complain about and fix them in your branch before presenting it for approval. 2) Next, for changes to various parts of GCC that are not independent of GDC, isolate changes by subsystem (see MAINTAINERS), then either produce a patch or, if too large, point how to get a diff of exactly those parts in a branch. Send it to gcc-patches and CC the relevant maintainers. This includes also splitting out changes to the shared build machinery and to the shared testsuite infrastructure. 3) Finally, once all those parts are approved, you will have to convince one or various global reviewers to go through the rest of the branch (FE proper, runtime and testcases) and ACK it. The merge of Go could be a good example to follow: http://gcc.gnu.org/ml/gcc/2010-10/msg00342.html It was finally committed here, so it "only" took two months for someone who is one of the few top-class experts in GCC, with decades of experience, so be patient and persevere: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00274.html You should probably also read this: http://gcc.gnu.org/onlinedocs/gccint/Front-End.html Cheers, Manuel.
Re: h8300-elf build broken
> style nits: It should be size_t(__len - __pos), and not
> (size_t)(__len - __pos). Same for the other hunk. Patch OK with
> those changes.
Committed that way. Thanks! Ok for 4.7 branch as well?
* include/bits/random.tcc (seed_seq::generate): Cast max()
operands to size_t to ensure a template match.
* include/std/bitset (_M_copy_from_ptr): Cast min() operands to
size_t to ensure a template match.
Index: include/std/bitset
===
--- include/std/bitset (revision 187375)
+++ include/std/bitset (working copy)
@@ -1374,13 +1374,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
void
bitset<_Nb>::
_M_copy_from_ptr(const _CharT* __s, size_t __len,
size_t __pos, size_t __n, _CharT __zero, _CharT __one)
{
reset();
- const size_t __nbits = std::min(_Nb, std::min(__n, __len - __pos));
+ const size_t __nbits = std::min(_Nb, std::min(__n, size_t(__len -
__pos)));
for (size_t __i = __nbits; __i > 0; --__i)
{
const _CharT __c = __s[__pos + __nbits - __i];
if (_Traits::eq(__c, __zero))
;
else if (_Traits::eq(__c, __one))
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 187375)
+++ include/bits/random.tcc (working copy)
@@ -2770,13 +2770,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: (__n >= 68) ? 7
: (__n >= 39) ? 5
: (__n >= 7) ? 3
: (__n - 1) / 2;
const size_t __p = (__n - __t) / 2;
const size_t __q = __p + __t;
- const size_t __m = std::max(__s + 1, __n);
+ const size_t __m = std::max(size_t(__s + 1), __n);
for (size_t __k = 0; __k < __m; ++__k)
{
_Type __arg = (__begin[__k % __n]
^ __begin[(__k + __p) % __n]
^ __begin[(__k - 1) % __n]);
i386-rtems (and elf?) broken
Hi Using today's source via git and targeting i386-rtems4.11, the build ends with this. I changed ASM_OUTPUT_ASCII in gcc/config/i386/i386elf.h to use "const char *" instead of "const unsigned char *" and the build continued. Does that look to be the correct change? If so, I will submit a patch for review g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/users/joel/test-gcc/gcc-git/gcc -I/users/joel/test-gcc/gcc-git/gcc/. -I/users/joel/test-gcc/gcc-git/gcc/../include -I/users/joel/test-gcc/gcc-git/gcc/../libcpp/include -I/users/joel/test-gcc/gcc-git/gcc/../libdecnumber -I/users/joel/test-gcc/gcc-git/gcc/../libdecnumber/dpd -I../libdecnumber /users/joel/test-gcc/gcc-git/gcc/dwarf2asm.c -o dwarf2asm.o In file included from ./tm.h:20:0, from /users/joel/test-gcc/gcc-git/gcc/dwarf2asm.c:25: /users/joel/test-gcc/gcc-git/gcc/dwarf2asm.c: In function ‘void dw2_asm_output_nstring(const char*, size_t, const char*, ...)’: /users/joel/test-gcc/gcc-git/gcc/config/elfos.h:412:55: error: invalid conversion from ‘const unsigned char*’ to ‘const char*’ [-fpermissive] default_elf_asm_output_limited_string ((FILE), (STR)) ^ /users/joel/test-gcc/gcc-git/gcc/config/elfos.h:412:55: note: in expansion of macro 'ASM_OUTPUT_LIMITED_STRING' default_elf_asm_output_limited_string ((FILE), (STR)) ^ /users/joel/test-gcc/gcc-git/gcc/config/i386/i386elf.h:76:8: note: expanded from here ASM_OUTPUT_LIMITED_STRING ((FILE), _ascii_bytes); \ ^ /users/joel/test-gcc/gcc-git/gcc/config/i386/i386elf.h:76:8: note: in expansion of macro 'ASM_OUTPUT_ASCII' ASM_OUTPUT_LIMITED_STRING ((FILE), _ascii_bytes); \ ^ /users/joel/test-gcc/gcc-git/gcc/dwarf2asm.c:334:7: note: expanded from here ASM_OUTPUT_ASCII (asm_out_file, str, len); ^ -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: h8300-elf build broken
On Thu, May 10, 2012 at 3:33 PM, DJ Delorie wrote: > >> style nits: It should be size_t(__len - __pos), and not >> (size_t)(__len - __pos). Same for the other hunk. Patch OK with >> those changes. > > Committed that way. Thanks! Ok for 4.7 branch as well? yes, it is. Thanks, -- Gaby
Re: h8300-elf build broken
> > Committed that way. Thanks! Ok for 4.7 branch as well? > > yes, it is. Thanks, Done!
gcc-4.5-20120510 is now available
Snapshot gcc-4.5-20120510 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120510/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 187385 You'll find: gcc-4.5-20120510.tar.bz2 Complete GCC MD5=930474ae9fbbcc8e5697d066dc95c510 SHA1=2841df36d53b071925cfcf2950d900bf32d8361c Diffs from 4.5-20120503 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.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.
Build problem with libgo runtime
I'm investigating another build failure for Fedora 17 (based on 4.7).
The failing compile from the build log is as follows:
/bin/sh ./libtool --tag=CC
--mode=compile
/builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/xgcc
-B/builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/
-B/usr/ppc64-redhat-linux/bin/ -B/usr/ppc64-redhat-linux/lib/ -isystem
/usr/ppc64-redhat-linux/include -isystem /usr/ppc64-redhat-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime
-I../../../libgo/../libffi/include -I../libffi/include -pthread -fexceptions
-fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../libgo/../libgcc -I ../../gcc/include -O2 -O3 -mtune=power7
-mcpu=power7 -g -fsigned-char -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c -o
proc.lo `test -f 'runtime/proc.c' || echo '../../../libgo/'`runtime/proc.c
The reported failure:
../../../libgo/runtime/proc.c: In function ‘__go_go’:
../../../libgo/runtime/proc.c:1323:8: error: variable ‘sp’ might be
clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
../../../libgo/runtime/proc.c:1324:9: error: variable ‘spsize’ might be
clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
cc1: all warnings being treated as errors
The declarations in question are:
byte *sp;
size_t spsize;
G * volatile newg; // volatile to avoid longjmp warning
What's interesting here is that I don't see a problem when compiling for
a 32-bit target. However, it's also apparent that making "newg"
volatile was deemed sufficient up till now, so I am wondering if there
is something about our build options/environment that could cause the
problem.
I can work around the problem with the following patch, but would
appreciate any insights into whether this should be necessary, and if
not, what we're doing "wrong."
Thanks!
Bill
*** proc.c.orig 2012-05-10 21:02:13.394995624 -0500
--- proc.c 2012-05-10 21:01:36.050994265 -0500
*** __go_go(void (*fn)(void*), void* arg)
*** 1323,1328
--- 1323,1330
byte *sp;
size_t spsize;
G * volatile newg; // volatile to avoid longjmp warning
+ byte * volatile vsp;
+ size_t volatile vspsize;
schedlock();
*** __go_go(void (*fn)(void*), void* arg)
*** 1363,1374
if(sp == nil)
runtime_throw("nil g->stack0");
getcontext(&newg->context);
! newg->context.uc_stack.ss_sp = sp;
#ifdef MAKECONTEXT_STACK_TOP
! newg->context.uc_stack.ss_sp += spsize;
#endif
! newg->context.uc_stack.ss_size = spsize;
makecontext(&newg->context, kickoff, 0);
newprocreadylocked(newg);
--- 1365,1379
if(sp == nil)
runtime_throw("nil g->stack0");
+ vsp = sp;
+ vspsize = spsize;
+
getcontext(&newg->context);
! newg->context.uc_stack.ss_sp = vsp;
#ifdef MAKECONTEXT_STACK_TOP
! newg->context.uc_stack.ss_sp += vspsize;
#endif
! newg->context.uc_stack.ss_size = vspsize;
makecontext(&newg->context, kickoff, 0);
newprocreadylocked(newg);
