etting 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
> Any ideas about how to resolve this?
Compare with a known working version (e.g. GCC 7) and find the discrepancy.
--
Eric Botcazou
ols build (gnatdll to be precise).
--
Eric Botcazou
> 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
r_with_msg?
No one, it's obsolete. The port is very likely not (properly) configured.
--
Eric Botcazou
_Default: constant Boolean := False;
in system-rtems.ads.
--
Eric Botcazou
> 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
> 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 thi
n 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
o do a side-by-side debugging of a compiler built for a
similar target for which only 2 stores are generated.
--
Eric Botcazou
> 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
> Can you point me at least to the section which explains this?
http://gcc.gnu.org/install/build.html
--
Eric Botcazou
> + i386 Ada ICE (regression) - http://gcc.gnu.org/PR47481
I'll look into this one...
> + mips Ada -G0 - http://gcc.gnu.org/PR47500
...but a MIPS maintainer needs to take a preliminary look at this one.
--
Eric Botcazou
so they disable their
manipulation altogether to avoid generating wrong code.
--
Eric Botcazou
> I figured if I knew what was needed before opening the bug it would cut
> down on the need-info requests. Thanks.
The instructions are available on the http://gcc.gnu.org/bugs/ page.
--
Eric Botcazou
ave the same, in particular when they are on the LHS of an assignment.
--
Eric Botcazou
> What does "word" mean here? Is it a 32-bit entity or is it according to
> word_mode which is QImode for avr?
The latter, it is machine-dependent.
> So the same should be true for QI-subregs of scalar modes if
> UNITS_PER_WORT = 1. Right?
Right.
--
Eric Botcazou
y_operand), but I freely admit
> this is a part of the compiler that I'm not familiar with.
SPARC had exactly the same pattern as the 'U' constraint of MMIX. It now uses
reload_in_progress || reload_completed instead (in memory_ok_for_ldd).
--
Eric Botcazou
long?
Probably because you're also fiddling with configure checking options. Avoid
doing that if you aren't familiar with them.
--
Eric Botcazou
his weekends/holidays allowance would be dangerous and counter-productive:
people would rush to install risky changes on Friday and leave for the
week-end fingers crossed. This would be worse than the current policy IMO.
--
Eric Botcazou
e key
> "--disable-checking" configury bits that we were able to confirm a
> problem and start the real process of diagnosing what went wrong.
No, this isn't what happened, see the audit trail of PR48403. This was a big
breakage. --disable-checking had nothing to do with the problem either.
--
Eric Botcazou
_type condition. Would
that work for other languages as well, in particular C++?
--
Eric Botcazou
> LTO bootstrap has been broken for more than a month:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48148
I'm about to submit a fix for the .Ldebug_info0 failure.
--
Eric Botcazou
> I was LTO bootstrapping yesterday just fine. You're talking about
> bootstrap-profiled.
Not clear at all, a regular LTO bootstrap had failed on cc1 for days here.
--
Eric Botcazou
> Hmpf. Strange. I've bootstrapped with all languages except Ada
> yesterday, with gold as plugin-ld.
GNU ld (with plugins) for me, but --enable-checking=yes,rtl. Maybe H.J. had
e.g. --enable-checking=release. In any case, something is brittle ATM.
--
Eric Botcazou
the pass doesn't consume REG_DEAD/REG_UNUSED notes, it doesn't have to keep
them up-to-date. Instead, passes that consume them must df_note_add_problem()
on entry. For the generic reorg (delay slot filling) pass, this is done in
rest_of_pass_free_cfg.
--
Eric Botcazou
e the CFG has been destroyed so it
very likely needs to use a trick akin to that of the generic reorg pass in
rest_of_pass_free_cfg.
--
Eric Botcazou
> rest_of_pass_free_cfg calls df_analyze but it doesn't call
> df_note_add_problem. Is that the issue? I see that some other passes
> (like regrename) do a sequence of df_xyz calls.
It does now, you have outdated sources.
--
Eric Botcazou
middle-end expects word-mode subregs
of double-word-mode hard regs to be simplifiable.
--
Eric Botcazou
2 %f40) 4) isn't simplifiable either. H.P. wrote a
tentative patch for the subreg machinery to forbid this. Other references are:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01688.html
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01743.html
--
Eric Botcazou
could be applied immediately. The
patches from mainline it is made up of are listed at the end of the message.
Can I proceed with the backport?
2011-06-10 Eric Botcazou
Laurent Rougé
* doc/invoke.texi (SPARC options): Add -mflat.
* config/sparc/sparc.opt: Lik
> Apart from
>
> 2011-06-02 Eric Botcazou
>
>* cse.c (cse_find_path): Refine change to exclude EDGE_ABNORMAL_CALL
>edges only, when there is a non-local label in the function.
>* postreload-gcse.c (bb_has_well_behaved_predecessors): Likewise.
&
or mainline. You get the real testing when you
release and I think that the .1 release would have been appropriate. I'm not
so sure for the .2 release, as this would mean waiting for 4.6.3 to fix the
probable fallouts for the SPARC port. I guess we'd better drop the idea then.
--
Eric Botcazou
wasting
CPU cycles. ;-)
--
Eric Botcazou
think CPU cycles
> wouldn't be wasted by preparing a fix for 4.6.2).
I think it is as obviously safe as a reorg.c patch can be so I'm going to test
it (on the branch) and post it afterward, but it will be your call of course.
--
Eric Botcazou
> The immediate blocker to using C++ in gcc is the Ada frontend.
> --enable-build-with-cxx and --enable-languages=ada do not work together.
Could you elaborate?
--
Eric Botcazou
g++ instead of
gcc to link) are needed and extern "C" must be added all over the place, see:
http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html
I can post an updated patch if you want, but saying that the Ada front-end
blocks the use of C++ in gcc is unfair; it is (and has always be
11-07/msg00845.html
> I have a patch ready to go which would use C++ in stages 2 and 3. I
> can't propose that patch right now because it fails when building Ada.
> If we get Ada fixed, I will propose it.
OK, let's fix --enable-build-with-cxx with Ada. Thanks for clarifying.
--
Eric Botcazou
atch, thanks, will fix.
--
Eric Botcazou
COMPILER = $(CC)
> COMPILER_FLAGS = $(CFLAGS)
> LINKER = $(CC)
> LINKER_FLAGS = $(CFLAGS)
> else
> COMPILER = $(CXX)
> COMPILER_FLAGS = $(CXXFLAGS)
> LINKER = $(CXX)
> LINKER_FLAGS = $(CXXFLAGS)
> endif
I'm not sure because I don't think we want to compile the C files of the Ada
runtime with the C++ compiler. We want to do that only for the compiler.
--
Eric Botcazou
ern "C" blocks, I'm
going to clean it up.
--
Eric Botcazou
preferrable.
But your patch isn't necessary to do that, the C files are already compiled
with the C++ compiler as of today; the only issue is at the linking stage.
--
Eric Botcazou
> The problem is that the patches links gnattools unconditionally with
> g++. It should depend on --enable-build-with-cxx instead.
Yes, that part was wrong, it will be dropped, we don't want to use g++ here.
--
Eric Botcazou
I of the target.
Only after Fortran does the same. :-)
--
Eric Botcazou
that your suggestion is the way to go and I made the same when we were
fiddling with boolean_type_node in free_lang_data:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00966.html
So fine with me, as long as all the languages play by the same rules.
--
Eric Botcazou
alling cleanup_tree_cfg()
> after my transformation pass, still no luck
Try invoking rebuild_cgraph_edges.
--
Eric Botcazou
> I have measured it at some point and IIRC it was about 10% slower
> (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap,
> not sure if that included bootstrapping libstdc++ for the former).
IMO acceptable now that the build time of libjava has been halved.
--
Eric Botcazou
see name-lookup.c:get_anonymous_namespace_name.
--
Eric Botcazou
> Realistically, how many unique libraries are used for all of the GCC
> targets? I would think that it has to be some low, finite number.
There is at least one per OS (Linux, Solaris, HP-UX, IRIX, Tru64, *BSD, VMS,
Windows, etc) plus variants depending on the version of the OS.
--
s platform with the right
libraries and GCC as base compiler.
--
Eric Botcazou
area. You'd need to upgrade to
4.5.3 at least (or use the SVN 4.5 branch). That being said, targets with
multiple delay slots are indeed relatively untested.
--
Eric Botcazou
h
more in the V9 manual. Quoting it:
"The order of memory operations observed at a single location is a total order
that preserves the partial orderings of each processor’s transactions to this
address. There may be many legal total orders for a given program’s execution"
--
Eric Botcazou
> I'm porting a 64-bit target gcc on a 32-bit i386 host. I have set
> need_64bit_hwint to yes in config.gcc. But it fails when building
> libgcc.
You need to do the same in libcpp/configure.ac with recent versions.
--
Eric Botcazou
get rid of them in any case I'd think.
--
Eric Botcazou
get rid of them in any case I'd think.
--
Eric Botcazou
m beginning to think the whole of a-exexpr-gcc needs to be extracted
> into 2 distinct files, a-exexpr-gcc (normal GCC EH - as it is) and
> a-exexpr-gcc-arm (ARM EABI EH).
Probably some parts of it, yes.
--
Eric Botcazou
ration.
> Is the scenario above intended behavior of the combine pass or an
> accident? Or maybe even something else wrong in the machine description
> that makes it behave like that?
See how the i386 back-end copes with this for its "test" instruction.
--
Eric Botcazou
real_insn depends on -g? And that I have to write my
> own next really_real_insn?
Try prev_active_insn/next_active_insn.
--
Eric Botcazou
The test fails with a link error, as 'round' and 'rint' are only C99.
Fixed thusly, tested on SPARC/Solaris 8, applied on the mainline as obvious.
2011-10-13 Eric Botcazou
* gcc.dg/builtins-67.c: Guard iround and irint with HAVE_C99_RUNTIME.
--
Eric Bo
other
classes) shouldn't depend on the mode but only on the type.
--
Eric Botcazou
> Right and as Richard said I can munge the modes during expansion of
> existing builtins when needed.
OK, but you precisely shouldn't need to do it since the type is fixed.
--
Eric Botcazou
erstand
> how introducing .loc directive affects debug_line format in gcc 4.6.1.
.loc directives are processed by the assembler, which then builds .debug_line.
--
Eric Botcazou
> I would like to implement a compiler fix for a SPARC-cpu variant
> that does the following:
> After each "fdivs" (SPARC single-float division) save the destination
> FPU register to a stack memory location.
Do you need to reload it afterward or just save it?
--
Eric Botcazou
> I just need to save it. It needs to be saved so that the FPU
> pipeline is flushed.
Then why not save it just below the stack pointer?
--
Eric Botcazou
it.
> Did I miss something here ?
This usually means that the libiconv installation is botched, e.g. the compiler
sees a mix of GNU libiconv and Solaris libiconv, or something like that.
--
Eric Botcazou
ot; on sparc.
AFAICS there is no such file as gcc.c-torture/execute/ieee/mzero.c.
> I'm suspecting that perhaps cprop is ok, and the real issue is that
> sparc's definition of CANNOT_CHANGE_MODE_CLASS needs to be adjusted.
I'm a little skeptical at this point.
--
Eric Botcazou
BIG_ENDIAN : BYTES_BIG_ENDIAN))
return;
i.e. we need to bail out if we are narrowing and this is a big-endian target.
--
Eric Botcazou
> I quickly tried the patch below, but this does not prevent the
> transformation.
The quoted code is in copyprop_hardreg_forward_1.
--
Eric Botcazou
3, 0x3c, 1), F3(~3, ~0x3c, ~1), "[1]o,2,d", 0, v9|MASK_LEON
},
v9|leon
+{ "cas", F3(3, 0x3c, 0)|ASI(0x80), F3(~3, ~0x3c, ~0)|ASI(~0x80),
"[1],2,d",
F_ALIAS, v9|MASK_LEON }, /* casa [rs1]ASI_P,rs2,rd */
+{ "casl", F3(3, 0x3c, 0)|ASI(0x88), F3(~3, ~0x3c, ~0)|ASI(~0x88),
"[1],2,d",
F_ALIAS, v9|MASK_LEON }, /* casa [rs1]ASI_P_L,rs2,rd */
Likewise.
--
Eric Botcazou
sg03536.html
> Also, I see bucket loads of these :
>
> FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error)
PCH seems to be totally broken. AFAIK nothing has changed between 4.6.1 and
4.6.2 in this area. Can you try with 4.6.1? Did you change the machines?
--
Eric Botcazou
gnu.org/ml/gcc-patches/2011-05/msg02334.html
Where did config/t-crtin go? Alternatively, why not just add the missing rules
to config/t-rtems?
--
Eric Botcazou
rules are generic and have been integrated into libgcc/Makefile.in,
> but only used unless CUSTOM_CRTIN is set in a target fragment.
s/unless/if/ I presume? config/t-sol2 has the rules though so config/t-rtems
could just copy them, at least for now.
--
Eric Botcazou
> Again, can you please hit reload on your browser?
I have it too.
--
Eric Botcazou
can hardly be analyzed, there are too many failures, although they
probably come from a small number of problems. You should consider looking
into the gazillions of execution failures, determining why they fail (they pass
on Solaris or Linux) and submit patches to XFAIL/SKIP them for sparc-rtems.
--
Eric Botcazou
> Huh, IVOPTs should never cause a different size memory read. I wonder
> if the original issue would still reproduce with the fix reverted.
The original issue was unaligned arrays in packed structures. I don't see what
could have changed since then.
--
Eric Botcazou
> f() may change the value of x, so you cannot optimize away the load on that
> execution path.
This looks more like an aliasing issue with a, doesn't it?
--
Eric Botcazou
eds to have
# the gcc source dir in its include dir list
INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. -iquote
$(fsrcdir)/ada \
-I$(fsrcdir)/../include -I$(fsrcdir)
endif
It's probably only a matter of adjusting the regexp.
--
Eric Botcazou
> I haven't tried it yet but the 'cygwin32' looks suspicsious to me,
> i.e., the 32, to my understanding that '32' was removed years ago..
We should probably use the Windows-specific setting unconditionally.
--
Eric Botcazou
s-include
> -c -g -O2 -W -Wall -gnatpg -nostdinc s-taprop.adb -o s-taprop.o
> s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)
> make[5]: *** [s-taprop.o] Error 1
> make[5]: Leaving directory
Looks like the same problem, see gcc/ada/Makefile.in line 1573.
--
Eric Botcazou
here is something odd when cygwin is to
> use, I guess, mingw variants of files...
But grep is your friend. See s-oscons-tmplt.c lines 1343 and below.
--
Eric Botcazou
> phew, beyond my abilities yet again. someone more cygwin knowledgable
> would need to look into that I suppose...
Try adding defined (__CYGWIN__) to the first line.
--
Eric Botcazou
ADDR_SPACE_GENERIC and
> addr_space_t on the other side. I mean on the conceptual level, not on the
> technical (macro/function/typedef) level.
c_addr_space_name is C-specific whereas the others are generic.
--
Eric Botcazou
> Today I ran into a problem building today's GCC trunk with an older
> GCC 4.3. There is a warning in libcpp/macro.c about
> tokens_buff_remove_last_token declared inline after being called.
A previous instance: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01426.html
--
Eric Botcazou
R_P
in the process, if the answer to the above question is positive), there is no
point in resurrecting this now IMO.
--
Eric Botcazou
TRUCT_P flags in m32c_immd_dbl_mov? What condition do these tests try
to model exactly?
--
Eric Botcazou
t for the
kernel, etc. But most of them do things properly and stay compatible.
--
Eric Botcazou
ext
> of the signal itself. */
> if (STACK_GROWS_DOWNWARD)
> return _Unwind_GetCFA (context) - _Unwind_IsSignalFrame (context);
> else
> return _Unwind_GetCFA (context) + _Unwind_IsSignalFrame (context);
> }
Why does this "hack" not work? It was precisely devised for this purpose.
--
Eric Botcazou
rather than before it.
Don't set FS->signal_frame in that case. */
if (!signo || (*signo != 4 && *signo != 5 && *signo != 8))
fs->signal_frame = 1;
You might need to un-overload fs->signal_frame then.
--
Eric Botcazou
t).
The problem is very likely that the signal frame isn't marked as such.
--
Eric Botcazou
> I doubt he can help you with this one... When your problem concerns
> reorg, you should talk to people like Eric Botcazou or Richard
> Sandiford or HP Nillson. I've added Eric to the CC, to make this a
> happier crowd. :-)
Thank you. I was about to leave for vacation but I
l by the latter.
So I made a mistake when changing back the DF problem to LIVE in
2009-04-27 Richard Sandiford
Eric Botcazou
* resource.c (find_basic_block): Use BLOCK_FOR_INSN to look up
a label's basic block.
(mark_target_live_regs): Tidy and rewor
> I believe that I could legitimately approve that patch myself (it's
> pretty trivial and I didn't author it), but I'd prefer to get approval
> from one of the SPARC maintainers. Here's your chance:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html
OK.
--
Eric Botcazou
> I haven't been able to figure out what command to issue from the command
> line to reproduce this. Cut and paste from the dejagnu log doesn't
> work, which is more than annoying...
There is a blurb about this on http://gcc.gnu.org/wiki/DebuggingGCC
--
Eric Botcazou
the system assembler); GNU ld works too, although it lacks some features and
using the system linker might indeed be the Right Thing To Do on Solaris.
--
Eric Botcazou
e[2]: *** [compare] Error 1
>
> Would be interesting to see someone build i386-linux (really i386,
> not i586 or i686).
The i586-linux build fails in exactly the same way (this is PR 41241).
--
Eric Botcazou
me trick isn't working
> on 4.3.4.
I'd do things step by step, i.e. first try to have a full cygwin port without
changing the EH mechanism, then change it.
--
Eric Botcazou
x27;s complaining, which is why I'm
> confused; I thought that bit was stable.
Your .diff contains this
+ EH_MECHANISM=-gcc
so it looks as though the base compiler was SJLJ.
--
Eric Botcazou
o 225
OK, but the number of Ada failures is exactly 0 on x86/Linux, x86-64/Linux,
ia64/Linux, SPARC/Solaris and SPARC64/Solaris and 1 on PowerPC64/Linux so
you'll have to find out why it's so different for RTEMS.
--
Eric Botcazou
> Joel reported results for 4.5.0 20090910 r151592 and state of GCC
> changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.
Then, if EH is totally broken, a PR should be opened with a reduced testcase.
--
Eric Botcazou
> I will rebuild with the head and run ACATS on
> one of the broken ones. If still bad, then
> I will try with some simple exception tests
> Laurent put together the last time it broke.
> Maybe they are useful again. :)
Were they added to the gnat.dg testsuite? If no, they sh
401 - 500 of 1095 matches
Mail list logo
