Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Jul 05 2018, Jim Wilson wrote: > Tested with native riscv-linux bootstrap with Ada enabled. I'm getting a lot of errors from the assembler "non-constant .uleb128 is not supported" when trying to bootstrap the compiler with the cross-compiled ada compiler. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [committed][gcc][patch] Require sse for testcase on i686.
On Fri, Jul 06, 2018 at 11:46:43AM +0100, Tamar Christina wrote:
> This fixes an ABI warning generated on i686-pc-linux-gnu when using
> `vector_size` with no sse enabled explicitly.
>
> Regtested single test on x86_64-pc-linux-gnu with -m32 and no issues.
>
> Committed under the GCC obvious rule.
That is insufficient, I get the FAIL on i686-linux.
You don't really need dg-require-effective-target sse, it is a dg-do compile
time only test and on i?86/x86_64 failures with old assemblers would show up
only when assembling.
But -msse really should be used on all i?86-*-* and x86_64-*-*.
You'd normally get the -msse etc. automatically, but dg-options
is undesirable in gcc.dg/vect/ tests where all those predefined options
are lost that way, dg-additional-options should be used instead (and you can
say use there -O2 -fno-tree-vectorize or whatever you want).
So, if you have spare cycles, please test such change whether it still FAILs
on arm with your patch reverted after such test changes.
> gcc/testsuite/
> 2018-07-06 Tamar Christina
>
> PR target/84711
> * gcc.dg/vect/pr84711.c: Add -msse for i686 targets.
In the meantime, I've committed following fix as obvious:
2018-07-07 Jakub Jelinek
PR target/84711
* gcc.dg/vect/pr84711.c: Remove unnecessary sse
dg-require-effective-target. Add -msse not just on i386-*, but
on all i?86-* and x86_64-*.
--- gcc/testsuite/gcc.dg/vect/pr84711.c.jj 2018-07-06 23:35:44.952791972
+0200
+++ gcc/testsuite/gcc.dg/vect/pr84711.c 2018-07-07 09:43:27.068785902 +0200
@@ -1,8 +1,7 @@
/* { dg-do compile } */
/* { dg-require-effective-target vect_int } */
-/* { dg-require-effective-target sse { target i386*-*-* } } */
/* { dg-options "-O2" } */
-/* { dg-additional-options "-msse" { target i386*-*-* } } */
+/* { dg-additional-options "-msse" { target i?86-*-* x86_64-*-* } } */
typedef int v4si
__attribute__ ((vector_size (16)));
Jakub
[PATCH] Don't fold nextafter/nexttoward if -ftrapping-math or -fmath-errno if they produce denormal results (PR c/86420)
Hi!
So, apparently I've misread when exceptions are raised by
nextafter/nexttoward (and errno set).
if(((ix>=0x7ff0)&&((ix-0x7ff0)|lx)!=0) || /* x is nan */
((iy>=0x7ff0)&&((iy-0x7ff0)|ly)!=0)) /* y is nan */
return x+y;
I believe the above only raises exception if either operand is sNaN and thus
we should handle it:
if (REAL_VALUE_ISSIGNALING_NAN (*arg0)
|| REAL_VALUE_ISSIGNALING_NAN (*arg1))
return false;
Then:
if(x==y) return y; /* x=y, return y */
If arguments are equal, no exception is raised even if it is denormal,
we handle this with:
/* If x == y, return y cast to target type. */
if (cmp == 0)
{
real_convert (r, fmt, y);
return false;
}
Next:
if((ix|lx)==0) {/* x == 0 */
double u;
INSERT_WORDS(x,hy&0x8000,1);/* return +-minsubnormal */
u = math_opt_barrier (x);
u = u*u;
math_force_eval (u);/* raise underflow flag */
return x;
}
going from zero to +/- ulp should only raise underflow, but not set errno,
handled with:
/* Similarly for nextafter (0, 1) raising underflow. */
else if (flag_trapping_math
&& arg0->cl == rvc_zero
&& result->cl != rvc_zero)
return false;
Then overflow:
hy = hx&0x7ff0;
if(hy>=0x7ff0) {
double u = x+x; /* overflow */
math_force_eval (u);
__set_errno (ERANGE);
}
should be handled with:
if (REAL_EXP (r) > fmt->emax)
{
get_inf (r, x->sign);
return true;
}
And finally there is:
if(hy<0x0010) {
double u = x*x; /* underflow */
math_force_eval (u);/* raise underflow flag */
__set_errno (ERANGE);
}
which I've misread as raising exception and setting errno only if
the result is 0 and first arg isn't:
return r->cl == rvc_zero;
but actually it is true also for all denormal returns except for the x == y
case, so the following patch uses:
return r->cl == rvc_zero || REAL_EXP (r) < fmt->emin;
instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-07-07 Jakub Jelinek
PR c/86420
* real.c (real_nextafter): Return true if result is denormal.
* gcc.dg/nextafter-1.c (TEST): Adjust the tests that expect denormals
to be returned and when first argument is not 0, so that they don't do
anything for NEED_EXC or NEED_ERRNO.
--- gcc/real.c.jj 2018-05-06 23:12:49.211619736 +0200
+++ gcc/real.c 2018-07-06 18:42:44.761026632 +0200
@@ -5141,7 +5141,7 @@ real_nextafter (REAL_VALUE_TYPE *r, form
get_zero (r, x->sign);
return true;
}
- return r->cl == rvc_zero;
+ return r->cl == rvc_zero || REAL_EXP (r) < fmt->emin;
}
/* Write into BUF the maximum representable finite floating-point
--- gcc/testsuite/gcc.dg/nextafter-1.c.jj 2018-05-10 09:38:03.040250709
+0200
+++ gcc/testsuite/gcc.dg/nextafter-1.c 2018-07-06 19:17:55.138355524 +0200
@@ -58,23 +58,41 @@ name (void)
\
= (NEED_EXC || NEED_ERRNO) ? __builtin_inf##l1 () \
: fn (MAX1, __builtin_inf ());\
CHECK (__builtin_isinf##l1 (m) && !__builtin_signbit (m));\
- const type n = fn (DENORM_MIN1, 12.0##L2);\
+ const type n \
+= (NEED_EXC || NEED_ERRNO) ? 2.0##L1 * DENORM_MIN1 \
+ : fn (DENORM_MIN1, 12.0##L2); \
CHECK (n == 2.0##L1 * DENORM_MIN1); \
- const type o = fn (n, 24.0##L2); \
+ const type o \
+= (NEED_EXC || NEED_ERRNO) ? 3.0##L1 * DENORM_MIN1 \
+ : fn (n, 24.0##L2); \
CHECK (o == 3.0##L1 * DENORM_MIN1); \
- const type p = fn (o, 132.0##L2); \
+ const type p \
+= (NEED_EXC || NEED_ERRNO) ? 4.0##L1 * DENORM_MIN1 \
+ : fn (o, 132.0##L2); \
CHECK (p == 4.0##L1 * DENORM_MIN1); \
- const type q = fn (2.0##L1 * DENORM_MIN1, -__builtin_inf ());
\
+ const type q \
+= (NEED_EXC || NEED_ERRNO) ? DENORM_MIN1\
+ : fn (2.0##L1 * DENORM_MIN1, -__bu
[PATCH] Fix __mmask* types on many AVX512 intrinsics
Hi!
On Fri, Jul 06, 2018 at 12:47:07PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 05, 2018 at 11:57:26PM +0300, Grazvydas Ignotas wrote:
> > I think it would be more efficient if you took care of it. I won't
> > have time for at least a few days anyway.
Here is the complete patch, I found two further issues where
the __mmask mismatch was in between the return type and what was used
in the rest of the intrinsic, so not caught by my earlier greps.
I've added (except for the avx512bitalg which seems to have no runtime
test coverage whatsoever) tests that cover the real bugs and further
fixed the avx512*-vpcmp{,u}b-2.c test because (rel) << i triggered UB
if i could go up to 63.
I don't have AVX512* hw, so I've just bootstrapped/regtested the patch
normally on i686-linux and x86_64-linux AVX2 hw and tried the affected
tests without the config/i386/ changes and with them under SDE.
The patch should fix these FAILs:
FAIL: gcc.target/i386/avx512bw-vpcmpb-2.c execution test
FAIL: gcc.target/i386/avx512bw-vpcmpub-2.c execution test
FAIL: gcc.target/i386/avx512f-vinsertf32x4-3.c execution test
FAIL: gcc.target/i386/avx512f-vinserti32x4-3.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpgeb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpgeub-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpgeuw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpgew-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpleb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpleub-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpleuw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmplew-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpltb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpltub-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpltuw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpltw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpneqb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpnequb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpnequw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpneqw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpcmpub-2.c execution test
Ok for trunk?
I guess we want to backport it soon, but would appreciate somebody testing
it on real AVX512-{BW,VL} hw before doing the backports.
Another thing to consider is whether we shouldn't add those grep/sed checks
I've been doing (at least the easy ones that don't cross-check the
i386-builtins.def against the uses in the intrin headers) to config/i386/t-*
some way.
2018-07-07 Jakub Jelinek
* config/i386/avx512bitalgintrin.h (_mm512_mask_bitshuffle_epi64_mask):
Use __mmask64 type instead of __mmask8 for __M argument.
* config/i386/avx512fintrin.h (_mm512_mask_xor_epi64,
_mm512_maskz_xor_epi64): Use __mmask8 type instead of __mmask16 for
__U argument.
(_mm512_mask_cmpneq_epi64_mask): Use __mmask8 type instead of
__mmask16 for __M argument.
(_mm512_maskz_insertf32x4, _mm512_maskz_inserti32x4,
_mm512_mask_insertf32x4, _mm512_mask_inserti32x4): Cast last argument
to __mmask16 instead of __mmask8.
* config/i386/avx512vlintrin.h (_mm_mask_add_ps, _mm_maskz_add_ps,
_mm256_mask_add_ps, _mm256_maskz_add_ps, _mm_mask_sub_ps,
_mm_maskz_sub_ps, _mm256_mask_sub_ps, _mm256_maskz_sub_ps,
_mm256_maskz_cvtepi32_ps, _mm_maskz_cvtepi32_ps): Use __mmask8 type
instead of __mmask16 for __U argument.
* config/i386/avx512vlbwintrin.h (_mm_mask_cmp_epi8_mask): Use
__mmask16 instead of __mmask8 for __U argument.
(_mm256_mask_cmp_epi8_mask): Use __mmask32 instead of __mmask16 for
__U argument.
(_mm256_cmp_epi8_mask): Use __mmask32 return type instead of
__mmask16.
(_mm_mask_cmp_epu8_mask): Use __mmask16 instead of __mmask8 for __U
argument.
(_mm256_mask_cmp_epu8_mask): Use __mmask32 instead of __mmask16 for
__U argument.
(_mm256_cmp_epu8_mask): Use __mmask32 return type instead of
__mmask16.
(_mm_mask_cmp_epi16_mask): Cast last argument to __mmask8 instead
of __mmask16.
(_mm256_mask_cvtepi8_epi16): Use __mmask16 instead of __mmask32 for
__U argument.
(_mm_mask_cvtepi8_epi16): Use __mmask8 instead of __mmask32 for
__U argument.
(_mm256_mask_cvtepu8_epi16): Use __mmask16 instead of __mmask32 for
__U argument.
(_mm_mask_cvtepu8_epi16): Use __mmask8 instead of __mmask32 for
__U argument.
(_mm256_mask_cmpneq_epu8_mask, _mm256_mask_cmplt_epu8_mask,
_mm256_mask_cmpge_epu8_mask, _mm256_mask_cmple_epu8_mask): Change
return type as well as __M argument type and all casts from __mmask8
to __mmask32.
(_mm256_mask_cmpneq_epu16_mask, _mm256_mask_cmplt_epu16_mask,
_mm256_mask_cmpge_epu16_mask, _mm256_
Re: calculate overflow type in wide int arithmetic
Richard Biener writes:
> On Fri, Jul 6, 2018 at 9:50 AM Aldy Hernandez wrote:
>>
>>
>>
>> On 07/05/2018 05:50 AM, Richard Biener wrote:
>> > On Thu, Jul 5, 2018 at 9:35 AM Aldy Hernandez wrote:
>> >>
>> >> The reason for this patch are the changes showcased in tree-vrp.c.
>> >> Basically I'd like to discourage rolling our own overflow and underflow
>> >> calculation when doing wide int arithmetic. We should have a
>> >> centralized place for this, that is-- in the wide int code itself ;-).
>> >>
>> >> The only cases I care about are plus/minus, which I have implemented,
>> >> but we also get division for free, since AFAICT, division can only
>> >> positive overflow:
>> >>
>> >> -MIN / -1 => +OVERFLOW
>> >>
>> >> Multiplication OTOH, can underflow, but I've not implemented it because
>> >> we have no uses for it. I have added a note in the code explaining this.
>> >>
>> >> Originally I tried to only change plus/minus, but that made code that
>> >> dealt with plus/minus in addition to div or mult a lot uglier. You'd
>> >> have to special case "int overflow_for_add_stuff" and "bool
>> >> overflow_for_everything_else". Changing everything to int, makes things
>> >> consistent.
>> >>
>> >> Note: I have left poly-int as is, with its concept of yes/no for
>> >> overflow. I can adapt this as well if desired.
>> >>
>> >> Tested on x86-64 Linux.
>> >>
>> >> OK for trunk?
>> >
>> > looks all straight-forward but the following:
>> >
>> > else if (op1)
>> > {
>> > if (minus_p)
>> > - {
>> > - wi = -wi::to_wide (op1);
>> > -
>> > - /* Check for overflow. */
>> > - if (sgn == SIGNED
>> > - && wi::neg_p (wi::to_wide (op1))
>> > - && wi::neg_p (wi))
>> > - ovf = 1;
>> > - else if (sgn == UNSIGNED && wi::to_wide (op1) != 0)
>> > - ovf = -1;
>> > - }
>> > + wi = wi::neg (wi::to_wide (op1));
>> > else
>> > wi = wi::to_wide (op1);
>> >
>> > you fail to handle - -INT_MIN.
>>
>> Woah, very good catch. I previously had this implemented as wi::sub(0,
>> op1, &ovf) which was calculating overflow correctly but when I
>> implemented the overflow type in wi::neg I missed this. Thanks.
>>
>> >
>> > Given the fact that for multiplication (or others, didn't look too close)
>> > you didn't implement the direction indicator I wonder if it would be more
>> > appropriate to do
>> >
>> > enum ovfl { OVFL_NONE = 0, OVFL_UNDERFLOW = -1, OVFL_OVERFLOW = 1,
>> > OVFL_UNKNOWN = 2 };
>> >
>> > and tell us the "truth" here?
>>
>> Excellent idea...though it came with lots of typing :). Fixed.
>>
>> BTW, if I understand correctly, I've implemented the overflow types
>> correctly for everything but multiplication (which we have no users for
>> and I return OVF_UNKNOWN). I have indicated this in comments. Also,
>> for division I did nothing special, as we can only +OVERFLOW.
>>
>> >
>> > Hopefully if (overflow) will still work with that.
>>
>> It does.
>>
>> >
>> > Otherwise can you please add a toplevel comment to wide-int.h as to what
>> > the
>> > overflow result semantically is for a) SIGNED and b) UNSIGNED operations?
>>
>> Done. Let me know if the current comment is what you had in mind.
>>
>> OK for trunk?
>
> I'd move accumulate_overflow to wi::, it looks generally useful. That
> function
> misses to handle the !suboverflow && overflow case optimally.
>
> I see that poly-int choses to accumulate overflow (callers need to
> initialize it) while wide_int chooses not to accumulate... to bad
> this is inconsistent. Richard?
poly-int needs to accumulate internally when handling multiple coefficients,
but the external interface is the same as for wi:: (no caller initialisation).
Richard
Re: [PATCH] Don't fold nextafter/nexttoward if -ftrapping-math or -fmath-errno if they produce denormal results (PR c/86420)
On Sat, 7 Jul 2018, Jakub Jelinek wrote: 2018-07-07 Jakub Jelinek PR c/86420 * real.c (real_nextafter): Return true if result is denormal. I have a question on the side: would it be hard / useful, in cases where nextafter may set errno or some exception flag, to fold the result to a constant while keeping the function call (ignoring the value it returns)? To clarify, I mean replace _2 = nextafter(DBL_DENORM_MIN, 0); with nextafter(DBL_DENORM_MIN, 0); _2 = 0; I think we already do that for some other calls, although I can't remember where. The point would be that we have the value of _2 and can keep folding its uses. -- Marc Glisse
[Ada] Optimize calls to pure functions with by-ref In parameter
With GNAT you can declare a function as pure with a dedicated pragma, even if
it takes a parameter passed by reference. In this case, if the parameter is
declared as In (the default), the language additionally guarantees that it is
not modified, thus making the function also pure in the GCC sense.
Tested on x86-64/Linux, applied on the mainline.
2018-07-07 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_param): Minor tweak.
(gnat_to_gnu_subprog_type): New pure_flag local variable. Set it for
a pure Ada function with a by-ref In parameter. Propagate it onto the
function type by means of the TYPE_QUAL_RESTRICT flag.
* gcc-interface/utils.c (finish_subprog_decl): Set DECL_PURE_P if the
function type has the TYPE_QUAL_RESTRICT flag set.
2018-07-07 Eric Botcazou
* gnat.dg/pure_function3a.adb: New test.
* gnat.dg/pure_function3b.adb: Likewise.
* gnat.dg/pure_function3c.adb: Likewise.
* gnat.dg/pure_function3_pkg.ads: New helper.
--
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 262468)
+++ gcc-interface/decl.c (working copy)
@@ -5228,7 +5228,6 @@ gnat_to_gnu_param (Entity_Id gnat_param,
&& TYPE_MULTI_ARRAY_P (TREE_TYPE (gnu_param_type)))
gnu_param_type = TREE_TYPE (gnu_param_type);
- by_component_ptr = true;
gnu_param_type = TREE_TYPE (gnu_param_type);
if (ro_param)
@@ -5236,6 +5235,7 @@ gnat_to_gnu_param (Entity_Id gnat_param,
= change_qualified_type (gnu_param_type, TYPE_QUAL_CONST);
gnu_param_type = build_pointer_type (gnu_param_type);
+ by_component_ptr = true;
}
/* Fat pointers are passed as thin pointers for foreign conventions. */
@@ -5561,14 +5561,15 @@ gnat_to_gnu_subprog_type (Entity_Id gnat
/* Fields in return type of procedure with copy-in copy-out parameters. */
tree gnu_field_list = NULL_TREE;
/* The semantics of "pure" in Ada essentially matches that of "const"
- in the back-end. In particular, both properties are orthogonal to
- the "nothrow" property if the EH circuitry is explicit in the
- internal representation of the back-end. If we are to completely
+ or "pure" in GCC. In particular, both properties are orthogonal
+ to the "nothrow" property if the EH circuitry is explicit in the
+ internal representation of the middle-end. If we are to completely
hide the EH circuitry from it, we need to declare that calls to pure
Ada subprograms that can throw have side effects since they can
- trigger an "abnormal" transfer of control flow; thus they can be
- neither "const" nor "pure" in the back-end sense. */
+ trigger an "abnormal" transfer of control flow; therefore, they can
+ be neither "const" nor "pure" in the GCC sense. */
bool const_flag = (Back_End_Exceptions () && Is_Pure (gnat_subprog));
+ bool pure_flag = false;
bool return_by_direct_ref_p = false;
bool return_by_invisi_ref_p = false;
bool return_unconstrained_p = false;
@@ -5849,13 +5850,19 @@ gnat_to_gnu_subprog_type (Entity_Id gnat
gnu_param_list = chainon (gnu_param, gnu_param_list);
save_gnu_tree (gnat_param, gnu_param, false);
- /* If a parameter is a pointer, a function may modify memory through
- it and thus shouldn't be considered a const function. Also, the
- memory may be modified between two calls, so they can't be CSE'ed.
- The latter case also handles by-ref parameters. */
- if (POINTER_TYPE_P (gnu_param_type)
- || TYPE_IS_FAT_POINTER_P (gnu_param_type))
- const_flag = false;
+ /* A pure function in the Ada sense which takes an access parameter
+ may modify memory through it and thus need be considered neither
+ const nor pure in the GCC sense. Likewise it if takes a by-ref
+ In Out or Out parameter. But if it takes a by-ref In parameter,
+ then it may only read memory through it and can be considered
+ pure in the GCC sense. */
+ if ((const_flag || pure_flag)
+ && (POINTER_TYPE_P (gnu_param_type)
+ || TYPE_IS_FAT_POINTER_P (gnu_param_type)))
+ {
+ const_flag = false;
+ pure_flag = DECL_POINTS_TO_READONLY_P (gnu_param);
+ }
}
/* If the parameter uses the copy-in copy-out mechanism, allocate a field
@@ -6007,6 +6014,9 @@ gnat_to_gnu_subprog_type (Entity_Id gnat
if (const_flag)
gnu_type = change_qualified_type (gnu_type, TYPE_QUAL_CONST);
+ if (pure_flag)
+ gnu_type = change_qualified_type (gnu_type, TYPE_QUAL_RESTRICT);
+
if (No_Return (gnat_subprog))
gnu_type = change_qualified_type (gnu_type, TYPE_QUAL_VOLATILE);
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c (revision 262468)
+++ gcc-interface/utils.c (working copy)
@@ -3330,6 +3330,9 @@ finish_subprog_decl (tree decl, tree as
Re: [PATCH] Don't fold nextafter/nexttoward if -ftrapping-math or -fmath-errno if they produce denormal results (PR c/86420)
On Sat, Jul 07, 2018 at 11:55:17AM +0200, Marc Glisse wrote: > On Sat, 7 Jul 2018, Jakub Jelinek wrote: > > > 2018-07-07 Jakub Jelinek > > > > PR c/86420 > > * real.c (real_nextafter): Return true if result is denormal. > > I have a question on the side: would it be hard / useful, in cases where > nextafter may set errno or some exception flag, to fold the result to a > constant while keeping the function call (ignoring the value it returns)? To > clarify, I mean replace > > _2 = nextafter(DBL_DENORM_MIN, 0); > > with > > nextafter(DBL_DENORM_MIN, 0); > _2 = 0; > > I think we already do that for some other calls, although I can't remember > where. The point would be that we have the value of _2 and can keep folding > its uses. For errno purposes alone that would be possible, but the function is marked #define ATTR_MATHFN_ERRNO (flag_errno_math ? \ ATTR_NOTHROW_LEAF_LIST : ATTR_CONST_NOTHROW_LEAF_LIST) and thus with -ftrapping-math -fno-math-errno I'm afraid we'd immediately DCE the call in the second form (without lhs). Jakub
[Ada] Do not generate debug info for actual subtypes
These actual subtypes are artificial subtypes generated for parameters whose
nominal subtype is an unconstrained array type in order to expose the bounds.
There is no point in generating debug info for them so avoid doing it now.
Tested on x86-64/Linux, applied on the mainline.
2018-07-07 Eric Botcazou
* gcc-interface/gigi.h (add_decl_expr): Adjust prototype.
* gcc-interface/decl.c (gnat_to_gnu_entity): Remove useless test.
* gcc-interface/trans.c (add_stmt_with_node): Remove exceptions.
(add_decl_expr): Change type of second parameter and rename it.
(renaming_from_instantiation_p): New function moved from...
(set_expr_location_from_node): Test for exceptions here and add one
for actual subtypes built for unconstrained composite actuals.
* gcc-interface/utils.c (renaming_from_instantiation_p): ...here.
--
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 262495)
+++ gcc-interface/decl.c (working copy)
@@ -430,11 +430,10 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
|| Is_Public (gnat_entity));
/* Get the name of the entity and set up the line number and filename of
- the original definition for use in any decl we make. Make sure we do not
- inherit another source location. */
+ the original definition for use in any decl we make. Make sure we do
+ not inherit another source location. */
gnu_entity_name = get_entity_name (gnat_entity);
- if (Sloc (gnat_entity) != No_Location
- && !renaming_from_instantiation_p (gnat_entity))
+ if (!renaming_from_instantiation_p (gnat_entity))
Sloc_to_locus (Sloc (gnat_entity), &input_location);
/* For cases when we are not defining (i.e., we are referencing from
Index: gcc-interface/gigi.h
===
--- gcc-interface/gigi.h (revision 262468)
+++ gcc-interface/gigi.h (working copy)
@@ -77,9 +77,9 @@ extern tree end_stmt_group (void);
/* Set the BLOCK node corresponding to the current code group to GNU_BLOCK. */
extern void set_block_for_group (tree);
-/* Add a declaration statement for GNU_DECL to the current BLOCK_STMT node.
- Get SLOC from GNAT_ENTITY. */
-extern void add_decl_expr (tree gnu_decl, Entity_Id gnat_entity);
+/* Add a declaration statement for GNU_DECL to the current statement group.
+ Get the SLOC to be put onto the statement from GNAT_NODE. */
+extern void add_decl_expr (tree gnu_decl, Node_Id gnat_node);
/* Mark nodes rooted at T with TREE_VISITED and types as having their
sized gimplified. We use this to indicate all variable sizes and
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 262496)
+++ gcc-interface/trans.c (working copy)
@@ -8119,9 +8119,7 @@ add_stmt_force (tree gnu_stmt)
void
add_stmt_with_node (tree gnu_stmt, Node_Id gnat_node)
{
- /* Do not emit a location for renamings that come from generic instantiation,
- they are likely to disturb debugging. */
- if (Present (gnat_node) && !renaming_from_instantiation_p (gnat_node))
+ if (Present (gnat_node))
set_expr_location_from_node (gnu_stmt, gnat_node);
add_stmt (gnu_stmt);
}
@@ -8137,10 +8135,10 @@ add_stmt_with_node_force (tree gnu_stmt,
}
/* Add a declaration statement for GNU_DECL to the current statement group.
- Get SLOC from Entity_Id. */
+ Get the SLOC to be put onto the statement from GNAT_NODE. */
void
-add_decl_expr (tree gnu_decl, Entity_Id gnat_entity)
+add_decl_expr (tree gnu_decl, Node_Id gnat_node)
{
tree type = TREE_TYPE (gnu_decl);
tree gnu_stmt, gnu_init;
@@ -8179,7 +8177,7 @@ add_decl_expr (tree gnu_decl, Entity_Id
MARK_VISITED (TYPE_ADA_SIZE (type));
}
else
-add_stmt_with_node (gnu_stmt, gnat_entity);
+add_stmt_with_node (gnu_stmt, gnat_node);
/* If this is a variable and an initializer is attached to it, it must be
valid for the context. Similar to init_const in create_var_decl. */
@@ -8203,7 +8201,7 @@ add_decl_expr (tree gnu_decl, Entity_Id
gnu_decl = convert (TREE_TYPE (TYPE_FIELDS (type)), gnu_decl);
gnu_stmt = build_binary_op (INIT_EXPR, NULL_TREE, gnu_decl, gnu_init);
- add_stmt_with_node (gnu_stmt, gnat_entity);
+ add_stmt_with_node (gnu_stmt, gnat_node);
}
}
@@ -10005,6 +10003,32 @@ Sloc_to_locus (Source_Ptr Sloc, location
return true;
}
+/* Return whether GNAT_NODE is a defining identifier for a renaming that comes
+ from the parameter association for the instantiation of a generic. We do
+ not want to emit source location for them: the code generated for their
+ initialization is likely to disturb debugging. */
+
+bool
+renaming_from_instantiation_p (Node_Id gnat_node)
+{
+ if (Nkind (gnat_node) != N_Defining_Identifier
+ || !Is_Object (gnat_node)
+ || Comes_From_Source
[Ada] Reduce -Wstack-usage false positives on variant records
This reduces the number of false positives of -Wstack-usage in the presence of
variables whose nominal subtype is a discriminated record with a variant part.
Tested on x86-64/Linux, applied on the mainline.
2018-07-07 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity): Add GNAT_DECL local
variable and use it throughout.
: If the nominal subtype of the object is unconstrained,
compute the Ada size separately and put in on the padding type if the
size is not fixed.
: Minor tweak.
* gcc-interface/misc.c (gnat_type_max_size): Rename max_size_unit
into max_size_unit throughout.
2018-07-07 Eric Botcazou
* gnat.dg/stack_usage6.adb: New test.
* gnat.dg/stack_usage6_pkg.ads: New helper.
--
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 262497)
+++ gcc-interface/decl.c (working copy)
@@ -273,7 +273,9 @@ static bool intrin_profiles_compatible_p
tree
gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
{
- /* Contains the kind of the input GNAT node. */
+ /* The construct that declared the entity. */
+ const Node_Id gnat_decl = Declaration_Node (gnat_entity);
+ /* The kind of the entity. */
const Entity_Kind kind = Ekind (gnat_entity);
/* True if this is a type. */
const bool is_type = IN (kind, Type_Kind);
@@ -578,7 +580,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
if (definition
&& !gnu_expr
&& No (Address_Clause (gnat_entity))
- && !No_Initialization (Declaration_Node (gnat_entity))
+ && !No_Initialization (gnat_decl)
&& No (Renamed_Object (gnat_entity)))
{
gnu_decl = error_mark_node;
@@ -611,9 +613,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
may contain N_Expression_With_Actions nodes and thus declarations of
objects from other units that we need to discard. */
if (!definition
- && !No_Initialization (Declaration_Node (gnat_entity))
+ && !No_Initialization (gnat_decl)
&& !Is_Dispatch_Table_Entity (gnat_entity)
- && Present (gnat_temp = Expression (Declaration_Node (gnat_entity)))
+ && Present (gnat_temp = Expression (gnat_decl))
&& Nkind (gnat_temp) != N_Allocator
&& (!type_annotate_only || Compile_Time_Known_Value (gnat_temp)))
gnu_expr = gnat_to_gnu_external (gnat_temp);
@@ -634,9 +636,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
&& !(kind == E_Variable
&& Present (Linker_Section_Pragma (gnat_entity)))
&& !Treat_As_Volatile (gnat_entity)
- && (((Nkind (Declaration_Node (gnat_entity))
- == N_Object_Declaration)
- && Present (Expression (Declaration_Node (gnat_entity
+ && (((Nkind (gnat_decl) == N_Object_Declaration)
+ && Present (Expression (gnat_decl)))
|| Present (Renamed_Object (gnat_entity))
|| imported_p));
bool inner_const_flag = const_flag;
@@ -650,7 +651,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
bool used_by_ref = false;
tree gnu_ext_name = NULL_TREE;
tree renamed_obj = NULL_TREE;
- tree gnu_object_size;
+ tree gnu_ada_size = NULL_TREE;
/* We need to translate the renamed object even though we are only
referencing the renaming. But it may contain a call for which
@@ -755,8 +756,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
{
if (gnu_expr && kind == E_Constant)
{
- tree size = TYPE_SIZE (TREE_TYPE (gnu_expr));
- if (CONTAINS_PLACEHOLDER_P (size))
+ gnu_size = TYPE_SIZE (TREE_TYPE (gnu_expr));
+ gnu_ada_size = TYPE_ADA_SIZE (TREE_TYPE (gnu_expr));
+ if (CONTAINS_PLACEHOLDER_P (gnu_size))
{
/* If the initializing expression is itself a constant,
despite having a nominal type with self-referential
@@ -768,27 +770,38 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
&& (TREE_READONLY (TREE_OPERAND (gnu_expr, 0))
|| DECL_READONLY_ONCE_ELAB
(TREE_OPERAND (gnu_expr, 0
- gnu_size = DECL_SIZE (TREE_OPERAND (gnu_expr, 0));
+ {
+ gnu_size = DECL_SIZE (TREE_OPERAND (gnu_expr, 0));
+ gnu_ada_size = gnu_size;
+ }
else
- gnu_size
- = SUBSTITUTE_PLACEHOLDER_IN_EXPR (size, gnu_expr);
+ {
+ gnu_size
+ = SUBSTITUTE_PLACEHOLDER_IN_EXPR (gnu_size,
+ gnu_expr);
+ gnu_ada_size
+ = SUBSTITUTE_PLACEHOLDER_IN_EXPR (gnu_ada_size,
+ gnu_expr);
+ }
}
- else
- gnu_size = size;
}
/* We may have no GNU_EXPR because No_Initialization is
set even though there's an Expression. */
else if (kind == E_Constant
- && (Nkind (Declaration_Node (gnat_entity))
- == N_Object_Declaration)
- && Present (Expression (Declaration_Node (gnat_entity
- gnu_size
- = TYPE_SIZE (gnat_to_gnu_type
- (Etype
- (Expression (Declaration_Node (gnat_entity);
+ && Nkind (gnat_decl) == N_Object_Declaration
+ && Present (Expression (gnat_decl)))
+
[c-family] Swich -fdump-ada-spec output for Ada 2012
The aspect syntax introduced in Ada 2012 makes it much easier to support
function overloading in particular, so the patch removes a lot of lines:
c-ada-spec.c | 322 ++---
1 file changed, 105 insertions(+), 217 deletions(-)
Tested on x86-64/Linux, applied on the mainline.
2018-07-07 Eric Botcazou
* c-ada-spec.c (to_ada_name): Remove index parameter.
(pp_ada_tree_identifier): Likewise.
(dump_ada_macros): Adjust call to to_ada_name.
(struct overloaded_name_hash): Delete.
(struct overloaded_name_hasher): Likewise.
(overloaded_names): Likewise.
(compute_overloading_index): Likewise.
(dump_ada_decl_name): Do not call compute_overloading_index and
adjust calls to pp_ada_tree_identifier.
(dump_ada_double_name): Adjust calls to pp_ada_tree_identifier.
(dump_ada_import): Add spc parameter and switch to aspect syntax.
(dump_ada_function_declaration): Adjust call to pp_ada_tree_identifier.
(dump_ada_enum_type): Remove type and display_convention parameters.
Adjust calls to pp_ada_tree_identifier.
(dump_ada_node): Likewise and for dump_ada_structure.
(dump_nested_type) : Adjust call to dump_ada_enum_type
and tidy up.
: Adjust call to dump_ada_structure and switch to aspect
syntax.
(print_constructor): Adjust call to pp_ada_tree_identifier.
(print_destructor): Likewise.
(dump_ada_declaration): Switch to aspect syntax.
(dump_ada_structure): Likewise and tidy up. Replace display_convention
parameter with nested parameter.
(dump_ads): Emit pragma Ada_2012 in lieu of pragma Ada_2005.
(dump_ada_specs): Do not delete overloaded_names table.
--
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c (revision 262468)
+++ c-ada-spec.c (working copy)
@@ -34,8 +34,8 @@ along with GCC; see the file COPYING3.
/* Local functions, macros and variables. */
static int dump_ada_node (pretty_printer *, tree, tree, int, bool, bool);
static int dump_ada_declaration (pretty_printer *, tree, tree, int);
-static void dump_ada_structure (pretty_printer *, tree, tree, int, bool);
-static char *to_ada_name (const char *, unsigned int, bool *);
+static void dump_ada_structure (pretty_printer *, tree, tree, bool, int);
+static char *to_ada_name (const char *, bool *);
#define INDENT(SPACE) \
do { int i; for (i = 0; i homonyms;
-};
-
-struct overloaded_name_hasher : delete_ptr_hash
-{
- static inline hashval_t hash (overloaded_name_hash *t)
-{ return t->hash; }
- static inline bool equal (overloaded_name_hash *a, overloaded_name_hash *b)
-{ return a->name == b->name && a->context == b->context; }
-};
-
-static hash_table *overloaded_names;
-
-/* Compute the overloading index of function DECL in its context. */
-
-static unsigned int
-compute_overloading_index (tree decl)
-{
- const hashval_t hashcode
-= iterative_hash_hashval_t (htab_hash_pointer (DECL_NAME (decl)),
- htab_hash_pointer (DECL_CONTEXT (decl)));
- struct overloaded_name_hash in, *h, **slot;
- unsigned int index, *iter;
-
- if (!overloaded_names)
-overloaded_names = new hash_table (512);
-
- /* Look up the list of homonyms in the table. */
- in.hash = hashcode;
- in.name = DECL_NAME (decl);
- in.context = DECL_CONTEXT (decl);
- slot = overloaded_names->find_slot_with_hash (&in, hashcode, INSERT);
- if (*slot)
-h = *slot;
- else
-{
- h = new overloaded_name_hash;
- h->hash = hashcode;
- h->name = DECL_NAME (decl);
- h->context = DECL_CONTEXT (decl);
- h->homonyms.create (0);
- *slot = h;
-}
-
- /* Look up the function in the list of homonyms. */
- FOR_EACH_VEC_ELT (h->homonyms, index, iter)
-if (*iter == DECL_UID (decl))
- break;
-
- /* If it is not present, push it onto the list. */
- if (!iter)
-h->homonyms.safe_push (DECL_UID (decl));
-
- return index;
-}
-
/* Dump in BUFFER the name of a DECL node if set, in Ada syntax.
LIMITED_ACCESS indicates whether NODE can be accessed via a
limited 'with' clause rather than a regular 'with' clause. */
@@ -1519,13 +1450,7 @@ static void
dump_ada_decl_name (pretty_printer *buffer, tree decl, bool limited_access)
{
if (DECL_NAME (decl))
-{
- const unsigned int index
- = (TREE_CODE (decl) == FUNCTION_DECL && cpp_check)
- ? compute_overloading_index (decl) : 0;
- pp_ada_tree_identifier (buffer, DECL_NAME (decl), decl, index,
- limited_access);
-}
+pp_ada_tree_identifier (buffer, DECL_NAME (decl), decl, limited_access);
else
{
tree type_name = TYPE_NAME (TREE_TYPE (decl));
@@ -1539,7 +1464,7 @@ dump_ada_decl_name (pretty_printer *buff
pp_scalar (buffer, "%d", TYPE_UID (TREE_TYPE (decl)));
}
else if (TREE_CODE (type_name) == IDENTIF
Re: [committed][gcc][patch] Require sse for testcase on i686.
Hi Jakub,
>
> On Fri, Jul 06, 2018 at 11:46:43AM +0100, Tamar Christina wrote:
> > This fixes an ABI warning generated on i686-pc-linux-gnu when using
> > `vector_size` with no sse enabled explicitly.
> >
> > Regtested single test on x86_64-pc-linux-gnu with -m32 and no issues.
> >
> > Committed under the GCC obvious rule.
>
> That is insufficient, I get the FAIL on i686-linux.
> You don't really need dg-require-effective-target sse, it is a dg-do compile
> time only test and on i?86/x86_64 failures with old assemblers would show up
> only when assembling.
> But -msse really should be used on all i?86-*-* and x86_64-*-*.
Ah I wasn't are of that, I initially didn't add it to x86-64 since the test
wasn't generating the ABI warning there. But this is good to know for the
future.
>
> You'd normally get the -msse etc. automatically, but dg-options
> is undesirable in gcc.dg/vect/ tests where all those predefined options
> are lost that way, dg-additional-options should be used instead (and you can
> say use there -O2 -fno-tree-vectorize or whatever you want).
>
> So, if you have spare cycles, please test such change whether it still FAILs
> on arm with your patch reverted after such test changes.
Will do. Sorry for the mess, not very use to the x86 options yet.
Thanks,
Tamar
>
> > gcc/testsuite/
> > 2018-07-06 Tamar Christina
> >
> > PR target/84711
> > * gcc.dg/vect/pr84711.c: Add -msse for i686 targets.
>
> In the meantime, I've committed following fix as obvious:
>
> 2018-07-07 Jakub Jelinek
>
> PR target/84711
> * gcc.dg/vect/pr84711.c: Remove unnecessary sse
> dg-require-effective-target. Add -msse not just on i386-*, but
> on all i?86-* and x86_64-*.
>
> --- gcc/testsuite/gcc.dg/vect/pr84711.c.jj 2018-07-06 23:35:44.952791972
> +0200
> +++ gcc/testsuite/gcc.dg/vect/pr84711.c 2018-07-07 09:43:27.068785902 +0200
> @@ -1,8 +1,7 @@
> /* { dg-do compile } */
> /* { dg-require-effective-target vect_int } */
> -/* { dg-require-effective-target sse { target i386*-*-* } } */
> /* { dg-options "-O2" } */
> -/* { dg-additional-options "-msse" { target i386*-*-* } } */
> +/* { dg-additional-options "-msse" { target i?86-*-* x86_64-*-* } } */
>
> typedef int v4si
>__attribute__ ((vector_size (16)));
>
>
> Jakub
>
Re: [committed][gcc][patch] Require sse for testcase on i686.
On Sat, Jul 07, 2018 at 11:07:28AM +, Tamar Christina wrote: > > On Fri, Jul 06, 2018 at 11:46:43AM +0100, Tamar Christina wrote: > > > This fixes an ABI warning generated on i686-pc-linux-gnu when using > > > `vector_size` with no sse enabled explicitly. > > > > > > Regtested single test on x86_64-pc-linux-gnu with -m32 and no issues. > > > > > > Committed under the GCC obvious rule. > > > > That is insufficient, I get the FAIL on i686-linux. > > You don't really need dg-require-effective-target sse, it is a dg-do compile > > time only test and on i?86/x86_64 failures with old assemblers would show up > > only when assembling. > > But -msse really should be used on all i?86-*-* and x86_64-*-*. > > Ah I wasn't are of that, I initially didn't add it to x86-64 since the > test wasn't generating the ABI warning there. But this is good to know > for the future. The thing is that i?86-*-* and x86_64-*-* can be both multilib, and only the -m64 and -mx32 multilibs default to -msse2, -m32 does not. In gcc.target/ia32 one uses typically ia32 effective target for the -m32 i?86/x86_64 multilib, but in this case it doesn't hurt to add -msse to all. Jakub
Re: [PATCH] Don't fold nextafter/nexttoward if -ftrapping-math or -fmath-errno if they produce denormal results (PR c/86420)
On Sat, 7 Jul 2018, Jakub Jelinek wrote: On Sat, Jul 07, 2018 at 11:55:17AM +0200, Marc Glisse wrote: On Sat, 7 Jul 2018, Jakub Jelinek wrote: 2018-07-07 Jakub Jelinek PR c/86420 * real.c (real_nextafter): Return true if result is denormal. I have a question on the side: would it be hard / useful, in cases where nextafter may set errno or some exception flag, to fold the result to a constant while keeping the function call (ignoring the value it returns)? To clarify, I mean replace _2 = nextafter(DBL_DENORM_MIN, 0); with nextafter(DBL_DENORM_MIN, 0); _2 = 0; I think we already do that for some other calls, although I can't remember where. The point would be that we have the value of _2 and can keep folding its uses. For errno purposes alone that would be possible, but the function is marked #define ATTR_MATHFN_ERRNO (flag_errno_math ? \ ATTR_NOTHROW_LEAF_LIST : ATTR_CONST_NOTHROW_LEAF_LIST) and thus with -ftrapping-math -fno-math-errno I'm afraid we'd immediately DCE the call in the second form (without lhs). That looks like a problem we'll have to fix eventually. But not as part of this patch indeed. -- Marc Glisse
Re: [C++ PATCH] PR c++/79133
Did you consider handling this in check_local_shadow? On Fri, Jul 6, 2018 at 7:50 PM, Ville Voutilainen wrote: > Tested on Linux-PPC64. Ok for trunk, perhaps with the change > that I move the test under cpp1y, since it's a c++14 test anyway? > > I considered pushing the captures into the parameter scope. I don't > know how to do that; changing the pushdecl_outermost_localscope > to a pushdecl doesn't seem to cut it; I guess that I should add > a new function into name-lookup.[ch], but I wonder whether > that makes sense, considering that this is lambda-only functionality. > I also wonder whether it makes more sense than the solution > in this patch, considering that we handle packs here as well > and capturepack/parampack, capturepack/param, capture/parampack > and capture/param clashes. > > Guidance welcome. This approach has the benefit that it, well, > seems to work. :) > > 2018-07-07 Ville Voutilainen > > gcc/cp/ > > PR c++/79133 > * lambda.c (start_lambda_function): Reject captures and parameters > with the same name. > > testsuite/ > > PR c++/79133 > * g++.dg/cpp0x/lambda/lambda-shadow3.C: New.
New Spanish PO file for 'gcc' (version 8.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-8.1.0.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Sat, Jul 7, 2018 at 12:25 AM, Andreas Schwab wrote: > On Jul 05 2018, Jim Wilson wrote: > >> Tested with native riscv-linux bootstrap with Ada enabled. > > I'm getting a lot of errors from the assembler "non-constant .uleb128 is > not supported" when trying to bootstrap the compiler with the > cross-compiled ada compiler. GCC configure assumes that if you have gas, then non-constant .uleb128 is OK. However, because RISC-V deletes instructions at link time, we cannot allow some forms of this construct. If you have a working gas available at gcc configure time, then it should do a gas run-time test and discover that this gas feature does not work. If you do not have a working gas at gcc configure time, it will assume the feature is available, try to use it, and then you get a build failure due to gas errors. The only time I've ever seen this error is if I try to use an old-style combined-tree build approach, because in this case gcc configures before gas is built. If you build and install binutils, and then build and install gcc, the build will work. I haven't tried to fix the old-style combined-tree approach, I didn't see an obvious fix, and since I don't like to do builds this way anymore it wasn't important enough to me to try to fix. JIm
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
On Fri, Jul 6, 2018 at 12:55 AM, Eric Botcazou wrote: >> Ada doesn't use trampolines if you define... >> >> > + Always_Compatible_Rep : constant Boolean := False; >> >> ...this to False. > > And also define TARGET_CUSTOM_FUNCTION_DESCRIPTORS for the architecture. I tried adding the missing definition. I now get === acats Summary === # of expected passes2320 # of unexpected failures0 === gnat Summary === # of expected passes2779 # of unexpected failures4 # of expected failures 24 # of unsupported tests 25 So yes, that solved my problem, and we have a working RISC-V Ada port now. Thanks for the help. Jim
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
> I tried adding the missing definition. I now get > > === acats Summary === > # of expected passes2320 > # of unexpected failures0 > > === gnat Summary === > > # of expected passes2779 > # of unexpected failures4 > # of expected failures 24 > # of unsupported tests 25 > > So yes, that solved my problem, and we have a working RISC-V Ada port > now. Thanks for the help. Great!
[PATCH] RISC-V: Finish Ada port.
Thanks to Eric Botcazou, this eliminates almost all of the remaining Ada testsuite failures by adding a missing definition for the target specific handling of function descriptors. Tested with a native riscv64-linux bootstrap with Ada, and running the Ada testsuite. There are only 4 failures left. Committed. Jim gcc/ * config/riscv/riscv.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): New. --- gcc/config/riscv/riscv.c | 4 1 file changed, 4 insertions(+) diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c index d87836f53f8..218f4de7d41 100644 --- a/gcc/config/riscv/riscv.c +++ b/gcc/config/riscv/riscv.c @@ -4786,6 +4786,10 @@ riscv_constant_alignment (const_tree exp, HOST_WIDE_INT align) #undef TARGET_WARN_FUNC_RETURN #define TARGET_WARN_FUNC_RETURN riscv_warn_func_return +/* The low bit is ignored by jump instructions so is safe to use. */ +#undef TARGET_CUSTOM_FUNCTION_DESCRIPTORS +#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 + struct gcc_target targetm = TARGET_INITIALIZER; #include "gt-riscv.h" -- 2.17.1
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
> I tried adding the missing definition. I now get > > === acats Summary === > # of expected passes2320 > # of unexpected failures0 > > === gnat Summary === > > # of expected passes2779 > # of unexpected failures4 > # of expected failures 24 > # of unsupported tests 25 > > So yes, that solved my problem, and we have a working RISC-V Ada port > now. Thanks for the help. You're welcome. Are the 4 remaining failures related to stack checking? -- Eric Botcazou
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Jul 07 2018, Jim Wilson wrote: > If you build and install binutils, and then build and install gcc, the > build will work. Not if the compiler was built in a canadian cross. That's the only way to bootstrap an Ada compiler. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
On Sat, Jul 7, 2018 at 9:41 AM, Eric Botcazou wrote: > You're welcome. Are the 4 remaining failures related to stack checking? FAIL: gnat.dg/debug11.adb scan-assembler-times 0x5a.*DW_AT_discr_list 1 FAIL: gnat.dg/debug11.adb scan-assembler-times 0x80.*DW_AT_discr_list 1 FAIL: gnat.dg/trampoline4.adb scan-assembler GNU-stack.*x FAIL: gnat.dg/warn5.adb (test for excess errors) I haven't tried looking at the failures yet, and might not spend much more time on this. Two of them are debug related, and debug support is a work in progress. I need to finish the native riscv64-linux support before we can do anything useful there, and I'd like to get back to working on that as soon as possible. The GNU-stack error looks a little worrisome. I'd expect a linux port to get GNU-stack stuff right without much trouble. The last one is warn5.adb:29:30: warning: source alignment (4) < alignment of "Element_Type" (8) Maybe something I copied from the mips linux port is wrong for riscv64 linux. Jim
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Sat, Jul 7, 2018 at 10:06 AM, Andreas Schwab wrote: > On Jul 07 2018, Jim Wilson wrote: > >> If you build and install binutils, and then build and install gcc, the >> build will work. > > Not if the compiler was built in a canadian cross. That's the only way > to bootstrap an Ada compiler. It worked for me. I have RISC-V Fedora Linux Ada compiler binaries that I built cross from an x86_64 Ubuntu 18.04 system. You should only see the gas error if your gas sources are in the same source tree as your gcc sources. if you have separate binutils and gcc source trees, the build should work. In the gcc/configure.ac file, see the in_tree_gas and in_tree_gas_elf variables, which are set if gas/ELF gas are in the same source tree. And then look at configure, and note that configure makes assumptions about gas features when these variables are set, instead of doing run-time assembler checks. I've done number of canadian cross compiler builds, and I've never run into this gas problem in any of them, but I always use separate binutils and gcc source trees for my builds. Jim
Re: [C++ PATCH] PR c++/79133
Hi, On 07/07/2018 01:50, Ville Voutilainen wrote: + error_at (DECL_SOURCE_LOCATION (parms), + "capture %qE and lambda parameter %qE " + "have the same name", + cap, parms); Should we really print the same name twice? Looks like we don't have available (yet) a location for cap - that would likely enable fancy things - but in that case too I don't think the user would find that interesting seeing the same name twice. Also, we are using %E, thus we are pretty printing expressions - which in general we don't want to do - I see that in the case of cap it gives pretty obfuscated results for the last two tests (what the heck is __lambda3?!?). So, all in all, maybe print the name once, as parms, or something like that, for the time being? Or try to avoid %E altogether? Paolo.
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Jul 07 2018, Jim Wilson wrote: > You should only see the gas error if your gas sources are in the same > source tree as your gcc sources. Nope. > if you have separate binutils and gcc source trees, the build should > work. It's not the canadian cross build that fails, but the subsequent native build using the (misconfigured) canadian cross build. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [C++ PATCH] PR c++/79133
On 7 July 2018 at 16:15, Jason Merrill wrote:
> Did you consider handling this in check_local_shadow?
Roughly like this, not fully tested yet:
2018-07-07 Ville Voutilainen
gcc/cp/
PR c++/79133
* name-lookup.c (check_local_shadow): Reject captures and parameters
with the same name.
testsuite/
PR c++/79133
* g++.dg/cpp0x/lambda/lambda-shadow3.C: New.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 3aafb0f..cc2d3c0 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2640,6 +2640,7 @@ check_local_shadow (tree decl)
|| TREE_CODE (decl) == TYPE_DECL)))
&& DECL_FUNCTION_SCOPE_P (old)
&& (!DECL_ARTIFICIAL (decl)
+ || is_capture_proxy (decl)
|| DECL_IMPLICIT_TYPEDEF_P (decl)
|| (VAR_P (decl) && DECL_ANON_UNION_VAR_P (decl
{
@@ -2648,7 +2649,8 @@ check_local_shadow (tree decl)
/* Don't complain if it's from an enclosing function. */
if (DECL_CONTEXT (old) == current_function_decl
&& TREE_CODE (decl) != PARM_DECL
- && TREE_CODE (old) == PARM_DECL)
+ && TREE_CODE (old) == PARM_DECL
+ && !is_capture_proxy (decl))
{
/* Go to where the parms should be and see if we find
them there. */
@@ -2665,6 +2667,20 @@ check_local_shadow (tree decl)
return;
}
}
+ /* DR 2211: check that captures and parameters
+ do not have the same name. */
+ else if (current_lambda_expr ()
+ && DECL_CONTEXT (old) == lambda_function (current_lambda_expr ())
+ && TREE_CODE (old) == PARM_DECL
+ && is_capture_proxy (decl))
+ {
+ if (DECL_NAME (decl) != this_identifier)
+ error_at (DECL_SOURCE_LOCATION (old),
+ "capture %qE and lambda parameter %qE "
+ "have the same name",
+ decl, old);
+ return;
+ }
/* The local structure or class can't use parameters of
the containing function anyway. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
new file mode 100644
index 000..b006470
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++14 } }
+
+int main() {
+ int x = 42;
+ auto lambda = [x](int x) {}; // { dg-error "have the same name" }
+ auto lambda2 = [x=x](int x) {}; // { dg-error "have the same name" }
+ auto lambda3 = [x](auto... x) {}; // { dg-error "have the same name" }
+ auto lambda4 = [](auto... x) {
+auto lambda5 = [x...](auto... x) {}; // { dg-error "have the same name" }
+auto lambda6 = [x...](int x) {}; // { dg-error "have the same name" }
+ };
+}
Re: [C++ PATCH] PR c++/79133
On 7 July 2018 at 21:12, Paolo Carlini wrote: > Should we really print the same name twice? Looks like we don't have > available (yet) a location for cap - that would likely enable fancy things - > but in that case too I don't think the user would find that interesting > seeing the same name twice. Also, we are using %E, thus we are pretty > printing expressions - which in general we don't want to do - I see that in > the case of cap it gives pretty obfuscated results for the last two tests > (what the heck is __lambda3?!?). So, all in all, maybe print the name once, > as parms, or something like that, for the time being? Or try to avoid %E > altogether? What should I print instead of %E?
Re: [C++ PATCH] PR c++/79133
On 7 July 2018 at 21:55, Ville Voutilainen wrote:
> On 7 July 2018 at 21:12, Paolo Carlini wrote:
>> Should we really print the same name twice? Looks like we don't have
>> available (yet) a location for cap - that would likely enable fancy things -
>> but in that case too I don't think the user would find that interesting
>> seeing the same name twice. Also, we are using %E, thus we are pretty
>> printing expressions - which in general we don't want to do - I see that in
>> the case of cap it gives pretty obfuscated results for the last two tests
>> (what the heck is __lambda3?!?). So, all in all, maybe print the name once,
>> as parms, or something like that, for the time being? Or try to avoid %E
>> altogether?
>
> What should I print instead of %E?
%qD instead of %qE, presumably. That seems to do the same thing in the
new patch, but I can sure change it.
Attached.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 3aafb0f..b883054 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2640,6 +2640,7 @@ check_local_shadow (tree decl)
|| TREE_CODE (decl) == TYPE_DECL)))
&& DECL_FUNCTION_SCOPE_P (old)
&& (!DECL_ARTIFICIAL (decl)
+ || is_capture_proxy (decl)
|| DECL_IMPLICIT_TYPEDEF_P (decl)
|| (VAR_P (decl) && DECL_ANON_UNION_VAR_P (decl
{
@@ -2648,7 +2649,8 @@ check_local_shadow (tree decl)
/* Don't complain if it's from an enclosing function. */
if (DECL_CONTEXT (old) == current_function_decl
&& TREE_CODE (decl) != PARM_DECL
- && TREE_CODE (old) == PARM_DECL)
+ && TREE_CODE (old) == PARM_DECL
+ && !is_capture_proxy (decl))
{
/* Go to where the parms should be and see if we find
them there. */
@@ -2665,6 +2667,20 @@ check_local_shadow (tree decl)
return;
}
}
+ /* DR 2211: check that captures and parameters
+ do not have the same name. */
+ else if (current_lambda_expr ()
+ && DECL_CONTEXT (old) == lambda_function (current_lambda_expr ())
+ && TREE_CODE (old) == PARM_DECL
+ && is_capture_proxy (decl))
+ {
+ if (DECL_NAME (decl) != this_identifier)
+ error_at (DECL_SOURCE_LOCATION (old),
+ "capture %qD and lambda parameter %qD "
+ "have the same name",
+ decl, old);
+ return;
+ }
/* The local structure or class can't use parameters of
the containing function anyway. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
new file mode 100644
index 000..b006470
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++14 } }
+
+int main() {
+ int x = 42;
+ auto lambda = [x](int x) {}; // { dg-error "have the same name" }
+ auto lambda2 = [x=x](int x) {}; // { dg-error "have the same name" }
+ auto lambda3 = [x](auto... x) {}; // { dg-error "have the same name" }
+ auto lambda4 = [](auto... x) {
+auto lambda5 = [x...](auto... x) {}; // { dg-error "have the same name" }
+auto lambda6 = [x...](int x) {}; // { dg-error "have the same name" }
+ };
+}
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Sat, Jul 7, 2018 at 11:30 AM, Andreas Schwab wrote: > On Jul 07 2018, Jim Wilson wrote: >> if you have separate binutils and gcc source trees, the build should >> work. > > It's not the canadian cross build that fails, but the subsequent native > build using the (misconfigured) canadian cross build. This works for me. I have a sysroot created from a live system. I configure/build/install a cross binutils, then cross gcc. I put the cross install tree on my path, then I configure/build/install the canadian cross binutils and then gcc. Then I copy the canadian cross install tree to the RISC-V system and use it to bootstrap a native gcc with Ada. This is also presumably what the debian, fedora, and gentoo folks did to get their first native compiler. They didn't report any problems. Is this the first time you are trying to build a native RISC-V compiler for OpenSuse? If you already built a C/C++ compiler, then I would expect the Ada compiler build to work the same way. But if this is your first native RISC-V compiler build attempt then maybe there is something different about how you are trying to do the build. I could share my build scripts with you but they are pretty simple. It is also possible to build a canadian cross compiler from github riscv/riscv-gnu-toolchain using the linux-native makefile rule, but since it has its own copy of glibc you might run into glibc versioning problems. One thing I could mention is that I started with a gcc-7.3 release, because Ubuntu 18.04 has gcc-7.3 as the native compiler, and I wasn't sure if gcc-7 Ada could build gcc-9 Ada. Sometimes old Ada versions can't compile new Ada versions. So I actually did the canadian cross build with binutils-2.30 and gcc-7.3.1, and then moved up from gcc-7 to gcc-9 on the RISC-V side. I maybe haven't tried a canadian cross build with a newer gcc version, so maybe something broke after gcc-7. That seems unlikely though. If you can give me details about exactly how you are trying to canadian cross build the Ada compiler, I can try to reproduce your problem here. Jim
Re: [C++ PATCH] PR c++/79133
Needed one more tweak; when dealing with a capture proxy, always bail
out and never fall through to the warning-handling
code below the DR 2211 check.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 3aafb0f..fee5482 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2640,6 +2640,7 @@ check_local_shadow (tree decl)
|| TREE_CODE (decl) == TYPE_DECL)))
&& DECL_FUNCTION_SCOPE_P (old)
&& (!DECL_ARTIFICIAL (decl)
+ || is_capture_proxy (decl)
|| DECL_IMPLICIT_TYPEDEF_P (decl)
|| (VAR_P (decl) && DECL_ANON_UNION_VAR_P (decl
{
@@ -2648,7 +2649,8 @@ check_local_shadow (tree decl)
/* Don't complain if it's from an enclosing function. */
if (DECL_CONTEXT (old) == current_function_decl
&& TREE_CODE (decl) != PARM_DECL
- && TREE_CODE (old) == PARM_DECL)
+ && TREE_CODE (old) == PARM_DECL
+ && !is_capture_proxy (decl))
{
/* Go to where the parms should be and see if we find
them there. */
@@ -2665,6 +2667,20 @@ check_local_shadow (tree decl)
return;
}
}
+ /* DR 2211: check that captures and parameters
+ do not have the same name. */
+ else if (is_capture_proxy (decl))
+ {
+ if (current_lambda_expr ()
+ && DECL_CONTEXT (old) == lambda_function (current_lambda_expr ())
+ && TREE_CODE (old) == PARM_DECL
+ && DECL_NAME (decl) != this_identifier)
+ error_at (DECL_SOURCE_LOCATION (old),
+ "capture %qD and lambda parameter %qD "
+ "have the same name",
+ decl, old);
+ return;
+ }
/* The local structure or class can't use parameters of
the containing function anyway. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
new file mode 100644
index 000..b006470
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++14 } }
+
+int main() {
+ int x = 42;
+ auto lambda = [x](int x) {}; // { dg-error "have the same name" }
+ auto lambda2 = [x=x](int x) {}; // { dg-error "have the same name" }
+ auto lambda3 = [x](auto... x) {}; // { dg-error "have the same name" }
+ auto lambda4 = [](auto... x) {
+auto lambda5 = [x...](auto... x) {}; // { dg-error "have the same name" }
+auto lambda6 = [x...](int x) {}; // { dg-error "have the same name" }
+ };
+}
Re: [C++ PATCH] PR c++/79133
Hi,
On 07/07/2018 23:20, Ville Voutilainen wrote:
+ error_at (DECL_SOURCE_LOCATION (old),
+ "capture %qD and lambda parameter %qD "
+ "have the same name",
+ decl, old);
Let's consider, say (with -Wshadow):
int main() {
int x = 42;
auto lambda0 = [x]() { int x; };
}
I'm thinking that the new diagnostic should be more consistent with it.
Paolo.
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Jul 07 2018, Jim Wilson wrote: > This is also presumably what the debian, fedora, and gentoo folks did > to get their first native compiler. They didn't report any problems. Of course, they didn't build an ada compiler. > Is this the first time you are trying to build a native RISC-V > compiler for OpenSuse? I have bootstrapped several architectures for SUSE and openSUSE, thank you. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH] fold strings as long as the array they're stored in (PR 86428)
While working on other string folding improvements (PR 77357)
I came across another distinct case where GCC could do better:
it doesn't consider as candidates strings that have as many
elements as the size of the array they are stored in, even if
their length is within the bounds of the array. For instance,
only the first strlen() call below is folded even though
the arguments to both are valid NUL-terminated strings.
const char a[4] = "123";
int f (void)
{
return strlen (a); // folded
}
const char b[4] = "123\0";
int g (void)
{
return strlen (b); // not folded
}
The attached tiny patch adjusts the the string_constant() function
to recognize as valid string constants all those whose length (as
returned by strlen()) is less than the size of the array they are
stored in.
Tested on x86_64-linux.
Testing of an earlier version of the patch exposed what I think
is a deficiency in the (very) early strlen folding: c_strlen()
folds expressions of the form strlen(A + I) to sizeof(A) - I when
A is an array of known size and I a non-const variable. This not
only prevents -Warray-bounds from warning on invalid indices but
also defeats other, possibly more profitable optimizations based
on the range of the result of the strlen() call. The logs show
that the code dates at least as far back as 1992. With VRP and
other data flow based optimizations I think we can do better
today. I opened bug 86434 to improve things.
Martin
PR tree-optimization/86428 - strlen of const array initialized with a string of the same length not folded
gcc/ChangeLog:
PR tree-optimization/86428
* expr.c (string_constant): Handle string literals of
length up to the size of the array they are stored in.
gcc/testsuite/ChangeLog:
PR tree-optimization/86428
* gcc.dg/strlenopt-49.c: New test.
* gcc.c-torture/execute/builtins/strlen-3.c: Adjust.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 262437)
+++ gcc/expr.c (working copy)
@@ -11358,7 +11358,6 @@ string_constant (tree arg, tree *ptr_offset)
}
else if (VAR_P (array) || TREE_CODE (array) == CONST_DECL)
{
- int length;
tree init = ctor_for_folding (array);
/* Variables initialized to string literals can be handled too. */
@@ -11367,22 +11366,25 @@ string_constant (tree arg, tree *ptr_offset)
|| TREE_CODE (init) != STRING_CST)
return 0;
- /* Avoid const char foo[4] = "abcde"; */
- if (DECL_SIZE_UNIT (array) == NULL_TREE
- || TREE_CODE (DECL_SIZE_UNIT (array)) != INTEGER_CST
- || (length = TREE_STRING_LENGTH (init)) <= 0
- || compare_tree_int (DECL_SIZE_UNIT (array), length) < 0)
- return 0;
+ tree array_size = DECL_SIZE_UNIT (array);
+ if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
+ return NULL_TREE;
- /* If variable is bigger than the string literal, OFFSET must be constant
- and inside of the bounds of the string literal. */
- offset = fold_convert (sizetype, offset);
- if (compare_tree_int (DECL_SIZE_UNIT (array), length) > 0
- && (! tree_fits_uhwi_p (offset)
- || compare_tree_int (offset, length) >= 0))
- return 0;
+ /* Avoid returning a string that doesn't fit in the array
+ it is stored in, like
+ const char a[4] = "abcde";
+ but do handle those that fit even if they have excess
+ initializers, such as in
+ const char a[4] = "abc\000\000";
+ The excess elements contribute to TREE_STRING_LENGTH()
+ but not to strlen(). */
+ unsigned HOST_WIDE_INT length = strlen (TREE_STRING_POINTER (init));
+ if (compare_tree_int (array_size, length + 1) < 0)
+ return NULL_TREE;
- *ptr_offset = offset;
+ /* Callers should verify that OFFSET is within the bounds
+ of the array and warn for out-of-bounds offsets. */
+ *ptr_offset = fold_convert (sizetype, offset);
return init;
}
Index: gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c
===
--- gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c (revision 262437)
+++ gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c (working copy)
@@ -2,8 +2,11 @@
Test strlen on const variables initialized to string literals.
- Written by Jakub Jelinek, 9/14/2004. */
+ Written by Jakub Jelinek, 9/14/2004.
+ { dg-do compile }
+ { dg-options "-O2 -Wall -fdump-tree-optimized" } */
+
extern void abort (void);
extern __SIZE_TYPE__ strlen (const char *);
extern char *strcpy (char *, const char *);
@@ -10,7 +13,6 @@ extern char *strcpy (char *, const char *);
static const char bar[] = "Hello, World!";
static const char baz[] = "hello, world?";
static const char larger[20] = "short string";
-extern int inside_main;
int l1 = 1;
int x = 6;
@@ -59,12 +61,10 @@ main_test(void)
if (strlen (&larger[10]) != 2)
abort ();
- inside_main = 0;
- /* This will result in strlen call, because larger
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Sat, Jul 7, 2018 at 2:43 PM, Andreas Schwab wrote: > On Jul 07 2018, Jim Wilson wrote: > >> This is also presumably what the debian, fedora, and gentoo folks did >> to get their first native compiler. They didn't report any problems. > > Of course, they didn't build an ada compiler. But building an Ada compiler works exactly the same as building C and C++ compilers. There should really be no difference. >> Is this the first time you are trying to build a native RISC-V >> compiler for OpenSuse? > > I have bootstrapped several architectures for SUSE and openSUSE, thank > you. I am aware that you have much experience building stuff. But building RISC-V is a little different than the others, because of link-time relaxations deleting code, which means some things that work for other targets don't work for RISC-V. It is possible that the scheme you are using to build canadian cross compilers will work for other targets but not RISC-V because of this problem. That is why I asked if this is your first attempt to canadian cross build a RISC-V native compiler. And because of the above, that building Ada should be no different from building C and C++. Anyways, all I can repeat is what I've said before. It works for me. I can give you my trivial build scripts if you want. Otherwise, you have to give me enough info that I can reproduce the problem that you ran into. Jim
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Jul 07 2018, Jim Wilson wrote: > But building an Ada compiler works exactly the same as building C and > C++ compilers. There should really be no difference. That Ada compiler is unique in that it uses exceptions. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [C++ PATCH] PR c++/79133
On 8 July 2018 at 00:35, Paolo Carlini wrote:
> Hi,
>
> On 07/07/2018 23:20, Ville Voutilainen wrote:
>>
>> + error_at (DECL_SOURCE_LOCATION (old),
>> + "capture %qD and lambda parameter %qD "
>> + "have the same name",
>> + decl, old);
>
> Let's consider, say (with -Wshadow):
>
> int main() {
> int x = 42;
> auto lambda0 = [x]() { int x; };
> }
>
> I'm thinking that the new diagnostic should be more consistent with it.
There are a couple of errors that do an "error: redeclaration of foo"
followed by an inform "previously declared here". I would suggest that I do
an "error: declaration of parameter foo"
followed by an inform "previously declared as a capture here". How
does that sound?
That would make this more consistent with such a shadow warning, but I
don't want
to use the shadowing wording (which would be easy to do; just set
'shadowed' and do
a 'goto inform'), because this isn't shadowing in the precise sense;
the shadowing cases
are warnings, whereas this is more like the redeclaration errors in
the same function.
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
> I haven't tried looking at the failures yet, and might not spend much > more time on this. Two of them are debug related, and debug support > is a work in progress. I need to finish the native riscv64-linux > support before we can do anything useful there, and I'd like to get > back to working on that as soon as possible. No clue about debug11.adb, maybe Pierre-Marie could shed some light on it. > The GNU-stack error looks a little worrisome. I'd expect a linux port to > get GNU-stack stuff right without much trouble. The test checks that -ftrampolines forces the use of trampolines instead of descriptors. If trampolines are generated on the stack for RISC-V, then the stack should be made executable when there are built. Otherwise you can add the appropriate triplet to the dg-skip-if line. In any case, that's benign since trampolines are not generated by default now. > The last one is warn5.adb:29:30: warning: source alignment (4) < alignment > of "Element_Type" (8) Maybe something I copied from the mips linux port is > wrong for riscv64 linux. No, this looks as expected, you just need to add the appropriate triplet to the list on line 29 when you have 15 seconds to kill. Patchlet preapproved. -- Eric Botcazou
Re: [C++ PATCH] PR c++/79133
Hi,
On 08/07/2018 00:09, Ville Voutilainen wrote:
On 8 July 2018 at 00:35, Paolo Carlini wrote:
Hi,
On 07/07/2018 23:20, Ville Voutilainen wrote:
+ error_at (DECL_SOURCE_LOCATION (old),
+ "capture %qD and lambda parameter %qD "
+ "have the same name",
+ decl, old);
Let's consider, say (with -Wshadow):
int main() {
int x = 42;
auto lambda0 = [x]() { int x; };
}
I'm thinking that the new diagnostic should be more consistent with it.
There are a couple of errors that do an "error: redeclaration of foo"
followed by an inform "previously declared here". I would suggest that I do
an "error: declaration of parameter foo"
followed by an inform "previously declared as a capture here". How
does that sound?
Sounds pretty good to me, I think this is the way to go but I'm not sure
about the details...
That would make this more consistent with such a shadow warning, but I
don't want
to use the shadowing wording (which would be easy to do; just set
'shadowed' and do
a 'goto inform'), because this isn't shadowing in the precise sense;
the shadowing cases
are warnings, whereas this is more like the redeclaration errors in
the same function.
... indeed and that annoys me a bit. Not having studied at all c++/79133
so far (sorry) it seems a little weird to me that according to the
standard we have to handle the two types of "shadowing" in different
ways, one more strict, one less. Thus I would suggest double checking
the details of that, eventually with Jason too in terms of the actual
patch you would like to apply.
Paolo.
Re: [C++ PATCH] PR c++/79133
On 8 July 2018 at 01:54, Paolo Carlini wrote: >> That would make this more consistent with such a shadow warning, but I >> don't want >> to use the shadowing wording (which would be easy to do; just set >> 'shadowed' and do >> a 'goto inform'), because this isn't shadowing in the precise sense; >> the shadowing cases >> are warnings, whereas this is more like the redeclaration errors in >> the same function. > > ... indeed and that annoys me a bit. Not having studied at all c++/79133 so > far (sorry) it seems a little weird to me that according to the standard we > have to handle the two types of "shadowing" in different ways, one more > strict, one less. Thus I would suggest double checking the details of that, > eventually with Jason too in terms of the actual patch you would like to > apply. Well. The PR is about DR 2211 which, in simple terms, says that lambda parameters and captures cannot have the same name. See http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#2211 That's stricter than -Wshadow, but otherwise equally strict as the other error cases already handled in check_local_shadow. So I'll make this error case more consistent with the others. We already handle redeclaration errors slightly differently from shadowing warnings in that function.
Re: [PATCH] Fix __mmask* types on many AVX512 intrinsics
On Sat, Jul 7, 2018 at 11:15 AM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Jul 06, 2018 at 12:47:07PM +0200, Jakub Jelinek wrote:
>> On Thu, Jul 05, 2018 at 11:57:26PM +0300, Grazvydas Ignotas wrote:
>> > I think it would be more efficient if you took care of it. I won't
>> > have time for at least a few days anyway.
>
> Here is the complete patch, I found two further issues where
> the __mmask mismatch was in between the return type and what was used
> in the rest of the intrinsic, so not caught by my earlier greps.
>
> I've added (except for the avx512bitalg which seems to have no runtime
> test coverage whatsoever) tests that cover the real bugs and further
> fixed the avx512*-vpcmp{,u}b-2.c test because (rel) << i triggered UB
> if i could go up to 63.
>
> I don't have AVX512* hw, so I've just bootstrapped/regtested the patch
> normally on i686-linux and x86_64-linux AVX2 hw and tried the affected
> tests without the config/i386/ changes and with them under SDE.
> The patch should fix these FAILs:
>
> FAIL: gcc.target/i386/avx512bw-vpcmpb-2.c execution test
> FAIL: gcc.target/i386/avx512bw-vpcmpub-2.c execution test
> FAIL: gcc.target/i386/avx512f-vinsertf32x4-3.c execution test
> FAIL: gcc.target/i386/avx512f-vinserti32x4-3.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpb-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpgeb-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpgeub-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpgeuw-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpgew-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpleb-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpleub-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpleuw-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmplew-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpltb-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpltub-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpltuw-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpltw-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpneqb-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpnequb-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpnequw-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpneqw-2.c execution test
> FAIL: gcc.target/i386/avx512vl-vpcmpub-2.c execution test
>
> Ok for trunk?
>
> I guess we want to backport it soon, but would appreciate somebody testing
> it on real AVX512-{BW,VL} hw before doing the backports.
I've run the testsuite with this patch applied and all tests passed on
i7-7800X. There are avx512vl-vmovdqa64-1.c and avx512vl-vpermilpdi-1.c
failures, but those seem unrelated.
thanks,
Gražvydas
Re: [PATCH] fold strlen() of aggregate members (PR 77357)
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
GCC folds accesses to members of constant aggregates except
for character arrays/strings. For example, the strlen() call
below is not folded:
const char a[][4] = { "1", "12" };
int f (void) { retturn strlen (a[1]); }
The attached change set enhances the string_constant() function
to make it possible to extract string constants from aggregate
initializers (CONSTRUCTORS).
The initial solution was much simpler but as is often the case,
MEM_REF made it fail to fold things like:
int f (void) { retturn strlen (a[1] + 1); }
Handling those made the project a bit more interesting and
the final solution somewhat more involved.
To handle offsets into aggregate string members the patch also
extends the fold_ctor_reference() function to extract entire
string array initializers even if the offset points past
the beginning of the string and even though the size and
exact type of the reference are not known (there isn't enough
information in a MEM_REF to determine that).
Tested along with the patch for PR 86415 on x86_64-linux.
+ if (TREE_CODE (init) == CONSTRUCTOR)
+ {
+ tree type;
+ if (TREE_CODE (arg) == ARRAY_REF
+ || TREE_CODE (arg) == MEM_REF)
+ type = TREE_TYPE (arg);
+ else if (TREE_CODE (arg) == COMPONENT_REF)
+ {
+ tree field = TREE_OPERAND (arg, 1);
+ type = TREE_TYPE (field);
+ }
+ else
+ return NULL_TREE;
what's wrong with just
type = TREE_TYPE (field);
In response to your comment below abut size I simplified things
further so determining the type a priori is no longer necessary.
?
+ base_off *= BITS_PER_UNIT;
poly_uint64 isn't enough for "bits", with wide-int you'd use offset_int,
for poly you'd then use poly_offset?
Okay, I tried to avoid the overflow. (Converting between all
these flavors of wide int types is a monumental PITA.)
You extend fold_ctor_reference to treat size == 0 specially but then
bother to compute a size here - that looks unneeded?
Yes, well spotted, thanks! I simplified the code so this isn't
necessary, and neither is the type.
While the offset of the reference determines the first field in the
CONSTRUCTOR, how do you know the access doesn't touch
adjacent ones? STRING_CSTs do not have to be '\0' terminated,
so consider
char x[2][4] = { "abcd", "abcd" };
and MEM[&x] with a char[8] type? memcpy "inlining" will create
such MEMs for example.
The code is only used to find string constants in initializer
expressions where I don't think the size of the access comes
into play. If a memcpy() call results in a MEM_REF[char[8],
&x, 8] that's fine. It's a valid reference and we can still
get the underlying character sequence (which is represented
as two STRING_CSTs with the two string literals). I might
be missing the point of your question.
@@ -6554,8 +6577,16 @@ fold_nonarray_ctor_reference (tree type, tree ctor,
tree byte_offset = DECL_FIELD_OFFSET (cfield);
tree field_offset = DECL_FIELD_BIT_OFFSET (cfield);
tree field_size = DECL_SIZE (cfield);
- offset_int bitoffset;
- offset_int bitoffset_end, access_end;
+
+ if (!field_size && TREE_CODE (cval) == STRING_CST)
+ {
+ /* Determine the size of the flexible array member from
+the size of the string initializer provided for it. */
+ unsigned HOST_WIDE_INT len = TREE_STRING_LENGTH (cval);
+ tree eltype = TREE_TYPE (TREE_TYPE (cval));
+ len *= tree_to_uhwi (TYPE_SIZE (eltype));
+ field_size = build_int_cst (size_type_node, len);
+ }
Why does this only apply to STRING_CST initializers and not CONSTRUCTORS,
say, for
struct S { int i; int a[]; } s = { 1, { 2, 3, 4, 5, 6 } };
I can't think of a use for it. Do you have something in mind?
? And why not use simply
field_size = TYPE_SIZE (TREE_TYPE (cval));
like you do in c_strlen?
Yes, that's simpler, thanks.
Otherwise looks reasonable.
Attached is an updated patch. I also enhanced the handling
of non-constant indices. They were already handled before
to a smaller extent. (There may be other opportunities
here.)
Martin
PR middle-end/77357 - strlen of constant strings not folded
gcc/ChangeLog:
* builtins.c (c_strlen): Avoid out-of-bounds warnings when
accessing implicitly initialized array elements.
* expr.c (string_constant): Handle string initializers of
character arrays within aggregates.
* gimple-fold.c (fold_array_ctor_reference): Add argument.
Store element offset. As a special case, handle zero size.
(fold_nonarray_ctor_reference): Same.
(fold_ctor_reference): Add argument. Store subobject offset.
* gimple-fold.h (fold_ctor_reference): Add argument.
gcc/testsuite/ChangeLog:
PR middle-end/77357
* gcc.dg/strlenopt-49.c: New test.
* gcc.dg/strlenopt-50.c: New test.
* gcc.dg/strleno
