Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Aug 9, 2014, at 9:55 AM, Chen Gang wrote: >> > > Excuse me, I can not find it with `find ./ | grep "\.sum$”` Then you didn’t do a test suite run. make check will create .sum files. Try cd gcc && make check. Then in testsuite/gcc/gcc.sum there will be a file. > After comparing, should the related ".sum" files be the same (same means > pass checking)? No, use contrib/compare_tests before_dir after_dir :-) If you _save_off the .sum files, you can use the places where you same them off. If you use two trees, you can just use them directly (no saving off). where the two are the build directories that you did a make check in. The output will be in simple english and should be readily understandable.
RE: [PATCH mips] Pass -msoft-float/-mhard-float flags to GAS
Matthew Fortune writes:
> Moore, Catherine writes:
> > > -Original Message-
> > > From: Steve Ellcey [mailto:sell...@mips.com]
> > > Sent: Friday, August 08, 2014 3:42 PM
> > > To: Moore, Catherine; matthew.fort...@imgtec.com; echri...@gmail.com;
> > >
> > > 2014-08-08 Steve Ellcey
> > >
> > > * config/mips/mips.h (ASM_SPEC): Pass float options to assembler.
> > >
> > > diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
> > > 8d7a09f..9a15287 100644
> > > --- a/gcc/config/mips/mips.h
> > > +++ b/gcc/config/mips/mips.h
> > > @@ -1187,6 +1187,8 @@ struct mips_cpu_info { %{mshared} %{mno-
> > > shared} \ %{msym32} %{mno-sym32} \ %{mtune=*} \
> > > +%{mhard-float} %{msoft-float} \
> > > +%{msingle-float} %{mdouble-float} \
> > > %(subtarget_asm_spec)"
> > >
> > > /* Extra switches sometimes passed to the linker. */
> > >
> >
> > Hi Steve,
> > The patch itself looks okay, but perhaps a question for Matthew.
> > Does the fact that the assembler requires -msoft-float even if .set
> > softfloat is present in the .s file deliberate behavior?
>
> The assembler requires -msoft-float if .gnu_attribute 4,3 is given. I.e.
> the
> overall module options must match the ABI which has been specified. .set
> directives can still be used to override the 'current' options and be
> inconsistent with the overall module and/or .gnu_attribute setting.
>
> > I don't have a problem with passing along the *float* options to gas, but
> > would hope that the .set options were honored as well.
>
> Yes they should be.
I forgot to add that there will be some side effects to this patch which are
not ideal but also unavoidable. The main one I know of is the MIPS Linux
kernel which is compiled as soft-float as there must be an absolute guarantee
that there is no floating point register usage. However, there is assembly
code which uses the floating-point registers for context switches and these
modules have not been set up to use .set hardfloat. This means that all
existing kernel releases will not build with the new compiler. I have
asked some of the MIPS kernel developers to apply fixes to the relevant files
and back-port to any supported release. The code has always been notionally
wrong but never detected as the assembler did not know that it was assembling
soft-float code so allowed FP instructions. The fixed code will build with
old and new tools.
Similar issues will arise if anything is compiled as single-float but is
using double-precision instructions currently. The fixes are simple and it is
arguably an improvement to such code bases to find these issues and add
appropriate .set directives to account for the special usage.
Matthew
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/10/2014 04:03 PM, Mike Stump wrote: > On Aug 9, 2014, at 9:55 AM, Chen Gang wrote: >>> >> >> Excuse me, I can not find it with `find ./ | grep "\.sum$”` > > Then you didn’t do a test suite run. make check will create .sum files. Try > cd gcc && make check. Then in testsuite/gcc/gcc.sum there will be a file. > OK, thanks, I built it under individual directory "build-gcc", I guess your meaning is "cd ./build-gcc/gcc && make check". If what I guess is incorrect, please let me know, thanks. >> After comparing, should the related ".sum" files be the same (same means >> pass checking)? > > No, use contrib/compare_tests before_dir after_dir :-) If you _save_off the > .sum files, you can use the places where you same them off. If you use two > trees, you can just use them directly (no saving off). > > where the two are the build directories that you did a make check in. The > output will be in simple english and should be readily understandable. > OK, Thanks, and I shall try to finish within next week (one building is still very long, although I have switched to mac book -- more higher performance machine). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c: Be sure 'errbuf' always be zero terminated.
I guess, I find the root cause:
In "gcc/libjava/configure", "--disable-core-jni" is hardcoded manually
for classpath with FIXME, then all related trying are useless. For me,
if have parameter "--enable-core-jni", need skip "--disable-core-jni".
The related information in gcc/libjava/configure:
6820 # Set up to configure Classpath.
6821 # FIXME: no supported way to pass args in autoconf.
6822 # Disable tool wrappers to avoid ltdl.h configure check.
6823 ac_configure_args="$ac_configure_args --disable-tool-wrappers"
6824 ac_configure_args="$ac_configure_args --disable-load-library"
6825 ac_configure_args="$ac_configure_args --${LIBGCJDEBUG}-debug"
6826 ac_configure_args="$ac_configure_args --enable-default-toolkit=$TOOLKIT"
6827 dir1=`cd $srcdir && pwd`
6828 dir2=`pwd`
6829 ac_configure_args="$ac_configure_args --with-vm-classes=$dir1:$dir2"
6830 ac_configure_args="$ac_configure_args --disable-core-jni"
6831 ac_configure_args="$ac_configure_args --disable-examples"
6832 ac_configure_args="$ac_configure_args --with-glibj=build"
On 08/10/2014 01:58 PM, Chen Gang wrote:
>
> On 8/3/14 13:50, Chen Gang wrote:
>> Excuse me, after tried, I still did not know hot to build the source
>> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni".
>> What I have done is:
>>
>> - ../gcc/configure --enable-core-jni --enable-languages=c,c++,java
>>make all-target-libjava
>>
>> - also try "../gcc/configure && make", but get same result.
>>
>> - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath
>>/native/jni/Makefile" manually, but still no effect.
>>
>> Welcome any ideas, suggestions or completions for it, thank.
>>
>> Also sorry, I did not finish sending patch v2 for it within 2014-08-03,
>> one excuse is: for each complete building, it needs 12-15 hours under my
>> laptop. So next, I shall buy a PC for it (also for linux kernel).
>>
>
> After try again, I can let it pass building, but I do not know whether
> it is enough for this patch:
>
> - ../gcc/configure --enable-core-jni && make
>
> - enable JNIDIRS in x86_64-unknown-linux-gnu/libjava/classpath/native/
>Makefile, manually.
>
> - then "make && make check" succeed with all related things are built.
>
> Before send patch v2 for it, I shall wait the confirmation from related
> members.
>
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
[PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable
Hi,
I am proposing another patch, this time to resolve PR60289. The issue in the bug
reported is, that a code like:
class(*), pointer :: P
allocate(character(20)::P)
is rejected by trunk's gfortran compiler. ja...@gcc.gnu.org proposed a first
patch in the PR, which my patch extends.
Motivation: Previously parsing of the type association to the unlimited
polymorphic variable P was not allowed and reported the error "Error:
Allocating p at (1) with type-spec requires the same character-length parameter
as in the declaration", after the errorneous error report was fixed by
janus' patch, an ICE occured in trans-stmt.c's gfc_trans_allocate()-routine.
The ICE reported in PR60289 is something different and does not occur in trunk
anymore. The ICE reported now boils down to line 5056 in trans-stmt.c:
tmp= al->expr->ts.u.cl->backend_decl;
The dereferencing of ts.u's cl member is valid only, when ts.type is of
BT_CHARACTER. With al->expr being an unlimited polymorphic type, the
backend_decl is not available in cl.
Although there is a backend_decl available in ts.u.derived, I was not able to
get it compatible for the fold_convert in the line following the assignment to
tmp:
gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE(tmp),
se_sz.expr));
My current solution therefore is to execute those two statements only, when
ts.type is of BT_CHARACTER.
Can someone explain what the fold_convert is doing in that specific place? I
assume that it is checking for and ensuring some type compatibility. Is there
some documentation available, explaining this? Is something similar needed for
the unlimited polymorphic variable?
Attached patch bootstraps and regtests ok on x86_64-unknown-linux-gnu. You
may need to have my patch for 60255 incorporated, too, for testing.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 15d8dab..15d3613 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -6878,7 +6878,9 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
goto failure;
}
- if (code->ext.alloc.ts.type == BT_CHARACTER && !e->ts.deferred)
+ /* Check F08:C632. */
+ if (code->ext.alloc.ts.type == BT_CHARACTER && !e->ts.deferred
+ && !UNLIMITED_POLY (e))
{
int cmp = gfc_dep_compare_expr (e->ts.u.cl->length,
code->ext.alloc.ts.u.cl->length);
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 547e9c1..575342d 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5046,7 +5046,7 @@ gfc_trans_allocate (gfc_code * code)
if (unlimited_char)
tmp = TREE_TYPE (gfc_typenode_for_spec (&code->expr3->ts));
else
- tmp = TREE_TYPE (gfc_typenode_for_spec (&al->expr->ts));
+ tmp = TREE_TYPE (gfc_typenode_for_spec (&al->expr->ts));
tmp = TYPE_SIZE_UNIT (tmp);
memsz = fold_build2_loc (input_location, MULT_EXPR,
TREE_TYPE (tmp), tmp,
@@ -5061,10 +5061,14 @@ gfc_trans_allocate (gfc_code * code)
gfc_add_block_to_block (&se.pre, &se_sz.pre);
se_sz.expr = gfc_evaluate_now (se_sz.expr, &se.pre);
gfc_add_block_to_block (&se.pre, &se_sz.post);
- /* Store the string length. */
- tmp = al->expr->ts.u.cl->backend_decl;
- gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE (tmp),
- se_sz.expr));
+ /* Store the string length only when variable allocated is
+ a character array. */
+ if(al->expr->ts.type== BT_CHARACTER)
+ {
+ tmp= al->expr->ts.u.cl->backend_decl;
+ gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE(tmp),
+ se_sz.expr));
+}
tmp = TREE_TYPE (gfc_typenode_for_spec (&code->ext.alloc.ts));
tmp = TYPE_SIZE_UNIT (tmp);
memsz = fold_build2_loc (input_location, MULT_EXPR,
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90
new file mode 100644
index 000..070ba89
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+! Testing fix for
+! PR fortran/60289
+!
+program test
+implicit none
+
+class(*), pointer :: P
+
+allocate(character(20)::P)
+
+select type(P)
+type is (character(*))
+P ="some test string"
+if (P .ne. "some test string") then
+call abort()
+end if
+class default
+call abort()
+end select
+
+deallocate(P)
+end program test
+
[C PATCH] Diagnose predefined identifiers in pedantic mode
We weren't properly diagnosing neither the __func__ (introduced in C99),
nor the __FUNCTION__/__PRETTY_FUNCTION__ (GNU extension) predefined
identifiers. I believe we should; the compiler ought to have a
compile-time switch for turning off extensions.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-08-10 Marek Polacek
* c-parser.c (c_parser_postfix_expression) :
Add pedwarn.
(c_parser_postfix_expression) :
Likewise.
(c_parser_postfix_expression) : Likewise.
* gcc.dg/concat.c: Add dg-options.
* gcc.dg/func-outside-2.c: Add __extension__.
* gcc.dg/pr19967.c: Use -std=c99.
* gcc.dg/pr22458-1.c: Add dg-options.
* gcc.dg/pr33676.c: Add dg-options.
* gcc.dg/func-outside-2.c: New test.
* gcc.dg/gnu-predef-1.c: New test.
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index ca8577c..5f23379 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -7136,8 +7136,24 @@ c_parser_postfix_expression (c_parser *parser)
switch (c_parser_peek_token (parser)->keyword)
{
case RID_FUNCTION_NAME:
+ pedwarn (loc, OPT_Wpedantic, "ISO C does not support "
+ "%<__FUNCTION__%> predefined identifier");
+ expr.value = fname_decl (loc,
+ c_parser_peek_token (parser)->keyword,
+ c_parser_peek_token (parser)->value);
+ c_parser_consume_token (parser);
+ break;
case RID_PRETTY_FUNCTION_NAME:
+ pedwarn (loc, OPT_Wpedantic, "ISO C does not support "
+ "%<__PRETTY_FUNCTION__%> predefined identifier");
+ expr.value = fname_decl (loc,
+ c_parser_peek_token (parser)->keyword,
+ c_parser_peek_token (parser)->value);
+ c_parser_consume_token (parser);
+ break;
case RID_C99_FUNCTION_NAME:
+ pedwarn_c90 (loc, OPT_Wpedantic, "ISO C90 does not support "
+ "%<__func__%> predefined identifier");
expr.value = fname_decl (loc,
c_parser_peek_token (parser)->keyword,
c_parser_peek_token (parser)->value);
diff --git gcc/testsuite/gcc.dg/c90-func-1.c gcc/testsuite/gcc.dg/c90-func-1.c
index e69de29..5f171d3 100644
--- gcc/testsuite/gcc.dg/c90-func-1.c
+++ gcc/testsuite/gcc.dg/c90-func-1.c
@@ -0,0 +1,10 @@
+/* Test that we diagnose the __func__ predefined identifier in
+ C90 pedantic mode. */
+/* { dg-do compile } */
+/* { dg-options "-std=iso9899:1990 -pedantic-errors" } */
+
+void
+foo (void)
+{
+ const char *s = __func__; /* { dg-error " ISO C90 does not support
.__func__. predefined identifier" } */
+}
diff --git gcc/testsuite/gcc.dg/concat.c gcc/testsuite/gcc.dg/concat.c
index 0b9d6f6..e3bfd46 100644
--- gcc/testsuite/gcc.dg/concat.c
+++ gcc/testsuite/gcc.dg/concat.c
@@ -1,6 +1,7 @@
/* Copyright (C) 2001 Free Software Foundation, Inc. */
/* { dg-do compile } */
+/* { dg-options "" } */
/* Test we output an error for concatenation of artificial strings.
diff --git gcc/testsuite/gcc.dg/func-outside-2.c
gcc/testsuite/gcc.dg/func-outside-2.c
index be3b099..28ef6bc 100644
--- gcc/testsuite/gcc.dg/func-outside-2.c
+++ gcc/testsuite/gcc.dg/func-outside-2.c
@@ -4,6 +4,6 @@
/* { dg-do compile } */
/* { dg-options "-pedantic-errors" } */
-const char *a = __func__; /* { dg-error "'__func__' is not defined outside of
function scope" "undef" } */
-const char *b = __FUNCTION__;
-const char *c = __PRETTY_FUNCTION__;
+__extension__ const char *a = __func__; /* { dg-error "'__func__' is not
defined outside of function scope" "undef" } */
+__extension__ const char *b = __FUNCTION__;
+__extension__ const char *c = __PRETTY_FUNCTION__;
diff --git gcc/testsuite/gcc.dg/gnu-predef-1.c
gcc/testsuite/gcc.dg/gnu-predef-1.c
index e69de29..9c7eebf 100644
--- gcc/testsuite/gcc.dg/gnu-predef-1.c
+++ gcc/testsuite/gcc.dg/gnu-predef-1.c
@@ -0,0 +1,14 @@
+/* Test that we diagnose the __FUNCTION__ and the __PRETTY_FUNCTION__
+ predefined identifiers in pedantic mode. */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu11 -pedantic" } */
+
+void
+foo (void)
+{
+ const char *s;
+ s = __FUNCTION__; /* { dg-warning " ISO C does not support .__FUNCTION__.
predefined identifier" } */
+ s = __PRETTY_FUNCTION__; /* { dg-warning " ISO C does not support
.__PRETTY_FUNCTION__. predefined identifier" } */
+ s = __extension__ __FUNCTION__;
+ s = __extension__ __PRETTY_FUNCTION__;
+}
diff --git gcc/testsuite/gcc.dg/pr19967.c gcc/testsuite/gcc.dg/pr19967.c
index 85afeaf..68c7e1c 100644
--- gcc/testsuite/gcc.dg/pr19967.c
+++ gcc/testsuite/gcc.dg/pr19967.c
@@ -4,7 +4,7 @@
be const char *. */
/* { dg-do compile } */
-/* { dg-options "-pedantic" } */
+/* { dg-options "-pedantic -std=c99" } */
char *strchr(const char *, int);
char *strrchr(const char *, int);
diff --git gcc/testsuite/g
Re: [C PATCH] Diagnose predefined identifiers in pedantic mode
On Sun, Aug 10, 2014 at 05:16:27PM +0200, Marek Polacek wrote: > We weren't properly diagnosing neither the __func__ (introduced in C99), > nor the __FUNCTION__/__PRETTY_FUNCTION__ (GNU extension) predefined > identifiers. I believe we should; the compiler ought to have a > compile-time switch for turning off extensions. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? And probably I should introduce something like -Wpredefined-identifiers...
RE: [PATCH mips] Pass -msoft-float/-mhard-float flags to GAS
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Saturday, August 09, 2014 3:00 PM
> To: Moore, Catherine; Steve Ellcey; echri...@gmail.com; GCC Patches
> Subject: RE: [PATCH mips] Pass -msoft-float/-mhard-float flags to GAS
>
> Moore, Catherine writes:
> > > -Original Message-
> > > From: Steve Ellcey [mailto:sell...@mips.com]
> > > Sent: Friday, August 08, 2014 3:42 PM
> > > To: Moore, Catherine; matthew.fort...@imgtec.com;
> > > echri...@gmail.com;
> > >
> > > 2014-08-08 Steve Ellcey
> > >
> > > * config/mips/mips.h (ASM_SPEC): Pass float options to assembler.
> > >
> > > diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
> > > 8d7a09f..9a15287 100644
> > > --- a/gcc/config/mips/mips.h
> > > +++ b/gcc/config/mips/mips.h
> > > @@ -1187,6 +1187,8 @@ struct mips_cpu_info { %{mshared} %{mno-
> > > shared} \ %{msym32} %{mno-sym32} \ %{mtune=*} \
> > > +%{mhard-float} %{msoft-float} \
> > > +%{msingle-float} %{mdouble-float} \
> > > %(subtarget_asm_spec)"
> > >
> > > /* Extra switches sometimes passed to the linker. */
> > >
> >
> > Hi Steve,
> > The patch itself looks okay, but perhaps a question for Matthew.
> > Does the fact that the assembler requires -msoft-float even if .set
> > softfloat is present in the .s file deliberate behavior?
>
> The assembler requires -msoft-float if .gnu_attribute 4,3 is given. I.e. the
> overall module options must match the ABI which has been specified. .set
> directives can still be used to override the 'current' options and be
> inconsistent with the overall module and/or .gnu_attribute setting.
>
> > I don't have a problem with passing along the *float* options to gas,
> > but would hope that the .set options were honored as well.
>
> Yes they should be.
>
> > My short test indicated that the .set *float* options were being
> > ignored if the correct command line option wasn't present.
>
> I'm not certain what you are describing here. Could you confirm with an
> example just in case something is not working as expected?
I don't have the example that I tried yesterday, but I am not able to reproduce
today.
If I notice again, I will post the example.
Thanks,
Catherine
Re: [PATCH mips] Remove fp64 multilibs from mips-mti-* targets.
OK.
-eric
On Fri, Aug 8, 2014 at 1:07 PM, Steve Ellcey wrote:
> Here is another MIPS patch. This removes the fp64 multilib from the
> mips-mti-* targets. With the new fpxx we no longer want special fp64
> multilibs in the mti targets. Since it doesn't affect any other targets
> hopefully there is no objection to checking this in.
>
> Tested on mips-mti-linux-gnu and mips-mti-elf targets.
>
> OK to checkin?
>
> Steve Ellcey
> sell...@mips.com
>
>
>
> 2014-08-08 Steve Ellcey
>
> * config/mips/t-mti-elf (MULTILIB_OPTIONS): Remove fp64 multilib.
> (MULTILIB_DIRNAMES): Ditto.
> * config/mips/t-mti-elf (MULTILIB_OPTIONS): Ditto.
> * config/mips/t-mti-elf (MULTILIB_EXCEPTIONS): Ditto.
> * config/mips/t-mti-linux (MULTILIB_OPTIONS): Ditto.
> * config/mips/t-mti-linux (MULTILIB_DIRNAMES): Ditto.
> * config/mips/t-mti-linux (MULTILIB_EXCEPTIONS): Ditto.
> * config/mips/mti-linux.h (SYSROOT_SUFFIX_SPEC): Ditto.
>
> diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
> index db9896b..318e981 100644
> --- a/gcc/config/mips/mti-linux.h
> +++ b/gcc/config/mips/mti-linux.h
> @@ -20,7 +20,7 @@ along with GCC; see the file COPYING3. If not see
> /* This target is a multilib target, specify the sysroot paths. */
> #undef SYSROOT_SUFFIX_SPEC
> #define SYSROOT_SUFFIX_SPEC \
> -
> "%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}%{mfp64:/fp64}%{mnan=2008:/nan2008}"
> +
> "%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}%{mnan=2008:/nan2008}"
>
> #undef DRIVER_SELF_SPECS
> #define DRIVER_SELF_SPECS \
> diff --git a/gcc/config/mips/t-mti-elf b/gcc/config/mips/t-mti-elf
> index cd0a967..487a015 100644
> --- a/gcc/config/mips/t-mti-elf
> +++ b/gcc/config/mips/t-mti-elf
> @@ -19,8 +19,8 @@
> # The default build is mips32r2, hard-float big-endian. Add mips32,
> # soft-float, and little-endian variations.
>
> -MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL
> msoft-float/mfp64 mnan=2008
> -MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof fp64
> nan2008
> +MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL
> msoft-float mnan=2008
> +MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof nan2008
> MULTILIB_MATCHES = EL=mel EB=meb mips32r2=mips32r3 mips32r2=mips32r5
> mips64r2=mips64r3 mips64r2=mips64r5
>
> # The 64 bit ABI is not supported on the mips32 architecture.
> @@ -43,8 +43,3 @@ MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
>
> # We do not want nan2008 libraries for soft-float.
> MULTILIB_EXCEPTIONS += *msoft-float*/*mnan=2008*
> -
> -# -mfp64 libraries are only built for mips32r2 and not in mips16 mode.
> -MULTILIB_EXCEPTIONS += *mips32/*mfp64*
> -MULTILIB_EXCEPTIONS += *mips64*/*mfp64*
> -MULTILIB_EXCEPTIONS += *mips16*/*mfp64*
> diff --git a/gcc/config/mips/t-mti-linux b/gcc/config/mips/t-mti-linux
> index cd0a967..487a015 100644
> --- a/gcc/config/mips/t-mti-linux
> +++ b/gcc/config/mips/t-mti-linux
> @@ -19,8 +19,8 @@
> # The default build is mips32r2, hard-float big-endian. Add mips32,
> # soft-float, and little-endian variations.
>
> -MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL
> msoft-float/mfp64 mnan=2008
> -MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof fp64
> nan2008
> +MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL
> msoft-float mnan=2008
> +MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof nan2008
> MULTILIB_MATCHES = EL=mel EB=meb mips32r2=mips32r3 mips32r2=mips32r5
> mips64r2=mips64r3 mips64r2=mips64r5
>
> # The 64 bit ABI is not supported on the mips32 architecture.
> @@ -43,8 +43,3 @@ MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
>
> # We do not want nan2008 libraries for soft-float.
> MULTILIB_EXCEPTIONS += *msoft-float*/*mnan=2008*
> -
> -# -mfp64 libraries are only built for mips32r2 and not in mips16 mode.
> -MULTILIB_EXCEPTIONS += *mips32/*mfp64*
> -MULTILIB_EXCEPTIONS += *mips64*/*mfp64*
> -MULTILIB_EXCEPTIONS += *mips16*/*mfp64*
Make lto-streamer.h consistent wrt. symtab_node
Looking for something else, I noticed that the majority of references in lto-streamer.h were to symtab_node, whereas there were two left to symtab_node. This patch, tested for weeks on i386-unknown-freebsd10.0, makes things consistent. Applied as obvious. Gerald 2014-08-10 Gerald Pfeifer * lto-streamer.h (struct output_block::symbol): Change from struct symtab_node to plain symtab_node. (referenced_from_this_partition_p): Change first parameter from struct symtab_node to plain symtab_node. Index: lto-streamer.h === --- lto-streamer.h (revision 213804) +++ lto-streamer.h (working copy) @@ -636,7 +636,7 @@ /* The current symbol that we are currently serializing. Null if we are serializing something else. */ - struct symtab_node *symbol; + symtab_node *symbol; /* These are the last file and line that were seen in the stream. If the current node differs from these, it needs to insert @@ -826,7 +826,7 @@ lto_symtab_encoder_t); bool reachable_from_other_partition_p (struct cgraph_node *, lto_symtab_encoder_t); -bool referenced_from_this_partition_p (struct symtab_node *, +bool referenced_from_this_partition_p (symtab_node *, lto_symtab_encoder_t); bool reachable_from_this_partition_p (struct cgraph_node *, lto_symtab_encoder_t);
Re: [PATCH, ARM] Keep constants in register when expanding
On 8 August 2014 23:22, Ramana Radhakrishnan wrote:
> On Tue, Aug 5, 2014 at 10:31 AM, Zhenqiang Chen
> wrote:
>> Hi,
>>
>> For some large constants, ARM will split them during expanding, which
>> makes impossible to hoist them out the loop or shared by different
>> references (refer the test case in the patch).
>>
>> The patch keeps some constants in registers. If the constant can not
>> be optimized, the cprop and combine passes can optimize them as what
>> we do in current expand pass with
>>
>> define_insn_and_split "*arm_subsi3_insn"
>> define_insn_and_split "*arm_andsi3_insn"
>> define_insn_and_split "*iorsi3_insn"
>> define_insn_and_split "*arm_xorsi3"
>>
>> The patch does not modify addsi3 since the define_insn_and_split
>> "*arm_addsi3" is only valid when (reload_completed ||
>> !arm_eliminable_register (operands[1])). The cprop and combine passes
>> can not optimize the large constant if we put it in register, which
>> will lead to regression.
>>
>> For logic operators, the patch skips changes for constants:
>>
>> INTVAL (operands[2]) < 0 && const_ok_for_arm (-INTVAL (operands[2])
>>
>> since expand pass always uses "sign-extend" to get the value
>> (trunc_int_for_mode called from immed_wide_int_const) for rtl, and
>> logs show most negative values are UNSIGNED when they are TREE node.
>> And combine pass is smart enough to recover the negative value to
>> positive value.
>
> I am unable to verify any change in code generation for this testcase
> with and without the patch when I had a play with the patch.
>
> what gives ?
Thanks for trying the patch.
Do you add option -fno-gcse which is mentioned in dg-options " -O2
-fno-gcse "? Without it, there is no change for the testcase since
cprop pass will propagate the constant to AND expr (A patch to enhance
cprop pass was discussed at
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html).
In addition, if the constant can not be hoisted out the loop, later
combine pass can also optimize it. These (cprop and combine) are
reasons why the patch itself has little impact on current tests.
Test case in the patch is updated since it does not work for armv7-m.
Thanks!
-Zhenqiang
> Ramana
>
>
>>
>> Bootstrap and no make check regression on Chrome book.
>> For coremark, dhrystone and eembcv1, no any code size and performance
>> change on Cortex-M4.
>> No any file in CSiBE has code size change for Cortex-A15 and Cortex-M4.
>> No Spec2000 performance regression on Chrome book and dumped assemble
>> codes only show very few difference.
>>
>> OK for trunk?
>>
>> Thanks!
>> -Zhenqiang
>>
>> ChangeLog:
>> 2014-08-05 Zhenqiang Chen
>>
>> * config/arm/arm.md (subsi3, andsi3, iorsi3, xorsi3): Keep some
>> large constants in register other than split them.
>>
>> testsuite/ChangeLog:
>> 2014-08-05 Zhenqiang Chen
>>
>> * gcc.target/arm/maskdata.c: New test.
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index bd8ea8f..c8b3001 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -1162,9 +1162,16 @@
{
if (TARGET_32BIT)
{
- arm_split_constant (MINUS, SImode, NULL_RTX,
- INTVAL (operands[1]), operands[0],
- operands[2], optimize && can_create_pseudo_p ());
+ if (!const_ok_for_arm (INTVAL (operands[1]))
+ && can_create_pseudo_p ())
+ {
+ operands[1] = force_reg (SImode, operands[1]);
+ emit_insn (gen_subsi3 (operands[0], operands[1], operands[2]));
+ }
+ else
+ arm_split_constant (MINUS, SImode, NULL_RTX,
+INTVAL (operands[1]), operands[0], operands[2],
+optimize && can_create_pseudo_p ());
DONE;
}
else /* TARGET_THUMB1 */
@@ -2077,6 +2084,17 @@
emit_insn (gen_thumb2_zero_extendqisi2_v6 (operands[0],
operands[1]));
}
+ else if (!(const_ok_for_arm (INTVAL (operands[2]))
+ || const_ok_for_arm (~INTVAL (operands[2]))
+ /* zero_extendhi instruction is efficient enough. */
+ || INTVAL (operands[2]) == 0x
+ || (INTVAL (operands[2]) < 0
+ && const_ok_for_arm (-INTVAL (operands[2]
+ && can_create_pseudo_p ())
+ {
+ operands[2] = force_reg (SImode, operands[2]);
+ emit_insn (gen_andsi3 (operands[0], operands[1], operands[2]));
+ }
else
arm_split_constant (AND, SImode, NULL_RTX,
INTVAL (operands[2]), operands[0],
@@ -2882,9 +2900,20 @@
{
if (TARGET_32BIT)
{
- arm_split_constant (IOR, SImode, NULL_RTX,
- INTVAL (operands[2]), operands[0], operands[1],
- optimize && can_create_pseudo_p ());
+ if (!(const_ok_for_arm (INTVAL (operands[2]))
+ || (TARGET_THUMB2
+ && const_ok_for_arm (~INTVAL (operands[2])))
+ || (INTVAL (operands[2]) < 0
+ && const_ok_for_arm (-INTVAL (operands[2]
+ && can_create_pseudo_p ())
+ {
+ operands[2] = force_reg (SImode, operands[2]);
+ emit_insn (gen_iorsi3 (operands[0], operands[1], ope
Re: [PATCH 2/2] Move Asan instrumentation to sanopt pass
On 08/08/2014 12:09 PM, Jakub Jelinek wrote: > Ok, thanks. Done in r213807. -Y
Re: [PATCH 1/2] Support fnspecs for internal functions
> On 08/08/2014 12:07 PM, Jakub Jelinek wrote: > Ok, thanks, with a minor nit: Done in r213806 (the nit fixed in patch 2/2). -Y
Re: [GSoC] Elimination of CLooG library installation dependency
On 09/08/2014 12:05, Roman Gareev wrote: With just C++ code, Sven can help little. He has no knowledge about graphite internals. I want to ask him about correctness of ISL ASTs generated from mentioned isl_codegens. I am not sure if he can see it just like this. Do you now have a setup where you can just compile one of the attached files with graphite and everything else without and the code crashes? No, I don't. As I mentioned earlier, all the files from this test case individually produce object files which linked into the one executable, which cause “Segmentation fault (core dumped)” (It'll cause “Segmentation fault (core dumped)”, if we try to run it). I think that it's very difficult to detach the code, which would produce the executable and save the semantics of this big OOP project. Furthermore, there is a possibility that the detached code can produce no new useful information. I've found that if we try to compile any of the btCollisionWorld.cpp, btCollisionDispatcher.cpp and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the produced object file will lead to creation of the wrong executable (after linking with other object files generated by origin Graphite). I am confused. It seems you attached some kind of reduced version of btCollisionWorld.cpp? How did you obtain it? Did you compile and test with these versions? That's why I think that we could consider only, for example, btCollisionDispatcher.cpp. It contains only one scope, which is incorrectly processed by Graphite with the ISL code generator as the main generator. Why did you provide two files. I assume one should be sufficient to reproduce the crash, no? I've detached the code, which is used by Graphite to produce similar AST's. OK. But did you check if they actually segfault or fail? I think for the one file you choose, it would be interesting to look at the code generation input as well as the kernels generated by CLooG and isl. Maybe we can understand what is going on. Yes, exactly those that you provided. At a first look, I don't see anything obvious wrong, except that the huge modulo values, which arise from some integer wrapping support Sebastian added once for unsigned integers. I see two approaches you can take: 1) The easy one Disallow unsigned integers in the scop detection. I have doubts we can do anything good with those huge modulo constraints placed all over the generated code 2) Try to understand the test case I would try a couple of easy unsigned int loops to see if we can handle them properly. Something like: for (unsigned long i = 0; i < M; i++) A[i] += i; At best, we could even write your test case as such a loop and reproduce the bug outside of this huge C++ code. Maybe looking at the GIMPLE allows you to write C code that has similar behavior and where we could check the output? Tobias
Re: [PATCH i386 AVX512] [2/n] Introduce `-mavx512bw' switch
On Fri, Aug 8, 2014 at 2:31 PM, Kirill Yukhin wrote: > This patch introduces `-mavx512bw' compiler switch. > Bootstrapped. > > gcc/ > * common/config/i386/i386-common.c > (OPTION_MASK_ISA_AVX512BW_SET) : Define. > (OPTION_MASK_ISA_AVX512BW_UNSET): Ditto. > (OPTION_MASK_ISA_AVX512VL_UNSET) : Ditto. > (ix86_handle_option): Handle OPT_mavx512bw. > * config/i386/cpuid.h (bit_AVX512BW): Define. > * config/i386/driver-i386.c (host_detect_local_cpu): Detect avx512bw, > set -mavx512bw accordingly. > * config/i386/i386-c.c (ix86_target_macros_internal): Handle > OPTION_MASK_ISA_AVX512BW. > * config/i386/i386.c (ix86_target_string): Handle -mavx512bw. > (ix86_option_override_internal): Define PTA_AVX512BW, handle > PTA_AVX512BW and OPTION_MASK_ISA_AVX512BW. > (ix86_valid_target_attribute_inner_p): Handle OPT_mavx512bw. > * config/i386/i386.h (TARGET_AVX512BW): Define. > (TARGET_AVX512BW_P(x)): Ditto. > * config/i386/i386.opt: Add mavx512bw. > > Is it ok for trunk? OK with a small change below. Thanks, Uros. > diff --git a/gcc/common/config/i386/i386-common.c > b/gcc/common/config/i386/i386-common.c > index 3db1535..a2e94d5 100644 > --- a/gcc/common/config/i386/i386-common.c > +++ b/gcc/common/config/i386/i386-common.c > @@ -67,6 +67,8 @@ along with GCC; see the file COPYING3. If not see >(OPTION_MASK_ISA_AVX512ER | OPTION_MASK_ISA_AVX512F_SET) > #define OPTION_MASK_ISA_AVX512DQ_SET \ >(OPTION_MASK_ISA_AVX512DQ | OPTION_MASK_ISA_AVX512F_SET) > +#define OPTION_MASK_ISA_AVX512BW_SET \ > + (OPTION_MASK_ISA_AVX512BW | OPTION_MASK_ISA_AVX512F_SET) > #define OPTION_MASK_ISA_RTM_SET OPTION_MASK_ISA_RTM > #define OPTION_MASK_ISA_PRFCHW_SET OPTION_MASK_ISA_PRFCHW > #define OPTION_MASK_ISA_RDSEED_SET OPTION_MASK_ISA_RDSEED > @@ -159,6 +161,8 @@ along with GCC; see the file COPYING3. If not see > #define OPTION_MASK_ISA_AVX512PF_UNSET OPTION_MASK_ISA_AVX512PF > #define OPTION_MASK_ISA_AVX512ER_UNSET OPTION_MASK_ISA_AVX512ER > #define OPTION_MASK_ISA_AVX512DQ_UNSET OPTION_MASK_ISA_AVX512DQ > +#define OPTION_MASK_ISA_AVX512BW_UNSET OPTION_MASK_ISA_AVX512BW > +#define OPTION_MASK_ISA_AVX512VL_UNSET OPTION_MASK_ISA_AVX512VL The line above belongs to 3/n pach.
