> 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 https://gcc.gnu.org/install/prerequisites.h
> 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.
>
> Per
> 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 char
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 C
> 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 accor
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:
> 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 ...
T
> 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 fai
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
> 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
>
> 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
> 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 instead
> 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
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 guard.
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 b
> 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
+++ b/gcc/te
> 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
> 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. SAVE_E
> && 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 r
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 output_const
> 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 value
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 on
> 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 non-in
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) ->
> 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 t
> 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 that
> 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
> 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
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, &loop_nest,
&datarefs, &dependences))
{
> 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,
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 on
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,
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
> 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 li
> PR target/104781
> * config.host (tmake_file): Add i386/32/t-eh-return-no-sse for
> 32-bit x86 Cygwin and Solaris.
> * config/i386/32/t-eh-return-no-sse: New file.
What about MinGW here?
--
Eric Botcazou
> Disabling sse/sse2 might be a problem especially on mingw where we need to
> restore SSE registers in the EH return, no?
Not in 32-bit mode I think, all XMM registers are call used.
--
Eric Botcazou
> Bootstrapped/regtested on {x86_64,i686,powerpc64le,aarch64,s390x}-linux,
> ok for trunk?
>
> 2022-03-13 Jakub Jelinek
>
> PR rtl-optimization/104814
> * ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb
> doesn't end with onlyjump_p.
>
> * gcc.c-torture/exec
> Here is an updated patch for it. Ok for trunk?
>
> 2022-03-14 Jakub Jelinek
>
> PR rtl-optimization/104814
> * ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb doesn't
> end with onlyjump_p. Assume BB_END (test_bb) is always non-NULL.
>
> * gcc.c-tortur
This is a regression present on mainline, 11 and 10 branches. When the serial
port is closed, we need to ensure that the port handle is properly reset for
it to be detected as closed.
Tested on x86-64/Linux, applied on mainline, 11 and 10 branches.
2022-03-24 Pascal Obry
PR ada/10
This used to work long ago but broke at some point, so I'm applying the fix
only on the mainline, all the more so that it deals the "section" attribute.
Tested on x86-64/Linux, applied on the mainline.
2022-03-25 Eric Botcazou
c-family/
* c-ada-spec.cc (dump_ada_import): Deal with th
> this is my first patch to GCC, if there is anything off, please, say
> so. I have used the default HTML formatting that comes with Emacs. I
> have created the patch using the `git format-patch` utility.
Thanks for your contribution. Small nit:
+ Support for 128bit integers has beed added.
Th
> I have run the tests on my usual Linux systems (little endian power10,
> little endian power9, big endian power8), but I don't have access to a
> VxWorks system. Eric does this fix the failure for you?
Yes, if you add '*' at the end of the selector, i.e. [istarget *-*-vxworks*].
> If it does f
> 2022-04-13 Jakub Jelinek
>
> PR target/105247
> * simplify-rtx.cc (simplify_const_binary_operation): For shifts
> or rotates by VOIDmode constant integer shift count use word_mode
> for the operand if int_mode is narrower than word.
>
> * gcc.c-torture/compile/p
> 2022-04-22 Jakub Jelinek
>
> PR rtl-optimization/105333
> * rtlanal.cc (replace_rtx): Use simplify_subreg or
> simplify_unary_operation if CONST_SCALAR_INT_P rather than just
> CONST_INT_P.
>
> * gcc.dg/pr105333.c: New test.
OK, thanks.
--
Eric Botcazou
> While playing around with the compiler options trying to find a solution, I
> made an interesting discovery which is that GCC support 64-bit compare and
> swap on SPARCv8plus but not on 32-bit SPARCv9:
>
> glaubitz@gcc202:~$ echo | gcc -mv8plus -E -dM -|grep -i SWAP
> #define __GCC_HAVE_SYNC_COM
> Does anyone know the reasoning behind this?
Solaris preserves the full 64-bit registers in 32-bit mode.
--
Eric Botcazou
This is a regression present on mainline and 11 branch: the new transformation
applied during expansion by Narrow_Large_Operation would incorrectly perform
name resolution for the operator again.
Tested on x86_64-suse-linux, applied on mainline and 11 branch.
2022-01-28 Eric Botcazou
> Unfortunately this breaks quite a lot of things.
Right, for example in Ada where we now happily turn a division by zero, which
should raise an exception with -gnatp, into nonsense. Do we really need this
rather useless optimization in GCC? Blindly mimicing LLVM is not a reason...
I have ins
This is what has been done for ages on SPARC/Solaris and makes it possible to
use 64-bit atomic instructions even in 32-bit mode.
Tested on SPARC64/Linux, applied on the mainline.
2022-01-31 Eric Botcazou
PR target/104189
* config/sparc/linux64.h (TARGET_DEFAULT): Add MASK_V8
> Since I didn't see anyone responding to this problem, I filed PR
> 104356 to record the regression.
> And yes this should be handled correctly.
Thanks. Note that we have an example of this in libgcc/libgcc2.c too.
--
Eric Botcazou
> Well, yes, we have to fix it. I will share my thoughts when coming
> along the bugreport.
IMO we should simply scrap it, as it does not serve any useful purpose, breaks
a very ancient and useful idiom and also introduces an artificial discrepancy
between 1/X and 2/X for example.
--
Eric Bot
> The optimization can be useful, it doesn't have to be for user written
> y = 1 / x; but can appear through inlining or some other optimizations, e.g.
> jump threading and suddenly we have constant 1 in some bb, if it a never
> executed at runtime block, it will be likely shorter because of the
>
> Yes, I think the intent is clear. The question is whether we should
> re-instantiate the clear intent of preserving a literal / 0 as well
> (for C, without -fnon-call-exceptions).
Note that the code is precisely compiled with -fnon-call-exceptions:
ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
# Prov
> Well, yes, we have to fix it.
Here's the fix we agreed upon in the audit trail, OK for the mainline?
PR tree-optimization/104356
* match.pd (X / bool_range_Y is X): Add guard.
(X / X is one): Likewise.
(X / abs (X) is X < 0 ? -1 : 1): Likewise.
(X / -X is
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -401,27 +401,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >
> > /* X / bool_range_Y is X. */
> > (simplify
> >
> >(div @0 SSA_NAME@1)
> >
> > - (if (INTEGRAL_TYPE_P (type) && ssa_name_has_boolean_range (@1))
> > + (if (INTEGRAL_TY
Hi,
this completes my fix for PR debug/101947 by emptying the base_types vector
before (re)populating it.
Tested on x86_64-suse-linux, OK for the mainline?
2022-02-04 Eric Botcazou
PR debug/104366
* dwarf2out.cc (dwarf2out_finish): Empty base_types.
(dwarf2out_early
> In the past stack sharing has been quite important for the linux
> kernel. So perhaps one of the tests we should do if we wanted to go
> forward in this cycle would be to test kernel builds to see if any start
> tripping over the stack space diagnostics they've put in place over the
> years.
St
> I don't think an option to go to pre-12 behavior is useful. I'll
> postpone the series to stage1.
FWIW fine with me.
--
Eric Botcazou
> I've committed a change to update libgo to the Go1.18beta2 release.
This apparently broke the build on SPARC/Solaris 11.3:
/homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:32:26: error:
reference to undefined name 'open'
32 | mmapFD = open(&devZero[0], 0 /* O_RDONL
> I've committed this patch to fix these problems. Bootstrapped and ran
> Go testsuite on x86_64-pc-linux-gnu and x86_64-solaris.
Fine by me, thanks for the quick turnaround!
--
Eric Botcazou
> gcc/testsuite/ChangeLog:
>
> PR target/79754
> * gcc.target/i386/pr79754.c: New test.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> Pushed to master.
And 11 branch apparently, but it should be:
/* { dg-do compile { target dfp } } */
instead of just:
/* { d
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check with no new failures. Ok for mainline?
>
>
> 2022-02-27 Roger Sayle
>
> gcc/ChangeLog
> PR middle-end/80270
> * expmed.cc (extract_integral_bit_field): If OP0 is a hard
> register, c
This fixes a thinko in my fix for the -freorder-blocks-and-partition glitch
with SEH on 64-bit Windows:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565208.html
Even if no exceptions are active, e.g. in C, we always need to consider calls.
Tested on x86-64/Windows, applied on mainli
> The transposition nolto -> notlo is confusing and it makes the long
> name even harder to read than it already is - I kept reading it as
> "not lo" until I realized it was a simply typo.
Thanks for catching this!
--
Eric Botcazou
> 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
> FOR_EACH_WIDER_M
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 'proc
> 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 impa
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 E
> 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
> 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
implementa
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 debug/101598
> 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 ali
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;
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
* config/aar
> (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.
Tha
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 th
> 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
> point
> 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
> 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
> 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
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.
* config/pa/pa-hpux10
> 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
> 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 ex
> 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
> 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 fa
> Do those loads still get scalarized at -O0?
Presumably not at the GIMPLE level, but possibly at the RTL level.
--
Eric Botcazou
> 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 patte
> 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, b
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);
|
> 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 /home/eric/cvs/gcc/gcc
> 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 :/ 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 equi
This is a regression present since the 10.x series, but the underlying issue
has been there since the TARGET_VEC_PERM_CONST hook was implemented, in the
form of an ICE when expanding a constant VEC_PERM_EXPR in V4QI, while the
back-end only supports V8QI constant VEC_PERM_EXPRs.
Tested on SPARC
Hi,
most cases of VIEW_CONVERT_EXPRs involving reverse scalar storage order are
disqualified for SRA because they are storage_order_barrier_p, but you can
still have a VIEW_CONVERT_EXPR to a regular composite type being applied to
a component of a record type with reverse scalar storage order, alt
Hi,
DW_OP_not is a bitwise, not a logical NOT, so it computes the wrong result in
a DWARF conditional expression.
Tested (GCC + GDB° on x86-64/Linux, OK for the mainline?
2022-05-13 Eric Botcazou
* dwarf2out.c (loc_list_from_tree_1) : Swap the operands
if the condition is a
> But this doesn't fix
>
> case TRUTH_NOT_EXPR:
> case BIT_NOT_EXPR:
> op = DW_OP_not;
> goto do_unop;
Nope (I couldn't trigger it after my change).
> I also wonder where we get the TRUTH_NOT_EXPR to expand from? I suspect
> some non-gimplified global tree?
Yes, it's in the
> OK. Possibly also qualifies for the branch(es) as wrong-code fix.
Thanks. It's not a regression, but I can indeed put in on recent branches.
--
Eric Botcazou
> But this doesn't fix
>
> case TRUTH_NOT_EXPR:
> case BIT_NOT_EXPR:
> op = DW_OP_not;
> goto do_unop;
Revised patch attached, using Jakub's suggestion. The original (buggy) DWARF
procedure for the Ada testcase I previously posted is:
.uleb128 0x8# (DIE (0x5b) D
> It won't work for types larger than size of address, it would need to use
> dwarf_OP (DW_OP_const_type) instead of DW_OP_lit0 in that case.
> But maybe TRUTH_NOT_EXPR will be never seen for such types and after all,
> even the loc_list_from_tree_1 INTEGER_CST case doesn't handle that
> (the RTL c
The problem is that subtypes are not part of the limited view of a package so
we need to use types in conjunction with limited_with clauses, which is not
always desirable since this yields less portable Ada bindings. The patch
also contains a small enhancement for complex floating-point types.
Te
1 - 100 of 174 matches
Mail list logo
