> Does Ada have signed booleans that are BOOLEAN_TYPE but do _not_
> have [-1, 0] as range? I think documenting [0, 1] for (single-bit
> precision?) unsigned BOOLEAN_TYPE and [-1, 1] for signed BOOLEAN_TYPE would
> be conservative.
All BOOLEAN_TYPEs are unsigned in Ada but may have precision >
> This should be fixed now. I rewrote the test to check the padding byte
> directly, instead of inspecting a copy of it which might not preserve
> the padding bits.
Great, thanks!
--
Eric Botcazou
> I don't see that. That's definitely not what GCC expects here,
> the left-most word of the doubleword should be unchanged.
>
> Your testcase should be a dg-do-run and probably more like
>
> NOMIPS16 int __attribute__((noipa)) test (const unsigned char *buf)
> {
> int val;
> ((unsigned
> It turns out that adaint.c includes other Windows header files than just
> windows.h, so defining WIN32_LEAN_AND_MEAN is not sufficient for it.
>
> gcc/ada/
>
> * adaint.c [_WIN32]: Undefine 'abort' macro.
I backported it onto the 13 branch.
--
Eric Botcazou
> Ensure that that container aggregate expressions are expanded as
> such and not as records even if the type of the expression is a
> record.
>
> gcc/ada/
>
> * exp_aggr.adb (Expand_N_Aggregate): Ensure that container
> aggregate expressions do not get expanded as records but
> This just applies the same fix to Expand_Array_Aggregate as the one that was
> recently applied to Convert_To_Assignments.
>
> gcc/ada/
>
> * exp_aggr.adb (Convert_To_Assignments): Tweak comment.
> (Expand_Array_Aggregate): Do not delay the expansion if the parent
> node is a
> Such assignments to container aggregates are later transformed into
> procedure calls to the procedures named in the Aggregate aspect
> definition, for which the delayed expansion is not required/expected.
>
> gcc/ada/
>
> * exp_aggr.adb (Convert_To_Assignments): Do not mark node for
>
Hi,
fold_ctor_reference attempts to use a recursive local processing in order to
call native_encode_expr on the leaf nodes of the constructor, before falling
back to calling native_encode_initializer if this fails. There are a couple
of issues related to endianness present in it:
1) it does
> Arg, once again, I'm sorry. I don't know how this happened. It would
> be trivial to fix it but since
>
> commit 4a48a38fa99f067b8f3a3d1a5dc7a1e602db351f
> Author: Eric Botcazou
> Date: Wed Jun 21 18:19:36 2023 +0200
>
> ada: Fix build of GNAT tools
>
> the build with Ada included
> We want to be able to treat such things as invariant somehow even if we
> can't do that for references to user data that might be changed by
> intervening code.
>
> That is, indicate that we know that the _REF actually refers to a const
> variable or is otherwise known to be unchanging.
>
>
> Is this an issue with the patch? Or does it need a newer Ada compiler
> to for building it?
Neither, it's very likely an issue with your build procedure: you need to use
a matching host Ada compiler to build a cross Ada compiler, that's documented
in
> But nobody is going to understand why the INTEGER_CST case goes the
> other way.
I can add a fat comment to that effect of course. :-)
> As you say we don't have a good way to say we're doing
> this to avoid undefined behavior, but then a view-convert back would
> be a good way to indicate
> I don't like littering the patterns with this and it's likely far from the
> only cases we have?
Maybe, but that's the only problematic case we have in Ada. It occurs only on
mainline because we have streamlined address calculations there, from out-of-
line to inline expansion, i.e. from run
Hi,
on the attached testcase, the Ada compiler gives a bogus warning:
storage_offset1.ads:16:52: warning: Constraint_Error will be raised at run
time [enabled by default]
This directly comes from the GENERIC folding setting a bogus TREE_OVERFLOW on
an INTEGER_CST during the (T)P - (T)(P + A)
> OK.
Thanks!
> Can we handle non-integer bitfields by recursing with a temporary buffer to
> encode it byte-aligned and then apply shifting and masking to get it in
> place? Or is that not worth it?
Certainly doable, something along these lines is implemented in varasm.c to
output these
Hi,
the encoder for CONSTRUCTORs assumes that all bit-fields (DECL_BIT_FIELD) have
integral types, but that's not the case in Ada where they may have pretty much
any type, resulting in a wrong encoding for them.
The attached fix filters out non-integral bit-fields, except if they start and
end
> Would it be better to use
>
> wi::to_uhwi (wi::to_wide (local->index) - wi::to_wide (local->min_index))
>
> to honor the actual sign of the indices? I think nothing forbids frontends
> to use a signed TYPE_DOMAIN here? But the difference should be always
> representable in an unsigned
Hi,
Ada supports arrays with negative indices, although the internal index type is
sizetype like in other languages, which is unsigned. This means that negative
values are represented by very large numbers, which works with a bit of care.
The attached test exposes a small loophole in
> && DECL_RETURN_VALUE_P (inner))
> diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc
> index 0c4f8b90c8e..460ef6f1f01 100644
> --- a/gcc/ada/gcc-interface/utils.cc
> +++ b/gcc/ada/gcc-interface/utils.cc
> @@ -1966,7 +1966,7 @@ finish_record_type (tree
> I think we really need Eric (as one who e.g. introduced the
> DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that
> on the Ada side.
I have been investigating this for a few days and it's no small change for Ada
and probably for other languages with dynamic types.
> I think we really need Eric (as one who e.g. introduced the
> DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that
> on the Ada side.
DECL_INVARIANT_P is only set on discriminants with no default value and those
are really invariant in Ada, i.e. do not change once set.
>
> probably also helps PR109612 and the other similar PR referenced therein.
Here's a more aggressive patch in this area, but it regresses guality tests,
for example:
+FAIL: gcc.dg/guality/ipa-sra-1.c -O2 -DPREVENT_OPTIMIZATION line 27 k ==
3
+FAIL: gcc.dg/guality/ipa-sra-1.c -O3 -g
> Haven't looked into detail, but just saving compilation time shouldn't be
> the only factor when deciding about debug info stuff, another and perhaps
> even more important would be whether it affects the emitted debug info.
At least it doesn't change the guality results.
--
Eric Botcazou
Hi,
insert_debug_temp_for_var_def has some strange code whereby it creates debug
temporaries for SINGLE_RHS (RHS for gimple_assign_single_p) but not for other
RHS in the same situation. Removing it saves 25% of compilation time at -g -O
for a pathological testcase I have.
It was recently pointed out that we generate symbolic links to ghost files
when building the GNAT tools, as the mlib-tgt-specific-*.adb files are gone.
Tested on x86-64/Linux, applied on the mainline. I'll backport this onto
branches after the GCC 13.1 release is out.
2023-04-25 Eric
> That "supposed to" is only *one* possible implementation.
> The one in CRIS - and I believe the preferred one; one I
> should advocate more - is to *always* expose clobbering of
> the flags.
Yes, both approaches are acceptable IMO and should work.
--
Eric Botcazou
> Tested on Aarch64/Linux by Richard S. (thanks!) and on x86-64/Linux by me,
> and applied on the mainline.
It turns out that it slightly broke the x86/Linux compiler, which is not yet
an acceptable trade-off. Adjusted like this, tested on x86[_64]/Linux, this
should not change anything for
This is the build failure of the Ada runtime for Aarch64 targets. The Aarch64
back-end now asserts that the main variant of scalar types has TYPE_USER_ALIGN
cleared, and that's not the case for scalar types declared with a confirming
alignment clause in Ada.
Tested on Aarch64/Linux by Richard
> If the
> (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c))
> to
> (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0)
> transformation is kosher for WORD_REGISTER_OPERATIONS, then I guess the
> invalid operation is then in
> simplify_context::simplify_binary_operation_1
> case AND:
>
> If we want to fix it in the combiner, I think the fix would be following.
> The optimization is about
> (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c))
> and IMHO we can only optimize it into
> (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0)
> if we know that the upper bits of the
> Originally I didn't really see this as an operation. But the more and
> more I ponder it feels like it's an operation and thus should be subject
> to WORD_REGISTER_OPERATIONS.
>
> While it's not really binding on RTL semantics, if we look at how some
> architectures implement reg->reg copies,
This is a regression present on the mainline and 12 branch at -O2, but the
issue is related to vectorization so was present at -O3 in earlier versions.
The vcondu expander that was added for VIS 3 more than a decade ago does not
fully work, because it does not filter out the unsigned condition
Hi Gaius,
> yes indeed and thanks for the patch!
You're welcome. The documentation was slightly broken again in the meantime,
but nothing really serious this time.
Again tested with a modern and an old version of Makeinfo. OK for mainline?
2023-03-27 Eric Botcazou
*
For the same reason as on PowerPC.
Tested on Aarch64/Linux, applied on the mainline and 12 branch.
2023-03-23 Eric Botcazou
* gnat.dg/div_zero.adb: Skip for aarch64*-*-* targets.
--
Eric Botcazoudiff --git a/gcc/testsuite/gnat.dg/div_zero.adb b/gcc/testsuite/gnat.dg/div_zero.adb
> Is there a way to say that the test results should be inverted on a
> particular platform (instead of purely unsupported)?
Yes, you can do pretty much what you want with the testsuite harness.
--
Eric Botcazou
> This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
Try the attached patch.
--
Eric Botcazoudiff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 227e3004077..d4f036a3f1e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++
Hi,
this is the incompatibility of -fstack-clash-protection with Windows SEH. Now
the Windows ports always enable TARGET_STACK_PROBE, which means that the stack
is always probed (out of line) so -fstack-clash-protection does nothing more.
Tested on x86-64/Windows and Linux, OK for all active
It is present on the mainline and 12 branch and comes from Andrew P. and me
forgetting about the VOID_TYPE_P case of SAVE_EXPRs.
Tested on x86-64/Linux, applied on mainline and 12 branch as obvious.
2023-02-14 Eric Botcazou
gcc/
* gimplify.cc (gimplify_save_expr): Add missing
> 3) we have also gcc/ada/gcc-interface/*.h with
> ada.h:#define INLINE static inline
> gigi.h:static inline unsigned HOST_WIDE_INT
> gigi.h:static inline bool
> gigi.h:static inline bool
> gigi.h:static inline bool
> gigi.h:static inline tree
> gigi.h:static inline tree
> gigi.h:static inline
> OK. PLACEHOLDER_EXPR are only relevant pre simplification.
I presume you mean "pre gimplification" here?
--
Eric Botcazou
This is needed to support the _Float32 and _Float64 types.
Tested on x86-64/Linux, applied on the mainline.
2023-01-13 Eric Botcazou
c-family/
* c-ada-spec.cc (is_float32): New function.
(is_float64): Likewise.
(is_float128): Tweak.
(dump_ada_node) : Call
Hi,
unlike other IPA passes, the ICF pass can be run at -O0 and some testcases
rely on this in the testsuite. Now it effectively creates a tail call so the
DF information needs be updated in this case after epilogue creation.
Tested on x86-64/Linux, OK for mainline?
2023-01-13 Eric
Hi,
this fixes the problematic interaction between bitfields, unions, SSO and SRA.
Tested on x86-64/Linux and SPARC/Solaris, OK for all active branches?
2023-01-11 Eric Botcazou
Andreas Krebbel
PR tree-optimization/108199
* tree-sra.cc (sra_modify_expr): Deal
Hi,
the Modula-2 documentation is rejected by older versions of Makeinfo because
the web of @node markers is fairly broken, apparently some subsections were
moved around, most notably between the Overview and Using sections, and the
@node markers were not (properly) adjusted.
This patch
> fixed now.
> bootstrapped successfully!
Thanks for fixing it. Another way out is to hide the Win32 API by defining
__GTHREAD_HIDE_WIN32API like libstdc++ does in its header files.
--
Eric Botcazou
> The libgcc parts look reasonable to me, but I can't approve them.
> Maybe Jonathan Yong can approve those parts as mingw-w64 target
> maintainer, or maybe a libgcc approver can do so.
OK.
> The libstdc++ parts are OK for trunk. IIUC they could go in
> separately, they just wouldn't be very
This just makes the pattern matching more robust.
Tested on SPARC64/Solaris and x86-64/Linux, applied on the mainline.
2022-11-29 Eric Botcazou
PR ada/107810
* gnat.dg/unchecked_convert9.adb: Adjust pattern.
--
Eric Botcazoudiff --git
Hi,
there is a thinko in the op1_range method of ranger's operator_bitwise_xor
class in a boolean context: if the result is known to be true, it may infer
than a specific operand is false without any basis.
Tested on x86-64/Linux, OK for mainline, 12 and 11 branches?
2022-11-25 Eric
Hi,
when two arrays of scalars have a different storage order in Ada, the
front-end makes sure that the conversion is performed component-wise
so that each component can be reversed. So it's a little bit counter
productive that the ldist pass performs the opposite transformation
and synthesizes
> Ok if no regressions, perhaps the test needs to be in the ada test suite ?
Thanks. Sure, testcase added to gnat.dg like so:
* gnat.dg/machine_attr2.ads, gnat.dg/machine_attr2.adb: New test.
--
Eric Botcazoupackage Machine_Attr2 is
type Non_Secure is access procedure;
pragma
> Oh, do you have a testcase suitable for the testsuite?
C guality testcase attached, it fails on x86/Linux with -m32 on the gcc-12
branch (which does not have the fix):
FAIL: gcc.dg/guality/param-6.c -O1 -DPREVENT_OPTIMIZATION line 15 i == 5
FAIL: gcc.dg/guality/param-6.c -O2
> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
> on powerpc64le-linux-gnu, the result looked good. Both x86 and aarch64
> cfarm machines which I used for testing don't have gnat installed, do
> It looks reasonable - OK if the others CCed have no comments.
My only comment is that it needs to be tested with languages enabling -fnon-
call-exceptions by default (Ada & Go), if not already done.
--
Eric Botcazou
>I build GCC regularly from the weekly snapshots
>and so the decompression time adds up.
But is very largely dwarfed by the build time of the compiler, isn't it?
--
Eric Botcazou
> Eric, can you push the approved fix for this issue (look for a message
> from Richard P day or two back, approved by Richi)? I'm dealing with a
> medical issue and heading offline again momentarily.
Sure, done.
--
Eric Botcazou
> index 9778e776cf2..adb1e351e15 100644
> --- a/gcc/tree-ssa-ccp.cc
> +++ b/gcc/tree-ssa-ccp.cc
> @@ -4197,6 +4197,7 @@ const pass_data pass_data_fold_builtins =
>TODO_update_ssa, /* todo_flags_finish */
> };
>
> +template
> class pass_fold_builtins : public gimple_opt_pass
> {
> public:
> I can send the obvious patch to make it work as before and ignore the
> NULL which fixes this. I'm not sure if it should really be passing NULL
> around in the first place or not which is why I'm sharing the backtrace.
Thanks for the investigation. That's because the DECL_SOURCE_LOCATION of
Hi,
there is a thinko in the recent improvement by Jan:
2020-11-19 Jan Hubicka
* fold-const.c (operand_compare::operand_equal_p): Fix thinko in
COMPONENT_REF handling and guard types_same_for_odr by
virtual_method_call_p.
(operand_compare::hash_operand):
> gcc/ChangeLog:
>
> * file-prefix-map.cc (remap_filename): Allow remapping of relative paths
Small regression in Ada though, probably a missing guard somewhere:
=== gnat tests ===
Running target unix
FAIL: gnat.dg/specs/coverage1.ads (test for excess errors)
In order to
> And also:
>
> FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test
> FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution test
> FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 execution test
> FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O3 -g execution test
> FAIL:
> I was able to successfully build gcc-trunk using the provided patch.
> moreover, I was able to successfully build all of the packages used in
> the toolchain!
> (gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses,
> readline, gdbm, tcl, tk, openssl, xz-utils, sqlite, python3,
> Yes. But it is all the same: neither signed overflow nor unsigned
> overflow (of an addition, say) can be described as the result of an
> RTL comparison.
I disagree, see for example the implementation of the addvdi4_sp3 pattern (for
which we indeed use an UNSPEC) and of the uaddvdi4_sp32
> Do those loads still get scalarized at -O0?
Presumably not at the GIMPLE level, but possibly at the RTL level.
--
Eric Botcazou
> I have faced with "#error Timed lock primitives are not supported on
> Windows targets" and I'm not sure I understood the reason correctly.
>
> as far as I understand, the definition for
> `_GTHREAD_USE_MUTEX_TIMEDLOCK` comes from libstdc++/configure as a
> result of some test.
>
> why did I
> I suppose we could use memcmp on the as variable itself, to inspect
> the actual stored padding rather than the returned copy of it.
Yes, that's probably the only safe stance when optimization is enabled.
--
Eric Botcazou
> The test was only failing for me with -m32 (and not -m64), so I didn't
> notice until now. That probably means we should make the test fail more
> reliably if the padding isn't being cleared.
The tests fail randomly for me on SPARC64/Linux:
FAIL: 29_atomics/atomic/compare_exchange_padding.cc
> could you please refresh/recheck your patch for the current gcc master
> and solve the objections noted in the thread? is it possible?
I have attached a revised version of the original patch at:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html
This reimplements the GNU threads
It was broken by:
2022-08-31 Martin Liska
* config.build: Remove deprecated ports.
* config.gcc: Likewise.
* config.host: Likewise.
* configure.ac: Likewise.
* configure: Regenerate.
* config/pa/pa-hpux10.h: Removed.
*
> OK for trunk and 12 after a while of burn-in.
Thanks!
> Oh, do you have a testcase suitable for the testsuite?
I only have an Ada testcase for GDB, let me try to find something more usable.
--
Eric Botcazou
> You mean in CCV? That works yes, but only because (or if) the setter
> and getter of the CC reg both use CCV (so never use any other flag at
> the same time; CCV has an empty intersection with all other CC modes).
We're talking about CCC here AFAIK, i.e. the carry, not CCV.
--
Eric Botcazou
> COMPARE may also set CC register to a constant when both operands are
> known constants.
No, a COMPARE is never evaluated alone, only the CC user may be evaluated.
--
Eric Botcazou
> I get a clean testsuite run configured and bootstrapped with
>
> --enable-languages=c,c++,go,fortran,ada,obj-c++,jit --enable-host-shared
>
> Is there a PR or specific tests in either fortran or ada for those
> improvements? ie, something specific I should check for? Part of rangers
>
Hi,
the following change:
2021-07-28 Bin Cheng
* alias.c (init_alias_analysis): Don't skip prologue/epilogue.
broke the alias analysis for the hard frame pointer (when it is used as a
frame pointer, i.e. when the frame pointer is not eliminated) described in the
large comment at
> (set (reg:SI 93)
> (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]
>
> as
>
> (set (reg:SI 93)
> (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]
>
> which leads to incorrect results since LTU on MODE_CC register isn't the
> same as "unsigned less than" in x86 backend.
Hi,
we have been using an Ada compiler for the Aarch64 architecture configured
with SJLJ exceptions as for the other architectures for some time, and have
not run into any problems so far so the setting looks obsolete now.
OK for the mainline?
2022-10-24 Eric Botcazou
*
Hi,
until most other machine attributes, this one does not work in Ada because,
while it applies to pointer-to-function types, it is explicitly marked as
requiring declarations in the implementation.
Now, in Ada, machine attributes are specified like this:
type Non_Secure is access procedure;
> Eric - the docs of DECL_BIT_FIELD are vague enough "must be accessed
> specially" but ISTR it might eventually only apply to the fields
> (bit) size and not it's position. OTOH the Ada frontend might not
> be too careful in setting this flag for bit-packed structs?
It sets the flag when the
Hi,
this assertion in branch_prob:
if (bb == ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb)
{
location_t loc = DECL_SOURCE_LOCATION (current_function_decl);
gcc_checking_assert (!RESERVED_LOCATION_P (loc));
had been correct until:
2021-08-11 Bernd Edlinger
PR
> could you please refresh/recheck your patch for the current gcc master
> and solve the objections noted in the thread? is it possible?
I can do the former, but not the latter as my development setup (mostly
testing) on Windows has nearly vanished in the meantime. But this rewritten
> How does this compare with Eric B's proposal at
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
My proposal was to reimplement (and extend) the native thread model (win32)
instead of adding a new one, the advantage being that you don't need an extra
threading layer between
This is the infamous PR rtl-optimization/38644 rearing its ugly head for leaf
functions on SPARC more than a decade later... Richard E.'s generic solution
has never been implemented so let's do as other RISC back-ends did.
Tested on SPARC64/Linux, applied on all active branches.
2022-10-14
> Not a fan as it could potentially hide a real issue, but I don't really
> have a better solution.
Thanks.
> I pondered suggesting "access" affect type identity, but the cases where
> that's really important are probably better handled by the "fn spec"
> attribute, leaving "access" strictly
Hi,
if you compile the attached testcase with -O2 -fno-inline -Wall, you get:
In function 'process_array3':
cc1: warning: 'process_array4' accessing 4 bytes in a region of size 3 [-
Wstringop-overflow=]
cc1: note: referencing argument 1 of type 'char[4]'
t.c:6:6: note: in a call to function
> Though I admit I didn't go carefully through all 24 GET_MODE_WIDER_MODE
> uses, 54 FOR_EACH_MODE_IN_CLASS uses, 3 FOR_EACH_MODE uses, 24
> FOR_EACH_MODE_FROM, 6 FOR_EACH_MODE_UNTIL and 15 FOR_EACH_WIDER_MODE uses.
> It is more important to go through the GET_MODE_WIDER_MODE and
>
> Let me know if you believe this is a good approach? I've ran regression
> tests and this hasn't broken anything so far...
Small regression in Ada though, probably a missing guard somewhere:
=== gnat tests ===
Running target unix
FAIL: gnat.dg/loop_optimization23.adb 3 blank
Hi,
the recent optimization implemented for complex modes in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595865.html
contains an oversight for big-endian platforms in the "interesting corner
case" mentioned in the message: it uses a lowpart SUBREG when the integer
modes have different
The SPARC/Linux port is very similar to the SPARC/Solaris port nowadays so it
makes sense to copy the setting of the support for atomic primitives.
This fixes the single regression in the gnat.dg testsuite:
FAIL: gnat.dg/prot7.adb (test for excess errors)
Tested on SPARC64/Linux, applied on the
Hi,
even at -O0 there may be a fair amount of DF computation performed when
compiling large units and part of it appears to be useless.
Bootstrapped/regtested on x86-64/Linux, OK for the mainline?
2022-10-06 Eric Botcazou
* function.cc (thread_prologue_and_epilogue_insns): Update
> I'm wondering if testing DR_IS_WRITE (dra) is enough here and whether
> the logic also applies to RAW and WAR. So should it be either
> (DR_IS_WRITE (dra) || DR_IS_WRITE (drb)) or DR_IS_WRITE (dra) &&
> DR_IS_WRITE (drb) instead?
It's a self-dependence, i.e. dra == drb in the block. Or do you
Hi,
as shown by the attached testcase, there is a loophole in the unroll-and-jam
pass that can quickly result in wrong code generation. The code reads:
if (!compute_data_dependences_for_loop (outer, true, _nest,
, ))
{
if (dump_file &&
> Before my change we had always done the folding *only* for TREE_CONSTANT
> (arg) and my change allowed it for some cases of !TREE_CONSTANT (arg), but
> I did not want to touch the !TREE_CONSTANT (arg) case at all:
...to touch the TREE_CONSTANT (arg) case at all...
--
Eric Botcazou
> I think the better fix would be to only consider TREE_CONSTANT (arg)
> if it wasn't constant initially. Because clearly "simplify" intends
> to be "constant" here. In fact I wonder why we test !TREE_CONSTANT (arg)
> at all, we don't simplify 'arg' ...
>
> Eric added this test (previosuly we'd
> Hmm :/ But that means we _should_ force a sign extension but only
> from ptrofftype_p ()? That is, your test above should maybe read
>
>signop sgn = TYPE_SIGN (type);
>if (ptrofftype_p (type))
> sgn = SIGNED;
>
> assuming 'type' is the type of lowbnd
Yes, that's essentially
> Meh. OK, eventually would need "indirection" through a wide-int then.
> Like
>
> offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd)))
That would be OK if get_offset_range did the same, but it does not since it
forces a sign-extension whatever the sign of a large type:
> Hmm, can we instead do
>
> if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd))
>{
> const offset_int lb = offset_int::from (lowbnd, SIGNED);
> ...
>
> ?
Apparently not:
In file included from /home/eric/cvs/gcc/gcc/coretypes.h:460,
from
Hi,
the following bogus warning:
In function 'lto26',
inlined from 'main' at /home/eric/gnat/bugs/V721-018/b~lto26.adb:237:7:
lto26.adb:11:13: warning: writing 1 byte into a region of size 0 [-Wstringop-
overflow=]
11 | Set (R, (7, 0, 84, Stream_Element (I), 0, 0, 0), 1);
|
> Eric is probably most familiar with this, but can you make sure to bootstrap
> and test this on a SJLJ EH target? I'm not sure --enable-sjlj-exceptions
> is well tested anywhere but on targets not supporting DWARF EH and the
> configury is a bit odd suggesting the option is mostly ignored ...
Hi,
you can build a view conversion between pretty much anything in Ada including
between types with different sizes, although the compiler warns in this case
and gigi pads the smaller type to end up with the same size.
The attached testcase triggers an ICE at -O or above for one of them:
FAIL:
> For late generated vector types this might result in inconsistencies with
> early (user) generated types when using LTO.
Is that a problem? That's no different with regular array types.
> Is there context available somehow so we can do like the is_ overloads
> on a decl and use a default
Hi,
vector types are represented as array types with DW_AT_GNU_vector attribute in
the debug info and a range [0 .. TYPE_VECTOR_SUBPARTS - 1]. That's obviously
skewed toward the C family of languages, therefore the attached patch changes
the lower bound to the default for the language of the
1 - 100 of 174 matches
Mail list logo
