> this patch of yours
>
> 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
>
> * gcc-interface/utils.c (convert_vms_descriptor): Add
> gnu_expr_alt_type parameter.
> Convert the expression to it instead of changing its type in place.
> (build_
that !DECL_INITIAL => DECL_INITIAL == 0 for TREE_READONLY+TREE_STATIC
and not TREE_READONLY alone.
--
Eric Botcazou
if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
&& DECL_DLLIMPORT_P (exp))
return false;
return true;
}
--
Eric Botcazou
ng about the initial
processing (i.e. during RTL expansion), the information is encoded in the
trees fed to the expander.
--
Eric Botcazou
> Is there a way to know whether an operand is signed or unsigned from its
> rtx?
Basically no, this information is not encoded in the operand, rather in the
operator (if it matters).
--
Eric Botcazou
quot;incorrect"?
Quad cores are available for exactly 1 architecture (x86) at affordable
prices, GCC is supposed to support more than just x86.
--
Eric Botcazou
usr/local/sparc-solaris/include is old.
Or a configuration problem, see PR target/28097.
--
Eric Botcazou
> Any suggestions on how to fix this issue?
gen_int_mode
--
Eric Botcazou
ore a call_insn
then the registers containing the arguments of the call are
live_throughout in the new insn.
--
Eric Botcazou
gt; [...]
> Things go wrong in "call_insn/u 215". Target has R0 and R1 are the
> parameter registers.
There should probably be a USE for R1 on the call insn then, like for R0.
Why is it there for the latter and not for the former?
--
Eric Botcazou
> If it doesn't today, then there's no tests covering the problems.
It does if you have a 64-bit HOST_WIDE_INT on your 32-bit host and this is now
enforced for most 64-bit targets.
--
Eric Botcazou
> I wasn't under those recipients.
For the sake of completeness, I wasn't among them either. But I can only
offer diligent review of SPARC specific patches these days and help for
severe problem reports.
--
Eric Botcazou
-gnatpg -gnata"
Looks like you're building the 4.4 cross-compiler with the 4.1.2 system
compiler. Use the 4.4 native compiler instead.
--
Eric Botcazou
> Fails here on ia64.
OK, this should be fixed everywhere now.
--
Eric Botcazou
> That appears to be caused by this change:
>
> 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]>
>
> * decl.c (gnat_to_gnu_entity) : Promote the alignment of
> objects by default.
> * fe.h (Debug_Flag_Dot_A): Delete.
> * debug.adb (-gnatd.a): U
> Yes. Any help?
This doesn't make any sense to me. I would put a breakpoint on the few lines
that update pbi->reg_live in flow.c and see why one of them triggers.
--
Eric Botcazou
> Start from the bb's live out and calculate each insn's live in&out.
> Where the first insn's live in must be the bb's live in, but the
> assertion failed.
So you're dumping pbi->reg_live after the call to propagate_one_insn as "insn
live in", right?
--
Eric Botcazou
le (file, insn_live_in);
and
fprintf(file, "after propagate, insn live in:\n");
debug_bitmap_file (file, insn_live_in);
be different if you don't update insn_live_in? You need to say what you're
really dumping here.
--
Eric Botcazou
> Yes, I'm talking about propagate one insn in flow.c. How I map live in
> and live out, please see the code below.
Thanks, but AFAICS this code doesn't update insn_live_in at all.
--
Eric Botcazou
> Yes, I'm talking about propagate one insn in flow.c. How I map live in
> and live out, please see the code below.
Thanks, but AFAICS this code doesn't update insn_live_in at all.
--
Eric Botcazou
)
> (nil))
Are you talking about flow.c:propagate_one_insn? If so, how do you map
"live in" and "live out" exactly, given that flow.c doesn't use these
but operates on a struct propagate_block_info instead?
--
Eric Botcazou
inter_align does not need length
attribute. Move x_regno_reg_rtx to ...
(regno_reg_rtx): ... new global array.
(reg_rtx_no, seq_stack, REGNO_POINTER_ALIGN): Update accestors.
[...]
Jan, any idea as to what could be going on here?
--
Eric Botcazou
Hi,
Since yesterday I'm having seemingly random bootstrap comparisons failures on
i586-suse-linux: for caller-save.o yesterday, for build/gensupport.o today at
revision 133861. But a second tree at the same revision bootstrapped fine.
Is anyone else seeing this?
--
Eric Botcazou
ed.
If maintaining it is now too much of a burden, then let's close it.
--
Eric Botcazou
s OK with this. This makes
things simpler for distributors. And I think that creating a special branch
would create more confusion than anything else.
So I'd simply revert the patch that (presumably) accidentally changed the
licence of this particular file and ask people to be careful about t
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
--
Eric Botcazou
e branch and not from
> point-releases anyway.
Seconded.
--
Eric Botcazou
> It builds now.
Thanks for the confirmation, and to H.J. for the fix.
--
Eric Botcazou
> I think something has broken for GNU/Linux x86 in
> the past week on the head. It was building fine last
> week. Does anyone else see this?
You just need to browse Bugzilla, it's PR tree-opt/35493.
--
Eric Botcazou
> This is:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35493
>
> Patch by H.J. Lu to fix the issue was approved but not commited yet:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html
It has been committed now.
--
Eric Botcazou
> I meant Ada can have non-integral members that are do not occupy an
> integral number of bytes.
Right, but the middle-end shouldn't need to touch them globally, the front-end
is supposed to break up the accesses.
--
Eric Botcazou
Of course we would be happy to lend a hand. :-)
--
Eric Botcazou
> Well let's see .. we (AdaCore) will try to focus more attention on this
> to evaluate whether it is feasible to get this feature working well
> enough to use in GNAT.
We already did that several times: -ftrapv is too broken to be used for Ada.
--
Eric Botcazou
> I opened
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
Thanks!
--
Eric Botcazou
int in decl.c where
the error message is issued and try to find out why it is issued with the
modified compiler and why it is not with the pristine compiler.
--
Eric Botcazou
compiler expects DImode to be aligned according to its
size, like other integral modes. I'd suggest to distill a reduced testcase
and debug side-by-side in decl.o (the error message is issued there) against
the pristine compiler, maybe it's only an oversight.
--
Eric Botcazou
> with Ada, right?).
Actually no, it's not possible. Once something is BLKmode, it's at least
aligned on a byte boundary. It's only possible for integral modes.
--
Eric Botcazou
> I'm not sure what to do about bit-aligned TImode fields
> for example, or other things that appearantly can be done with Ada
> (which allows bit-packing).
I think that we can live without TImode bitfields, up to DImode would be fine.
--
Eric Botcazou
> It has callers and callees which should not be inlined in order to
> reproduce the bug.
__attribute__((noinline))?
--
Eric Botcazou
t; debug format).
I propose to deprecate the *-*-solaris2.5 and *-*-solaris2.6 targets, the OS
were released more than a decade ago. The minimal supported version would
then be Solaris 7, the first version that can support DWARF-2 debug info.
--
Eric Botcazou
> This sounds like PR31081.
Indeed, the C++ testcase is the exact translation of my Ada testcase. :-)
The problem seems to arise relatively often in Ada, I think the PR should be
made "critical".
--
Eric Botcazou
p' on it and
compile at -O -gnatp.
Thanks in advance.
--
Eric Botcazou
package Q is
procedure Read(S : out Integer);
procedure Restore(S : in out Integer);
end Q;
package P is
type Int_Ptr is access all Integer;
procedure Exec(P : Int_Ptr);
end P;
with Q; use Q;
package
> a few cases but not in all. How can this happen?
You should not need to pass -fdelayed-branch explicitly. If you do, this
means you're compiling at -O0, in which case the problem you run into is not
very surprising. Just compile with bare -O1 at a minimum.
--
Eric Botcazou
> If you have a better justification, i'd love to hear it.
Justification for what? I only tried to explain to Sam why we do things the
way we do, I didn't write the GNU Coding Standards either.
--
Eric Botcazou
s simply not true, the ChangeLog and the commit messages in the
ada/ subdirectory are on par with the rest of the GCC tree, and that's fine.
--
Eric Botcazou
> Right, because surely one size fits all projects and possibilities,
It was supposed to be the Coding Standards for The GNU Project.
> and workflow and processes have certainly not changed since then.
In my opinion, it's now easier to work around their perceived deficiencies
e One True
> Way seems very suspect to me. After all, how else would they ever
> improve if nobody tries anything different?
The people who wrote them presumably thought about these issues, too.
--
Eric Botcazou
uite effective "executive summaries" for the patches and helpful to the
reader/reviewer. Please let's not throw the baby with the bath's water.
--
Eric Botcazou
> Sure, but as you explained yourself in the message I cited, the reason
> to do this change was because of a problem in STABS info generation :)
"reason" is not quite appropriate in this case, "occasion" is more accurate.
--
Eric Botcazou
> I'll take an example from one of your recent changes in gcc/ChangeLog:
>
> 2007-11-19 Eric Botcazou <[EMAIL PROTECTED]>
>
>* stor-layout.c (lang_adjust_rli): Delete.
>(set_lang_adjust_rli): Likewise.
>(layout_type):
>
> gcc/
> * config/sh/sh.md (cmpgeusi_t): Fix condition.
>
> which I used as suggested.
Not really in my opinion, it's a trivial fix and totally unrelated to Ada in
itself, "Fix typo" or "Fix obvious mistake" would have been just fine too.
--
Eric Botcazou
finding it
> by searching the mailing-list is not practical and it is not coupled
> with the checkin.
That's how it has always worked so it should be more or less practical.
For PRs, there is a link (URL: field), maybe we should use PRs more often.
--
Eric Botcazou
ACATS and GNAT
testsuites are also clean. Maybe occurs only on non-DWARF2 platforms too.
--
Eric Botcazou
> FWIW. I see the same behavior for i386-unknown-netbsdelf3.1 too (when
> compiling natively, i.e. not using cross compiler).
For native platforms, I would suggest to switch to DWARF-2 EH, see for
example system-freebsd-x86.ads.
--
Eric Botcazou
t makes it possible to reproduce it even on platforms where
it doesn't arise natively, by making the opposite change you made.
> Is there a PR for this or do I need to try to file one?
No, I don't think there is one.
--
Eric Botcazou
gnat_begin_handler
> + __gnat_end_handler
>
> Where do those come from and how do I turn them on?
raise-gcc.c and a-exexpr-gcc.adb, you need to add
EH_MECHANISM=-gcc
to the RTEMS section of Makefile.in.
--
Eric Botcazou
> Well it is now up to 13 minutes of compile time
> on that one file when it is 30 seconds at -O0 so
> this doesn't appear to help significantly.
OK, sounds like a real problem then.
--
Eric Botcazou
olaris), probably why nobody had noticed until recently.
Does RTEMS support DWARF-2 EH? If so, change the following lines to True
ZCX_By_Default: constant Boolean := False;
GCC_ZCX_Support : constant Boolean := False;
in system-rtems.ads.
--
Eric Botcazou
time from -O2 -> -O0 to work around the
> huge compile time. Is it possible that that
> is breaking the run-time?
That should not, in any cases.
--
Eric Botcazou
> Can anyone report that Ada works on the
> head on a SPARC or PowerPC self-hosted
> system?
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00945.html
--
Eric Botcazou
ptimization set to -O3.
Thanks for doing this!
> Thanks to Sun for donating a T2000 to Debian and to OSU's Open Source
> Lab for hosting the machine.
Seconded. :-)
--
Eric Botcazou
> I opened a bug
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
Thanks!
--
Eric Botcazou
compiler are a feature, --disable-checking should not be advertised since
all the assertions are now predicated on at least --enabled-checking=release.
That being said, if there is a bug, I agree that we should try and fix it.
--
Eric Botcazou
> I'm still seeing the same failure on x86_64-unknown-linux-gnu, is this
> going to get fixed?
You're not supposed to configure the compiler with --disable-checking as this
disables the internal assertions, use --enable-checking=release instead.
--
Eric Botcazou
ick an open PR in Bugzilla (http://gcc.gnu.org/bugzilla) and
try to fix the problem. We have dozens of these. :-) Some of them have been
pre-analyzed. An ICE (internal compiler error) is probably easier to start
with than a wrong-code bug.
--
Eric Botcazou
nder pressure. Do you define REG_ALLOC_ORDER for your
port? If so, in what position is $c1?
--
Eric Botcazou
3 $c3 [ ivtmp.103 ]))
>(expr_list:REG_DEP_TRUE (use (reg:SI 2 $c2 [ h ]))
>(expr_list:REG_DEP_TRUE (use (reg:SI 1 $c1 [ ivtmp.101 ]))
>(nil))
I don't think so, it should be in dead_or_set, the value contained in $c1 dies
in the insn.
--
Eric Botcazou
> Oh, I am using quite a new version of the compiler - rev 129547,
> DATESTAMP 20071022.
OK. AFAICS there is nothing glaring in the RTL you posted so you'll have to
put a watchpoint and find out who has set reg_rtx for this particular reload.
--
Eric Botcazou
gt; Anyways shouldnt reload be checking for live registers before reloading into
> them ?
Of course, it goes to great length to do so but there can be bugs. You didn't
specify which version of the compiler you're using though; they may have been
already fixed on the mainline.
--
Eric Botcazou
an instruction should not be true under
> INSN_P. Yet, INSN_P returns true for DEBUG_INSN. This is already
> leading to a lot of special-casing of DEBUG_INSN throughout the RTL
> bits of the compiler on the branch.
I share your concerns, but I've not looked at the specifics.
--
Eric Botcazou
es by providing more accurate
> insns lengths?
Yes, but this should work automatically. IOW, as Ian said, you shouldn't need
to do anything special. Maybe it's simply a latent bug in the PPC back-end.
--
Eric Botcazou
he fix for PR tree-optimization/33870 basically short-circuited it.
--
Eric Botcazou
> Please read the _description_ that comes along with the code example.
I did.
> Anyways, the patch is there.
The one for ifcvt.c, yes; more will be needed though, see for example
http://gcc.gnu.org/ml/gcc/2007-10/msg00754.html
--
Eric Botcazou
mple you gave in your first message.
--
Eric Botcazou
not all
or nothing like your earlier message[*] seemed to imply.
[*] http://gcc.gnu.org/ml/gcc/2007-10/msg00663.html
--
Eric Botcazou
> The use doesn't become proper simply because it appears in the code,
> even if in the code of GCC. volatile might be used there for
> completely different reasons.
No, I put it there for this purpose.
--
Eric Botcazou
> I have applied the "final" patch, if you want to re-test.
Slightly better, but not much (7 min for a full-checking bootstrap).
--
Eric Botcazou
mer has
> asked for, is often an overall loss.
That's a little outdated though, 4.x behaves differently.
--
Eric Botcazou
.
See gcc/gthr-posix.h for a proper use of "volatile" for a shared access.
--
Eric Botcazou
> Let's see what the results are on the now "optimal" first strategy.
Far better, but I've still a 51 min gap on a full checking bootstrap.
--
Eric Botcazou
rom
the viewpoint of the current thread, this is the crux of the matter.
--
Eric Botcazou
> The value that will be seen by other threads after they synchronize
> memory (with pthread_mutex_lock(), for instance).
What does it mean from the viewpoint of the current thread?
--
Eric Botcazou
mong other things.
>
> But if *v is simply shared, do all stores to it matter? No, only the
> final value is relevant.
Define "final value".
--
Eric Botcazou
> I'm working on it.
Thanks. However, don't we simply void the benefit of memory partitioning by
recursing on the MPTs?
--
Eric Botcazou
le for each version of the library.
The surge comes from the fix for PR tree-optimization/33870 (rev 129675).
With it, 'make all-target-libjava' takes 261 min user time. If I revert it,
do a 'make quickstrap' and run the command again, it only takes 109 min.
--
Eric Botcazou
> I get the following ICE running bootstrap with -O2 on ppc,
> --with-cpu=default32 r129655:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01543.html
--
Eric Botcazou
> If you make the function static then gcc can chose ABI-incompatible
> calling conventions.
Right, and the gain can be significant on x86.
--
Eric Botcazou
x-gnu
> i386-unknown-freebsd5.5
> i686-pc-linux-gnu (2)
> ia64-unknown-linux-gnu
> s390-ibm-linux-gnu
> s390x-ibm-linux-gnu
> sparc-sun-solaris2.8
> sparc64-unknown-linux-gnu
> x86_64-unknown-linux-gnu (2)
Thanks!
--
Eric Botcazou
if you care about OpenMP on Solaris 10.
--
Eric Botcazou
-testresults/2007-10/msg00390.html
They are more noisy than usual because of -fpic/-fPIC testing.
--
Eric Botcazou
cause it's a builtin. More generally, the RTL back-end
is allowed to mangle symbol names at its pleasure. You can display the RTL
associated with a FUNCTION_DECL by invoking debug_tree on it from within GDB.
--
Eric Botcazou
> The two files in question do compile at -O0 so you wouldn't
> trip it.
You misunderstood, only the compiler is built at -O0 -g, the runtime is built
normally at -O2 -g.
--
Eric Botcazou
> I would appreciate it is one of the SPARC/Solaris
> users would see if they can duplicate this.
I cannot duplicate on SPARC/Solaris, but my tree is not pristine.
This is for a --disable--bootstrap compiler built at -O0 -g.
--
Eric Botcazou
> Seemed safer to just roll things back and sort it out later.
Understood, thanks again for the quick turn around.
--
Eric Botcazou
> Sorry, folks. I've rolled this back.
Thanks, but this was not really necessary, Ada doesn't define
LANG_HOOKS_EXPAND_CONSTANT, you only needed to restore lhd_return_tree.
--
Eric Botcazou
nu
Looks like
2007-08-31 Ben Elliston <[EMAIL PROTECTED]>
* Makefile.in (LIBGNAT_TARGET_PAIRS): Use system-linux-ppc64.ads
when compiling for powerpc64-*-linux.
* system-linux-ppc64.ads: New file.
needs to be refined.
--
Eric Botcazou
const_double rtx and I appreciate
> help regarding this.
CONST0_RTX (SFmode)
--
Eric Botcazou
ARC toolchain from Sun. There have been indirect contributions, e.g. for
Solaris 10 support, and AFAIK they have been merged in the FSF tree.
--
Eric Botcazou
ions to the SPARC toolchain by Sun or
Canonical people over the last few years.
--
Eric Botcazou
pping between -mcpu settings and 32-bit ABI levels is as follows:
-mcpu 32-bit ABI
v7 v7
v8 v8
v9 v8plus
ultrasparc v8plusa
ultrasparc3v8plusb
--
Eric Botcazou
601 - 700 of 1093 matches
Mail list logo
