Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
> From the documentation
> (https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):
>
> %{S*}
>
> Substitutes all the switches specified to GCC whose names start
> with -S, but which also take an argument. This is used for switches like
> -o, -D, -I, etc. GCC considers -o foo as being one switch whose name
> starts with ‘o’. %{o*} substitutes this text, including the space. Thus
> two arguments are generated.
The ultimate spec(!) is to be found in gcc.cc though, which says:
%{S*} substitutes all the switches specified to GCC whose names start
with -S. This is used for -o, -I, etc; switches that take
arguments. GCC considers `-o foo' as being one switch whose
name starts with `o'. %{o*} would substitute this text,
including the space; thus, two arguments would be generated
%{S*&T*} likewise, but preserve order of S and T options (the order
of S and T in the spec is not significant). Can be any number
of ampersand-separated variables; for each the wild card is
optional. Useful for CPP as %{D*&U*&A*}.
> It looks like this is working as documented. I checked this with the
> following spec file:
But you wouldn't have a problem if it was, would you? What happens if the '+'
is changed to another character in the line passed to the driver.
--
Eric Botcazou
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
> Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this > option is dropped in switch-c.adb and doesn't get added to the ALI file. This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h and it looks like the '+' character is not matched by '*' or some such. -- Eric Botcazou
Re: When do I need -fnon-call-exceptions?
> On x864 Linux -fasynchronous-unwind-tables is the default. That is > probably sufficient to make your test case work. The testcase g++.dg/torture/except-1.C you recently added to the testsuite does not pass at all if -fnon-call-exceptions is not specified (and does not pass with optimization if -fno-delete-dead-exceptions is not specified). -- Eric Botcazou
Re: Probe emission in fstack-clash-protection
> That may ultimately be better for -fstack-check to make it more robust, > but it still wouldn't be a viable alternative for stack clash protection > for the reasons laid out in that blog post. Well, -fstack-check does that when it's possible, e.g. on Windows, but it's not on x86[_64]/Linux where you *cannot* probe below the stack pointer. -- Eric Botcazou
Re: gcc with the new WIN32 threads fails to compile libstdc++
> I'm assuming the problem also extends to the other __gthr_win32 routines as > well, __gthr_win32_create just happens to be the first symbol it cannot > find. > > Is there a way to fix this issue? How did you configure the compiler and what version of MinGW64 do you use? -- Eric Botcazou
Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64
> rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for
> any mode and thus leaves it to the generic code.
https://gcc.gnu.org/pipermail/gcc-patches/2016-October/460209.html
--
Eric Botcazou
Re: Possible regression in DF analysis
> The problem shows in loop-doloop.c when I introduce a loop end pattern > that replaces the first jump instruction (JUMP_INSN 15) with a pattern > that clobbers CC reg. However, the DF doesn't look like it works as > the doloop step cannot find the CC reg alive. Please see > loop-doloop.c:766. Hence, it introduces the doloop_end patterns, and > renders the compare instruction (INSN 14) dead code. leading to > errors. So df_get_live_out does not contain the CC register? iv_analysis_loop_init only performs a local update of the DF information, maybe it does not cover the basic block containing insn 14 and 15? -- Eric Botcazou
Re: Possible regression in DF analysis
> However, after this optimization I get the CC reg being dead after
> JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
> from fwprop1:
>
> (insn 14 11 15 3 (set (reg:CC 66 cc)
> (compare:CC (reg/v:SI 98 [ bytes ])
> (const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
> (nil))
> (jump_insn 15 14 16 3 (set (pc)
> (if_then_else (gtu (reg:CC 66 cc)
> (const_int 0 [0]))
> (label_ref 27)
> (pc))) "bad_cc.c":11:8 15 {condjump}
> (expr_list:REG_DEAD (reg:CC 66 cc)
> (int_list:REG_BR_PROB 955630228 (nil)))
> -> 27)
> (note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
> (jump_insn 18 16 19 4 (set (pc)
> (if_then_else (eq (reg:CC 66 cc)
> (const_int 0 [0]))
> (label_ref:DI 34)
> (pc))) "bad_cc.c":12:10 15 {condjump}
> (expr_list:REG_DEAD (reg:CC 66 cc)
> (int_list:REG_BR_PROB 365072228 (nil)))
> -> 34)
>
> Please observe the REG_DEAD note on the both jump instructions.
Passes that consume REG_DEAD/REG_UNUSED notes need to recompute them
explicitly, they are not updated on the fly.
--
Eric Botcazou
Re: GCC trunk bootstrap failure on i686-w64-mingw32
> So what could be causing it? An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html has broken --disable-sjlj-exceptions. That's now fixed. -- Eric Botcazou
Re: Build of any gcc breaks on my sparc / illumos env
> As you can see, I use both illumos as and ld, but I also tried using gnu as > with the same result. I also tried using gnu ld (which is not recommended > on a sparc build, AFAIK), but that brought in different problems earlier. > Anyone can help? Using GNU as + Solaris ld is the recommended combination with recent versions of the compiler, but Solaris ld must be recent enough, otherwise building for sparc-sun-solaris2.11 probably does not work indeed. -- Eric Botcazou
Re: New "Diving into GCC internals" section in newbies guide
> Hope this is helpful; please let me know if you see any mistakes, or if > there's room for improvement Nice work! In the "inside cc1" chapter, I think that IR is usually meant for "Intermediate Representation" rather than "Internal Representation" in this context. -- Eric Botcazou
Re: DWARF question about size of a variable
> Is there dwarf information that gives the size of a variable? I have a > test case which when run on Intel gdb can print the size of an > optimized out variable. However on PowerPC, gdb says the size > information for the variable is optimized out. Is there some DWARF > information that I can print on the Intel binary that shows the size > information for the variable even though the variable is optimized out? > Then by comparison on PowerPC I would expect the DWARF information > would either say the size of the variable is optimized out or there is > no information available. If you try to debug at an optimization level higher than -Og, your mileage may vary and depend on various factors; that's apparently an example where the debug info is slightly less damaged at -O3 on x86 than on PowerPC, but there are probably cases where this will be the other way around. -- Eric Botcazou
Re: qual_union_type help
> That makes sense during construction we also know what the value of > the discriminant is. What does the Ada front-end replace the > placeholder_exprs with? Can it simply be the value of the discriminant > at constructor? I haven't tried that. Ultimately all PLACEHOLDER_EXPRs need to be replaced by something in the code, i.e. they can only survive in (abstract) types. There is an entire machinery in tree.c for that, called both from the front-end and middle-end in Ada. You can replace it with an explicit value (SUBSTITUTE_IN_EXPR) or you can search for it in an object (SUBSTITUTE_PLACEHOLDER_IN_EXPR). You can presumably do it through the gimplification hook. -- Eric Botcazou
Re: qual_union_type help
> This makes sense this we can't gimplify a placeholder expression. So > this seems that when i make a constructor for the QUAL_UNION_TYPE i > must iterate the fields and replace the placeholder_expr to have a > reference to the discriminant via another COMPONENT_REF. Though does > this mean for the constructor i will need to create a temporary to > hold onto it to create another component_ref? The Ada compiler gets rid of all PLACEHOLDER_EXPRs in CONSTRUCTORs because the subtype of these CONSTRUCTORs is always constrained in Ada parlance, i.e. you know the value of the discriminant since it is assigned in the CONSTRUCTOR, so the gimplifier is indeed presumably not wired to eliminate them on its own. -- Eric Botcazou
Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
> Release managers. They certainly have authority on the timing, but not on the contents. > Working on that right now, sorry.. OK, thanks in advance. -- Eric Botcazou
Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
Martin, > The renaming patches have been just installed and I've built a few target > compilers so far. I'll be online in ~10 hours from now so I can address > potential issues caused by the patch. Who approved it though? The renaming of the C files in the ada/ directory is wrong and should be reverted ASAP. -- Eric Botcazou
Re: reordering of trapping operations and volatile
> Most C programmers would assume that volatile accesses already > provides this guarantee, so actually doing so would be good. I'm a little skeptical of this statement: if it was true, how come the most recent version of the standard does not provide it 30 years after the language was first standardized? > Or a more practical example: While debugging some embedded > device, it would also be very annoying if the compilers reorders > some trap before some debugging output. I could easily imagine > loosing hours figuring out what happens. The thing to do to avoid losing these hours is to debug the code at -O0. -- Eric Botcazou
Re: reordering of trapping operations and volatile
> Yes, although I think potentially trapping ops > are not moved before calls (as this would be > incorrect). So do you think it would be feasable > to prevent this for volatile too? Feasible probably, but why would this be desirable in C? It's not Java! -- Eric Botcazou
Re: atomic_load
> This is a silent and dangerous incorrect code generation issue. Let's avoid this kind of FUD, please, builtins are low-level devices and people must know what they are doing and be prepared for caveats. > If these functions are not meant to be used to exising > data, then at least the documentation needs to be changed > and include a big warning that this only happens to work > corectly if the data has sufficient alignment for the > specific architecture (which of course makes it impossible > to use this in a portable way). The last part of the sentence is again a blatant overstatement but I agree that the alignment caveat ought to be documented. Please suggest a wording to that effect and post a patch onto the gcc-patches@ ML. Thanks in advance. -- Eric Botcazou
Re: Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32
> Maybe it was the EH format changes or dwarf5 stuff backported, CCing > Eric. Indeed, the latter, the HAVE_LD_BROKEN_PE_DWARF5 kludge is incomplete. -- Eric Botcazou
Re: Signedness of boolean types (and Ada)
> I noticed while debugging why my "A?CST1:CST0" patch was broken for
> Ada, I noticed the following ranges for boolean types:
> # RANGE [0, 1] NONZERO 1
> _14 = checks__saved_checks_tos.482_2 > 0;
> # RANGE [0, 255] NONZERO 1
> _18 = _14 == 0;
> _19 = ~_18;
The '~' looks problematic if this is for Ada code, it ought to be:
_19 = _18 ^ 1;
See below.
> Should TYPE_UNSIGNED be always set for boolean types?
>
> I am testing the below patch to see if it fixes the problem, if we
> should assume TYPE_UNSIGNED is true for boolean types. If we should
> not assume that, then there is a problem with conversion between
> boolean types that have TYPE_UNSIGNED mismatched.
The patch is a nop, boolean types are always unsigned in Ada, see cstand.adb:
Set_Is_Unsigned_Type (Standard_Boolean);
but they have 8-bit precision instead of 1-bit precision so must be handled
with care, in particular BIT_NOT_EXPR should be avoided for them, see e.g. the
gimplifier:
if (TYPE_PRECISION (TREE_TYPE (*expr_p)) == 1)
*expr_p = build1_loc (input_location, BIT_NOT_EXPR,
TREE_TYPE (*expr_p),
TREE_OPERAND (*expr_p, 0));
else
*expr_p = build2_loc (input_location, BIT_XOR_EXPR,
TREE_TYPE (*expr_p),
TREE_OPERAND (*expr_p, 0),
build_int_cst (TREE_TYPE
(*expr_p), 1));
--
Eric Botcazou
Re: Issue with pointer types marked with scalar_storage_order
> I'm not really sure where exactly the bug is, because I'm not > quite sure if pointer types actually *should* be byte swapped. > > On the one hand, the typical use case of scalar_storage_order > is to simplify accessing binary data (read from a file or the > network) that was generated on a "foreign" architecture that > uses a different byte order. Those use cases are unlikely > to involve any pointer types, since pointer values from a > foreign system are typically not usable on the current > system anyway. > > On the other hand, even the name of the attribute specifically > refers to *scalar* types, and the C standard does classsify > pointer types amongst the scalar type. So maybe this was > originally intended? I don't think so, the feature was first implemented for Ada and, in Ada, pointer types (called access types) are *not* scalar types. So this indeed looks like a small oversight in the implementation. > Any comments or suggestions on what to do here? I'm going to conduct some testing in Ada but, barring unexpected fallout, I would be in favor of changing the GCC implementation. It's presumably a 1- line change in the reverse_storage_order_for_component_p predicate. -- Eric Botcazou
Re: On US corporate influence over Free Software and the GCC Steering Committee
> Here the relevant excerpt (but please go chech the quotation): > > "As an IBM employee, you are not allowed to use your gmail account to work > in any way on VNIC. You are not allowed to use your personal email account > as a "hobby". You are an IBM employee 100% of the time. > Please remove yourself completely from the maintainers file. I grant you a 1 > time exception on contributions to VNIC to make this change." > > > This is happened yesterday (literally). Troubling indeed, but this might just be an overzealous manager. IBM, like other corporations, has made significant technical contributions to GCC over the years, for example the scheduler and the vectorizer, and thus has assigned the copyright of these contributions to the FSF. -- Eric Botcazou
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
> I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. It does not build for Windows: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567582.html -- Eric Botcazou
Re: gcc does not reduce the function call to the result if called function is not static when using -O2, only with -O3, clang and msvc do the optimization also with -O2
> can someone explain to me why the -O2 optimizer is not able(allowed) to > reduce this small sample the same way as clang/msvc? Change the name of the function to something else than "main". -- Eric Botcazou
Re: DWARF64 gcc/clang flag discussion
> Sure enough - I was more getting at "would Clang's choice here have > much/any influence on GCC's choice in the future"? (ie: Is GCC > interested in compatibility with Clang?) I'd say yes, but this criterion comes second after consistency with itself. The latter dictates a -g switch so, once this is established, what -g switch can indeed be coordinated. -- Eric Botcazou
Re: mstackalign vs rbp order in gcc optimization level epilogue/prologue - O2/O3
> Would you folks consider this as a GCC bug? Do you folks see any issue in > the CLANG approach? Is there a way (any switch) in gcc which would reverse > the order of ‘setting %rbp’ vs ‘stack alignment code’ (like CLANG)? How does Clang align the frame pointer? What happens if the function uses dynamic stack allocation, e.g. by means of alloca? -- Eric Botcazou
Re: Run a single ada test
> I see check-gnat in some of the makefile input files but I do not see it > in the ones that are built. Is there something needed to specify when > configure is run to get it included? No, this works with some generic magic like for gcc; g++, gfortran and so on. -- Eric Botcazou
Re: Run a single ada test
> Is there a way to run a single ada test? The documentation mentions hows to > "run a subset of the tests by specifying which chapter to run" but not > individual tests. I tried this (and some variations) > > make -k check-ada RUNTESTFLAGS=gnat.exp=gnat.dg/opt86a.adb > > but it ran a whole bunch of tests actually NOT including the one I wanted. make -C gcc -k check-gnat RUNTESTFLAGS="dg.exp=opt86a.adb" You can omit the "-C gcc" if you run it from the gcc/ build dir of course. -- Eric Botcazou
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
> Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > are still lying around. I think that the e200 support was never contributed upstream. -- Eric Botcazou
Re: AVR CC0 transition
> I very much disagree with this. I think my approach was possibly the > only viable one, and definitely the most sensible one for this target. > Not only is there nothing meaningful to be gained from separating cc > setters and users on m68k given that almost all instructions (including > moves) clobber the flags, it is not really an actively maintained target > and any more adventurous approach would have introduced many more > possibilities for error. Generating exactly the same code as before as > much as possible was the correct goal IMO. Fair enough, but IMO the constraint that almost all instructions (including moves) clobber the flags is not sufficient (alone) to justify this approach, as it forces you to use an ad-hoc mechanism to eliminate redundant compares instead of the dedicated RTL pass, and may hinder scheduling in the case where it would be useful to schedule instructions, e.g. floating-point instructions, between the CC setters and the CC users. -- Eric Botcazou
Re: scalar_storage_order question
> Yes the following is a decent workaround:
> upal_u32be_t tempb;
> memcpy (&tempb, &u, sizeof(uint32_t));
> asm("":"+m"(tempb));
> uint32_t bu = tempb.val;
OK, let me try to do the same in the compiler then.
--
Eric Botcazou
Re: scalar_storage_order question
> What if we had this: > uint32_t u = 0x12345678; > upal_u32be_t tempb; > memcpy (&tempb, &u, sizeof(uint32_t)); > uint32_t bu = tempb.val; > > Is that valid? We still run into the wrong code with the above case. > memcpy here should be considered a byte-by-byte copy and therefor > should not have any type punning except for to bytes. The usual trick of people doing type punning and pretending they don't. ;-) No, this cannot work as-is, although it's probably fixable by blocking the propagation through the memcpy in case the scalar order is flipped, unlike the previous example. -- Eric Botcazou
Re: AVR CC0 transition
> Thanks, I will take a look at Bernd's work. IIRC, he took a > different approach from what was suggested in the wiki, right? Yes, let's say that it's a half-baked conversion, probably a consequence of the bounty. This might be good enough, depending on the architecture. -- Eric Botcazou
Re: scalar_storage_order question
> I notice this statement in the documentation: > Moreover, the use of type punning or aliasing to toggle the storage > order is not supported; that is to say, a given scalar object cannot > be accessed through distinct types that assign a different storage > order to it. > --- CUT --- > But I am not 100% sure that is the case here but I hope I am wrong in > saying this is not supported. This seems to me a fairly standard example of type punning: uint32_t u = 0x12345678; uint32_t bu = ((upal_u32be_t*)&u)->val; u = 0x12345678; uint32_t lu = ((upal_u32le_t*)&u)->val; u is accessed through upal_u32be_t and upal_u32le_t, i.e. BE and LE. -- Eric Botcazou
Re: Git ChangeLog policy for GCC Testsuite inquiry
> I strongly prefer to move towards relying on the git log. In my experience the output of git log is a total mess so cannot replace ChangeLogs. But we can well decide to drop ChangeLog for the testsuite. -- Eric Botcazou
Re: C2X Proposal, merge '.' and '->' C operators
> For what it's worth, that is how Go works. The '.' operator is used > for struct fields regardless of whether the left hand operand is a > struct or a pointer to a struct. Likewise in Ada. -- Eric Botcazou
Re: Testsuite not passing and problem with xgcc executable
> https://gcc.gnu.org/ml/gcc-testresults/2019-06/msg00810.html > results have been produced or there is something I am not aware of. You need to issue a third command: make mail-report.log -- Eric Botcazou
Re: Testsuite not passing and problem with xgcc executable
> Makefile:2323: recipe for target 'do-check' failed > make: *** [do-check] Error 2 > make: Target 'check' not remade because of errors. > > Please, can anyone let me know what am I doing wrong? Nothing, this just means that there are some failures in the testsuite. > Also, when running an input file using xgcc, I am gettig the following > error: > > xgcc: fatal error: cannot execute ‘cc1’: execvp: No such file or directory > compilation terminated. > > Can anyone let me what to do, when trying to execute the xgcc executable > from the build folder without installing it? You need to pass -B where contains the compiler cc1. -- Eric Botcazou
Re: On-Demand range technology [3/5] - The Prototype
> While I agree that symbolic ranges are a complication and that most > cases it currently handles are not "value-range" things I do not agree > with the idea that we can simply remove handling them and deal > with the fallout in some later point in the future. Eric may also be > able to show you "real" symbolic value-range magic. There are a couple of testcases in the testsuite that, I believe, require a minimal form of support for symbolic ranges: gcc.dg/tree-ssa/vrp94.c and gnat.dg/opt40.adb. They deal with the following pattern in C: if (x >= y) return 1; z = y - x; if (z <= 0) abort (); return z; where we want to eliminate the abort. Of course the C version doesn't really make sense on its own, but it's the translation of the Ada version where the if (z <= 0) abort (); is generated by the compiler (it's a range check in Ada parlance). I also agree that symbolic ranges are a complication but I don't understand why they would conceptually be treated differently from literal ranges. Of course things may been different practically speaking because I also agree that they are of lesser importance than literal ranges in most cases. > Note that symbolic ranges are already restricted to PLUS_EXPR > and MINUS_EXPR (and NEGATE_EXPR I think). There are > also "symbolic" (non-integer constant) ranges like [&a, &a]. Yes, the current implementation is restricted to additive operations. -- Eric Botcazou
Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .
> I do think so. The call is locally, linker should know it's local and > fix it up with local entry instead. We don't need to keep r12 always > hold the entry of being called function. Yes, but on VxWorks in kernel mode you first do partial linking and then the loader resolves the remaining relocations. None of them plays the usual dance with the local and global entry points implied by the ELFv2 ABI. -- Eric Botcazou
Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .
> Thank you Eric for the suggestion and say that we support in the loader > part ,can you please point on elfv2 reference that says implementation for > this specific case. I don't think there is a reference to this specific case in the ABI, only the general stuff about local and global entry points. We have had this patch in our tree for some time and it works well, so let me submit it for inclusion in the official tree. -- Eric Botcazou
Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .
> like above the control from "_ZThn8_N12Intermediate1vEv" (support
> function for this pointer update) is transferred
> "_ZN12Intermediate1vEv" by b inst (where its not updating the r12)
> and in the beginning of "_ZN12Intermediate1vEv" we are loading the
> toc base from r12 (which is incorrect ) ,we are investigating the
> issue and one way to fix the issue is that make THUNK to update the
> r12 ,the cal like bctrl or load the r12 with the function address in
> the _ZN12Intermediate1vEv prologue code .
Is that on VxWorks in kernel mode? If so, the loader doesn't abide by the
ELFv2 ABI so the simple way out is to disable asm thunks altogether:
#undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
#define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk
/* Return true if rs6000_output_mi_thunk would be able to output the
assembler code for the thunk function specified by the arguments
it is passed, and false otherwise. */
static bool
rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
const_tree)
{
/* The only possible issue is for VxWorks in kernel mode. */
if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP)
return true;
/* The loader neither creates the glue code sequence that loads r12 nor uses
the local entry point for the sibcall's target in the ELFv2 ABI. */
return DEFAULT_ABI != ABI_ELFv2;
}
--
Eric Botcazou
Re: A bug in vrp_meet?
> I have now applied this variant.
You backported it onto the 8 branch on Friday:
2019-05-03 Richard Biener
Backport from mainline
[...]
2019-03-07 Richard Biener
PR tree-optimization/89595
* tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
stmt iterator as reference, take boolean output parameter to
indicate whether the stmt was removed and thus the iterator
already advanced.
(dom_opt_dom_walker::before_dom_children): Re-iterate over
stmts created by folding.
and this introduced a regression for the attached Ada testcase at -O:
Program received signal SIGSEGV, Segmentation fault.
0x0102173c in set_value_range (
vr=0x17747a0 , t=VR_RANGE, min=0x76c3df78, max=, equiv=0x0)
at /home/eric/svn/gcc-8-branch/gcc/tree-vrp.c:298
298 vr->type = t;
on x86-64 at least. Mainline and 9 branch are not affected.
--
Eric Botcazoupackage Opt78 is
subtype Reasonable is Integer range 1..10;
type UC (D: Reasonable := 2) is record
S: String (1 .. D) := "Hi";
end record;
type AUC is access all UC;
procedure Proc (P : UC; Msg : String);
end Opt78;
-- { dg-do compile }
-- { dg-options "-O" }
package body Opt78 is
procedure Proc (P : UC; Msg : String) is
Default : UC := (1, "!");
begin
if P = Default then
raise Program_Error;
else
raise Constraint_Error;
end if;
end;
end Opt78;
Re: is re-running bootstrap after a change safe?
> Say if the first bootstrap succeeds and I then change a single > GCC .c file and rerun make bootstrap, am I guaranteed to see > the same fallout of the change as I would if I did a pristine > build in a clean directory? No, this would imply deleting the stage2 and stage3 compilers and that isn't what happens. Instead the compiler of each stage is updated in isolation. -- Eric Botcazou
Re: Function pointers to a nested function / contained procedure
> At the moment, I am at a loss of how to try to fix this. Any ideas? > Is there any other language which has such a feature, so a bit of > judicious copy & paste could be applied? (GNU) C and Ada since the dawn of time. There is an entire machinery in the middle-end and the back-ends to support this (look for trampolines/descriptors in the manual and the source code). This should essentially work out of the box for any language front-end. -- Eric Botcazou
Re: GCC missing -flto optimizations? SPEC lbm benchmark
> Hasn't GNAT sorted Ada elements in records (e.g. structures) by size > since near its initial addition to GCC in the mid-90s? This results in the > largest elements up front and minimizes the need for alignment gaps. No, that's a serious misconception, since one of the features of GNAT is to be compatible with C by default as much as possible. But we started to do some reordering recently when the records don't have (direct) equivalents in C. -- Eric Botcazou
Re: testsuite result updates for x86_64-w64-mingw32
> So looking at it again, this seems to be happening during stage3.
Yes, I should have realized it a while ago, you don't compile g-exptty.adb for
the compiler but only for the runtime... The backtrace seems to show that the
abort at libgcc/unwind-dw2.c:1386 is raised:
int size = dwarf_reg_size_table[__builtin_dwarf_sp_column ()];
if (size == sizeof(_Unwind_Ptr))
tmp_sp->ptr = (_Unwind_Ptr) cfa;
else
{
gcc_assert (size == sizeof(_Unwind_Word));
tmp_sp->word = (_Unwind_Ptr) cfa;
}
which is quite unexpected.
--
Eric Botcazou
Re: testsuite result updates for x86_64-w64-mingw32
> It's built with --disable-sjlj-exceptions --with-dwarf2 > > https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD > #L150 Then, if both the base compiler and the compiler to be built are configured that way, there is no reason why this cannot work. What's a little strange is that there is a .cold part in the backtrace: #14 0x015fd511 in uw_init_context_1.cold () at ../../../gcc-8-20181214/libgcc/unwind-dw2.c:1386 and this shouldn't happen for the compiler built during stage #1. Do you add -O2 to the STAGE1_CFLAGS or some such? If so, can you lower it to -O1 or -O0? -- Eric Botcazou
Re: testsuite result updates for x86_64-w64-mingw32
> Ah, that makes sense since the 32-bit SEH is different from the 64-bit one, > explains why the 64-bit builds work. Which EH mechanism does the base compiler use? The default one? We know that this works with the DWARF-2 mechanism (--disable-sjlj-exceptions). -- Eric Botcazou
Re: testsuite result updates for x86_64-w64-mingw32
> The gnat1 command that fails is > > mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/gnat1.exe -gnatwa -quiet > -nostdinc -dumpbase g-exptty.adb -auxbase-strip g-exptty.o -O2 -Wextra > -Wall -g -gnatpg -mtune=generic -march=i686 -gnatO g-exptty.o g-exptty.adb > -o E:\msys32-devel\tmp\ccAujHCD.s > > I attached gdb and set set env ADA_INCLUDE_PATH and it seems to not be able > to find some file but segfaults when printing the error, so I'm guessing > there's a heap corruption somewhere. > > The full stack trace is > https://gist.github.com/Mistuke/a62d45337f7515f5f4725fcff1c93395 > > It seem to not be able to find s-reldel.ads? Any tips on how to debug this? The file is not in the source tree so the failure is expected. In this case, Rtsfind.Load_Fail raises an exception which should be caught in the caller. The big difference between GCC 7 and GCC 8 here is documented on: https://gcc.gnu.org/gcc-8/changes.html "For its internal exception handling used on the host for error recovery in the front-end, the compiler now relies on the native exception handling mechanism of the host platform, which should be more efficient than the former mechanism." I presume that the problem occurs during stage #2, i.e. that the gnat1 at stake has been built by the base compiler, right? -- Eric Botcazou
Re: RTEMS Ada build problem on trunk
> I can build the trunk with a native > > gnat --version > GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] > Copyright (C) 1996-2018, Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk native compiler. How did you configure this latter compiler? -- Eric Botcazou
Re: Strange executable text files in the repository
> While working on Fedora gcc 9 rpm, I've noticed a couple of messages: > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/po > six/sys/ioccom.d is executable but has empty or no shebang, *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/po > six/sys/ttycom.d is executable but has empty or no shebang, *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.ads is > executable but has empty or no shebang, removing executable bit *** > WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.adb is > executable but has empty or no shebang, removing executable bit *** > WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libsanitizer/sanitizer_common/san > itizer_common_interceptors_ioctl.inc is executable but has empty or no > shebang, removing executable bit Typically (not for the sanitizer) because the files were created on Windows. > None of these files look like executable, any objections against (found > through > find [^o]* -type f -a -executable | xargs grep -L '^#!' > and removed from the list some ELF/Mach-O executables in the libgo (which > maybe shouldn't be executable anyway, we don't want people to run it when > they don't really know what it contains))? Do the libgo and/or > libphobos changes need to go through upstream first? > I've checked libsanitizer upstream and > sanitizer_common_interceptors_ioctl.inc isn't executable there. No objections for the couple of Ada files. -- Eric Botcazou
Re: Enabling vectorization at -O2 for x86 generic, core and zen tuning
> Note that I benchmarked -ftree-slp-vectorize separately before and > results was hit/miss, so perhaps enabling only -ftree-vectorize would > give better compile time tradeoffs. I was worried of partial memory > stalls, but I will benchmark it and also benchmark difference between > cost models. ; Alias to enable both -ftree-loop-vectorize and -ftree-slp-vectorize. ftree-vectorize Common Report Optimization Enable vectorization on trees. -- Eric Botcazou
Re: testsuite result updates for x86_64-w64-mingw32
> About the Ada compiler: it doesn't build on i686-w64-mingw32. It is > the reason why MSYS2 is stuck with 7.3 for 32 bits. Why doesn't it build? Because of PR ada/81878? -- Eric Botcazou
Re: testsuite result updates for x86_64-w64-mingw32
> There are new testsuite results for x86_64-w64-mingw32, for versions > 6.4.1, 7.3.1, 8.2.1 and 9.0.0. > > https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02309.html > https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02310.html > https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02312.html So we have an additional ACATS failure (ce2104c) in 8.2.1 over the previous releases? Feel free to open a PR about it if you have a couple of minutes. Thanks for testing the Ada compiler! -- Eric Botcazou
Re: movmem pattern and missed alignment
> It was repeatedly suggested that we _could_ derive alignment info from > function parameter types since we rely on precise typing there for example > for points-to analysis (albeit only for restrict qualification processing > and for DECL_BY_REFERENCE "pointers"). That would fix the simple testcase > that was presented here. OK, I keep forgetting it and that would be a good compromise indeed. -- Eric Botcazou
Re: movmem pattern and missed alignment
> It's not quite obvious what SSE has to do with this - any hint please? SSE introduced alignment constraints into the non-strict-alignment target x86 so people didn't really want to play by the rules of strict-alignment targets. > (according to my quick check this changed between gcc-4.5 and gcc-4.6) Possibly indeed, I remembered GCC 4.5 as being the turning point. -- Eric Botcazou
Re: movmem pattern and missed alignment
> That's correct, I was explaining from the middle-end perspective. There > we are consciously more lenient as we have to support the real world and > other languages than C. This is one of the cases. This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK for every language on strict-alignment platforms. This was changed only because of SSE on x86. -- Eric Botcazou
Re: Inefficient code
> Xstormy does 3 mov.b also. For that matter, so does the x86 target (both > -m32 and -m64). Hm. Indeed, even at -Os, so this may be a generic issue. -- Eric Botcazou
Re: Inefficient code
> So back to the previous one: anything I can do about a 24 bit field getting > split into three movqi rather than a movqi plus a movhi? That happens > during RTL expand, I believe. Yes, this one doesn't look as hopeless as the store merging issue. A way of tackling it would be to do a side-by-side debugging of a compiler built for a similar target for which only 2 stores are generated. -- Eric Botcazou
Re: Inefficient code
> I just constructed another test case that shows the same issue more
> blatantly:
>
> struct s
> {
> char a;
> char b;
> char c;
> char d;
> int e;
> int f;
> char h;
> char i;
> };
No, it's not the same issue.
> struct s ts;
>
> void setts(void)
> {
> ts.a=2;
> ts.b=4;
> ts.c=1;
> ts.d=24;
> ts.e=5;
> ts.f=42;
> ts.h=9;
> ts.i=3;
> }
>
> Each of the fields are written separately, even though clearly the adjacent
> byte writes can and should be combined into a single HImode move. This
> happens both with -O2 and -Os.
The GIMPLE pass responsible for the optimization simply punts for the "funny-
endian ordering" of the PDP11. More generally, you shouldn't expect anything
sparkling for such a peculiar architecture as the PDP11.
--
Eric Botcazou
Re: ChangeLog's: do we have to?
> They are definitely useful in my day-to-day work when tracking down changes > given I can easily grep them. Seconded. > I think that any change here should be _after_ we've switched to git > (finally). Well, git doesn't make anything easier than subversion in this area so... -- Eric Botcazou
Re: Sched1 stability issue
> We noticed a difference in the code generated for aarch64 gcc 7.2 > hosted in Linux vs mingw. AFIK, we are supposed to produce the same > output. Try maybe to compare the automata generated on the hosts, are they identical? -- Eric Botcazou
Re: RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'
> It seems the a-except.adb was replaced by a-except-2005.adb in this commit: Right, it's by design, the old support for SJLJ exceptions has been ditched for full runtimes. You probably just need to swap the values of Frontend_Exceptions : constant Boolean := True; ZCX_By_Default: constant Boolean := False; in system-rtems.ads. -- Eric Botcazou
Re: RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'
> I cannot find it in the GCC sources:
>
> grep -ri raise_nodefer_with_msg
> gcc/ada/gcc-interface/trans.c: (get_identifier
> ("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
>
> Who is supposed to provide an implementation of
> __gnat_raise_nodefer_with_msg?
No one, it's obsolete. The port is very likely not (properly) configured.
--
Eric Botcazou
Re: Finding virtual address of functions in code
> Is there any builtin function in C which prints the virtual address of > functions including the main? I see __builtin_return_address() but that > returns the “return address”. This list is not appropriate for such a question, use gcc-help@ instead. -- Eric Botcazou
Re: GCC 8 Ada bootstrap failure on mingw-w64
> Hmm there would be a huge amount of code to check. Compare the *build* with a known working version, not the code. > BTW it is quite strange that both stage2 and stage3 didn't fail and the > comparison was successful. It's not the compiler build, it's the gnattools build (gnatdll to be precise). -- Eric Botcazou
Re: GCC 8 Ada bootstrap failure on mingw-w64
> Any ideas about how to resolve this? Compare with a known working version (e.g. GCC 7) and find the discrepancy. -- Eric Botcazou
Re: Project Ranger
> First, we'll collect the cases that demonstrate a unique situation we > care about. I have 4 very specific case that show current > shortcomings.. Not just with the Ranger, but a couple we don't handle > with VRP today. .. I'll eventually get those put onto the wiki so the > list can be updated. I'm not specifically worried here, there is already a couple of testcases in the testsuite that require symbolic information to be properly optimized. > I think most of these cases that care about symbolics are not so much > range related, but rather an algorithmic layer on top. Any follow on > optimization to either enhance or replace vrp or anything similar will > simply use the ranger as a client. If it turns out there are cases > where we *have* to remember the end point of a range as a symbolic, then > the algorithm to track that symbolic along with the range, and request a > re-evaluation of the range when the value of that symbolic is changes. > > [...] > > Does that help? If it does, I'll add this to the coverage in the wiki > page. Yes, thanks for the detailed explanation. This approach of setting aside the handling of symbolic information might end up being a good compromise between the necessary minimal[*] handling of this information and the complexity of doing it directly in the Ranger. [*] The implicit assumption hee is that a VRP implementation with full-blown support of symbolic ranges is not worth the hassle in practice. -- Eric Botcazou
Re: Project Ranger
> The Ranger is far enough along now that we have confidence in both its > approach and ability to perform, and would like to solicit feedback on > what you think of it, any questions, possible uses, as well as > potential requirements to integrate with trunk later this stage. The PDF document mentions that you first intended to support symbolic ranges but eventually dropped them as "too complex, and ultimately not necessary". I don't entirely disagree with the former part, but I'm curious about the latter part: how do you intent to deal in the long term with cases that do require symbolic information to optimize things? The TODO page seems to acknowledge the loophole but only mentions a plan to deal with equivalences, which is not sufficient in the general case (as acknowledged too on the page). -- Eric Botcazou
Re: virtual-stack-vars reference not resolved in vregs
> Is this something the back end is responsible for getting right, for example > via the machine description file? If so, any hints where to start? The SUBREG of MEM is invalid at this stage. -- Eric Botcazou
Re: Must TYPE_MODE of a UNION_TYPE be of MODE_INT class?
> See stor-layout.c (compute_record_mode), particularly this section: > >/* If we only have one real field; use its mode if that mode's size > matches the type's size. This only applies to RECORD_TYPE. This > does not apply to unions. */ >if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode >&& tree_fits_uhwi_p (TYPE_SIZE (type)) >&& known_eq (GET_MODE_BITSIZE (mode), tree_to_uhwi (TYPE_SIZE >(type >; >else > mode = mode_for_size_tree (TYPE_SIZE (type), MODE_INT, 1).else_blk (); > > Is there a reason the type of the union must be of MODE_INT class but a > RECORD_TYPE with one field can have the class of it's single field? Yes, ABIs that pass structures or unions in registers traditionally pass the unions always in integer registers, whereas for structures it's dependent on the types of the fields. > Could anyone provide some insight on whether the TYPE_MODE of a union should > stay as a MODE_INT class or if it would be acceptable for the TYPE_MODE to > be other classes e.g. MODE_FLOAT? No, I don't think we want to change that. -- Eric Botcazou
Re: Selective scheduling and its usage
> Are you suggesting we should not care about regressions with features > that are not enabled by default or which are only exposed with > "non-standard" flags? The current scheme on which bugs get P1/P2/P4+ > assigned is quite simple... I'm only suggesting keeping them at P3, which is not "don't care" as far as I know but just the default priority. The criterion could be a flag that is not part of any -Ox switches and not enabled on any primary+secondary platforms. -- Eric Botcazou
Re: Selective scheduling and its usage
> I noticed there are quite many selective scheduling PRs: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659 > > and many others. Right, and some of them are P1/P2, which doesn't really make sense IMO. -- Eric Botcazou
Re: Why does IRA force all pseudos live across a setjmp call to be spilled?
> Maybe we should have a target hook that says setjmp/longjmp are > implemented by simple function calls (or as-if by function calls), so > as not to penalize everyone who has an, erm, more conservative ABI? Yes, that sounds a sensible compromise to me. -- Eric Botcazou
Re: Why does IRA force all pseudos live across a setjmp call to be spilled?
> Apparently the authors of the SPARC psABI thought that the last part of your > sentence is an interpolation and that the (historical) requirements were > vague enough to allow their interpretation, IOW that the compiler can do > the work. And, as PR target/83368 showed, both the GNU and the Solaris libc make use of the leeway given by the psABI for setjmp at least in some cases. -- Eric Botcazou
Re: Why does IRA force all pseudos live across a setjmp call to be spilled?
> C11 says in 7.13.2.1/2 > "The longjmp function restores the environment saved by the most recent > invocation of the setjmp macro in the same invocation of the program with > the corresponding jmp_buf argument." > where "environment" is not really defined, but it includes all information > a program will need to return to its caller (so it has to restore the > non-volatile registers, set stack pointers correctly, that kind of thing). Apparently the authors of the SPARC psABI thought that the last part of your sentence is an interpolation and that the (historical) requirements were vague enough to allow their interpretation, IOW that the compiler can do the work. -- Eric Botcazou
Re: Why does IRA force all pseudos live across a setjmp call to be spilled?
> I can't argue with anything in that comment, other than the conclusion. :-) > It's not the compiler's job to implement the setjmp/longjmp save/restore. > Maybe Kenny was working around a problem with some target's buggy setjmp > and spilling everything "fixed" it? What are the requirements imposed on setjmp exactly and by whom? The psABI on SPARC (the SCD) has an explicit note saying that setjmp/sigsetjmp/vfork don't (have to) preserve the usual non-volatile registers. -- Eric Botcazou
Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
> Indeed, this solves most of the new failures. Here is the acats test > summary: > === acats Summary === > # of expected passes 2298 > # of unexpected failures 22 > *** FAILURES: c23003b c23003g c23003i c250002 c380004 cd2b11a cd2b15c > ce2102l ce2102m ce2103a ce2103b ce3102d ce3107a ce3115a cxa4005 cxa4008 > cxa4016 cxa4019 cxac003 cxb3012 cxf3a01 cxf3a02 > /opt/devel/gnu/src/gcc-mingw-w64/gcc-8.0.0/gcc/testsuite/ada/acats/run_all.s > h completed at Wed Feb 7 12:28:36 CET 2018 Please open a PR for the ACATS regressions on mainline. -- Eric Botcazou
Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
> Sorry for the stupid question. How do I pass this to the testsuite? For ACATS it's a little awkward: you manually need to add it to the gccflags variable in gcc/testsuite/ada/acats/run_all.sh -- Eric Botcazou
Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
> Here's a short status report for trunk on x86_64-w64-mingw32 host. > > I know this is only a secondary platform, but there are some serius issues. > > Especially the ada part is in a bad shape compared to 7.3.0, see > https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html > and > https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00308.html > > At least 20 of the acats tests catch all memory until the host memory is > exhausted. Same holds for the two libstdc++ tests > 23_containers/unordered_set/requirements/exception/basic.cc > and > 23_containers/unordered_set/requirements/exception/propagation_consistent.cc Does passing -fno-reorder-blocks-and-partition change anything? -- Eric Botcazou
Re: [gcc plugin] get member offset in struct just like offsetof
> I am writing a gcc plugin for parsing the structure fields. But I have the > problem how to get the offset of each field in the struct? Just like the > offsetof macro in gcc. > > I see DECL_FIELD_OFFSET in tree.h, but the result seems not right. The offset in bits/bytes is given by tree.c:bit_position/byte_position. -- Eric Botcazou
Re: Status of m32c target?
> It's a bit like writing a new backend, except you have all this existing > code to worry about as well. Unless you start from scratch (which may > not be such a bad idea: you get to modernise it all, and it isn't _really_ > from scratch, you can peek at the old code and copy stuff from it). I disagree, it's nowhere near the difficulty of writing a new back-end, it's only a conversion from one representation to another and one could say that only "tactical" decisions are to be made, as opposed to more "strategical" decisions for a new back-end. And IMO starting from scratch is a bad idea. > But writing a backend is too much for a GSoC, even a small one. Definitely, and doing a CC0 conversion is probably an upper bound. -- Eric Botcazou
Re: Status of m32c target?
> Yes, I know that CCmode can represent condition code. But just the fact > that it can represent it doesn't make it superior or cc0 inferior or > bad. Having different representations for the same thing has also its > obvious upsides (think of different representations in maths or > physics), and in the present case one has the choice between an explicit > RTL representation and an implicit (w.r.t. to RTL) one. Different representations in maths are interesting only if you can easily go back and forth between them, so I don't think the analogy is valid here. > - cc0 does a good job and did always a good job in the past. In the > years I contributed to avr, there hasn't been a single cc0 flaw (all the > few, minor cc0-related issues were avr BE issues). cc0 does inhibit RTL optimizations because of the implementation constraints it imposes, most notably the non-separation of CC setters and users. > - No improvements of generated code are expected. avr won't benefit > from separating comparisons from branches (no scheduling). See above. Moreover, it is easy to implement a minimal form of scheduling to hide the latency of the loads (assuming some AVR processors are pipelined), in which case CCmode will give you a performance bonus. -- Eric Botcazou
Re: Build Ada compiler for nios2?
> This HOST_WIDE_INT is defined in gcc/hwint.h. Who is supposed to include > this file? Is this done via an #include or via a tm_file (gcc/config.gcc)? Nobody I'd say, the declaration shouldn't be compiled for the target. -- Eric Botcazou
Re: Dropping ChangeLogs
> ChangeLogs are a relic from the days before version-control systems with > real changesets. When you have real changesets, all ChangeLogs do is > add unnecessary process friction. ChangeLogs make it possible to quickly pinpoint unintentional changes going in the commits. Maybe git has specific counter-measures against them, but that's useful at least with Subversion. -- Eric Botcazou
Re: Byte swapping support
> handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it > will not issue a warning for C++ even though the pragma is effectively > ignored. Indeed, unlike for the attribute, will fix, thanks. -- Eric Botcazou
Re: Byte swapping support
> By the way, what happened to the C++ bits? I think the c-family patch > which went in assumes that the C++ bits are there as well. I don't really understand what you mean by "assume" here, but the C++ bits were incomplete and never got reviewed; I can resurrect them if there is some interest though. -- Eric Botcazou
Re: Byte swapping support
> I seem to remember it being able to attach a big-endian or little-endian > label to any individual variable (rather than a type), which could be a > scaler rather than a struct. So it was a bit more flexible than gcc. Well, the only thing I see in the documentation for "Byte Ordering" is the reference to pragma Pack and the __packed__ keyword for structures, which can toggle byte ordering by means of the byte-swap argument: "#pragma pack [ ([[max_member_alignment] , [min_structure_alignment][, byte-swap ]] ) ] The pack directive specifies that all subsequent structures..." with the same limitation as GCC about taking the address: "It is not possible to take the address of a byte-swapped member." -- Eric Botcazou
Re: Byte swapping support
> And there are lots of other problems, I don't have time to document them > all, or even remember them all. Personally, I think you are better off > trying to fix the application to make it more portable. Fixing the > compiler is not a magic solution to the problem that is any easier than > fixing the application. Note that WRS' Diab compiler has got something equivalent to what GCC has got now, i.e. a way to tag a particular component in a structure as BE or LE. -- Eric Botcazou
Re: Byte swapping support
> Was this considered significantly more complex because of the need to > discriminate between native and reverse order? Or do you expect similar > complexity even if this is not required (see my comment below)? The former. > I don't. The idea is to reverse scalar storage order for the whole > userspace process and then add byte swapping to the Linux kernel when > accessing userspace memory. This keeps userspace memory consistent > with regards to endianness, which should lead to high compatibility > with big-endian applications. Userspace memory access from the kernel > always uses a small set of helper functions, which should make it > easier to insert byte swapping at appropriate places. Well, if your userspace is entirely in reverse order, then of course things are totally different and I suspect that you'll pay the price in term of run time performance. This is not what the attribute was designed for, although we added the -fsso-struct switch at some point. -- Eric Botcazou
Re: Byte swapping support
> To support applications that assume big-endian memory layout on little- > endian systems, I'm considering adding support for reversing the > storage order to GCC. That was also the goal of the scalar_storage_order attribute. > In contrast to the existing scalar storage order support for structs, the > goal is to reverse the storage order for all memory operations to achieve > maximum compatibility with the behavior on big-endian systems, as far as > observable by the application. I presume that you'll well aware of this, but you cannot just reverse the storage order for any memory operation; for example, an array of 4 chars in C is stored the same way in big-endian and little-endian order, so you ought not to do byte swapping when you access it as a whole. So the above sentence must be read as "to reverse the storage order for all scalar memory operations". When the scalar_storage_order attribute was designed, discussions lead to the conclusion that doing the swapping for any scalar memory operation, as opposed to any access to a scalar within a structure, would not be a significant step forward to warrant the significantly more complex implementation (or the big performance penalty if you do things very roughly). > The plan is to insert byte swapping instructions as part of the RTL > expansion of GIMPLE assignments that access memory. This would leverage > code that was added for -fsso-struct, keeping the code simple and > maintainable. How do you discriminate scalars stored in native order and scalars stored in reverse order though? That's the main difficulty of the implementation. -- Eric Botcazou
Re: Overwhelmed by GCC frustration
> Just the fact that the backends that get most attention and attract > most developers don't use cc0 doesn't mean cc0 is a useless device. Everything that can be done with cc0 can be done with the new representation, at least theoritically, although this can require more work. > As far as cc0 is concerned, transforming avr BE is not trivial. > It would need rewriting almost all of its md files entirely. > It would need rewriting great deal of avr.c that handle > insn output and provide input to NOTICE_UPDATE_CC. I recently converted the Visium port, which is an architecture where every integer instruction, including a simple move, clobber the flags, so it's doable even for such an annoying target (but Visium is otherwise regular). See for example https://gcc.gnu.org/wiki/CC0Transition for some guidelines. > But my feeling is that opposing deprecation of cc0 is futile, > the voices that support cc0 deprecation are more and usefulness > of cc0 is not recognized. cc0 is just obsolete and inferior compared to the new representation. -- Eric Botcazou
Re: Volatile Memory accesses in Branch Delay Slots
> The function responsible for this behavior seems to be > resource_conflicts_p in reorg.c. Sadly, I could not find any comments > explaining why volatile accesses cannot be put into delay slots. > > What is the reason for this behavior? I am unable to think of any > situation where allowing volatile memory accesses in branch delay slots > leads to problems. Am I missing a case? Or are negative effects limited > to other architectures? Delay slot filling is a code movement optimization and such optimizations are not valid for volatile memory accesses in the general case. -- Eric Botcazou
Re: timeouts/malloc failures in ada tests?
> I see large numbers of timeouts in Ada tests on trunk in parallel > run s (make -j96) on x86_64. Messages like the one below appear > in the logs, suggesting some sort of heap corruption. I'm having > trouble reproducing it outside the rest of the test suite (i.e., > by just running the Ada tests by themselves) but maybe I'm doing > it wrong. Unless this is a known problem I can try to pinpoint > it closer if someone could share the magic spell to run just Ada > tests to speed up the debugging. > > Is it (a known problem)? No, but regressions were recently introduced in the ACATS testsuite: === acats tests === FAIL: cb4008a FAIL: cb41001 so this could be related. Ada is not enabled by default so this is not surprising. It's OK for small changes and bug fixes, but people making extensive changes to the compiler should really consider enabling it (and it's a very good testbed). -- Eric Botcazou
Re: GCC 6.4 Release Candidate available from gcc.gnu.org
> OK to re-apply then on the branch(es) if it fixes the bootstrap issue. I was wrong, it's PR sanitizer/78532 + PR sanitizer/78992 instead... 2016-11-30 Maxim Ostapenko PR sanitizer/78532 * sanitizer_common/sanitizer_platform_limits_posix.h (__sanitizer_sigaction): Adjust for sparc targets and various Glibc versions. 2017-01-10 James Clarke PR sanitizer/78992 * sanitizer_common/sanitizer_platform_limits_posix.h (struct __sanitizer_sigaction): Cherry-pick upstream r291561. Backported onto the branch after testing on SPARC64/Linux. -- Eric Botcazou
Re: GCC 6.4 Release Candidate available from gcc.gnu.org
> Iff 6.3.0 worked then it must be caused by > > r245546 | andreast | 2017-02-17 20:21:39 +0100 (Fri, 17 Feb 2017) | 9 > lines > > 2017-02-17 Andreas Tobler > > Backported from mainline > 2017-02-16 Andreas Tobler > > PR sanitizer/79562 > * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick > upstream r294806. > > > this was also pushed to the GCC 5 branch. Yes, it's again PR sanitizer/63958 I guess. -- Eric Botcazou
Re: Read-only *.ali files in adalib installation?
> I built an Ada cross-compiler and noticed that all the *.ali files in > adalib are read-only, e.g. > > ll /opt/rtems-4.12/lib64/gcc/powerpc-rtems4.12/7.1.1/adalib/ > > [...] > > -r--r--r-- 1 sebastian_h domain users 5210 Jun 12 14:06 i-fortra.ali > -r--r--r-- 1 sebastian_h domain users 2769 Jun 12 14:06 interfac.ali > -r--r--r-- 1 sebastian_h domain users 805 Jun 12 14:06 ioexcept.ali > -r--r--r-- 1 sebastian_h domain users 4179 Jun 12 14:06 i-pacdec.ali > -rw-r--r-- 1 sebastian_h domain users 1450556 Jun 12 14:30 libgnarl.a > -rw-r--r-- 1 sebastian_h domain users 16076716 Jun 12 14:30 libgnat.a > > [...] > > This is unlike the lib*.a files, which are user writeable. Its this > intentional? Yes for the ALI files, but no for the libraries (it doesn't matter for them). -- Eric Botcazou
Re: try_finally_expr wrong source location info
> But then, after lowering on the eh pass (gcc/tree-eh.c:1161), the "finally" > location is set up to the `gimple_location (tf->try_finally_expr)' which > actually expands to "testcase.cxx:4", a place where the "try" block starts. > > The dump testcase.cxx.009t.ehopt shows no location info for destructor: > std::unique_ptr::~unique_ptr (&lang); > > And next testcase.cxx.010t.eh dump shows equal location for constructor and > destructor: > [testcase.cxx:4:38] std::unique_ptr::unique_ptr ([testcase.cxx:4:38] > &lang, D.42272); [testcase.cxx:4:38] std::unique_ptr::~unique_ptr > (&lang); > > I performed several experiments trying to get information about gimple_block > around the try_finally_expr statement right in `lower_try_finally_onedest', > but unsuccessfully. And also, as far as I understand, this issue should be > fixed in all the lowering functions, not only this one. > > Where should I dig in order to fix the issue? We have been using this patchlet locally for some time: Index: tree-eh.c === --- tree-eh.c (revision 248944) +++ tree-eh.c (working copy) @@ -1413,11 +1413,12 @@ lower_try_finally_switch (struct leh_sta x = gimple_build_assign (finally_tmp, build_int_cst (integer_type_node, fallthru_index)); + gimple_set_location (x, finally_loc); gimple_seq_add_stmt (&tf->top_p_seq, x); tmp = build_int_cst (integer_type_node, fallthru_index); last_case = build_case_label (tmp, NULL, - create_artificial_label (tf_loc)); + create_artificial_label (finally_loc)); case_label_vec.quick_push (last_case); last_case_index++; @@ -1426,7 +1427,7 @@ lower_try_finally_switch (struct leh_sta tmp = lower_try_finally_fallthru_label (tf); x = gimple_build_goto (tmp); - gimple_set_location (x, tf_loc); + gimple_set_location (x, finally_loc); gimple_seq_add_stmt (&switch_body, x); } -- Eric Botcazou
