> This patch is an improved version over the one proposed in
Please avoid cross-posting. This should go on [EMAIL PROTECTED] only.
--
Eric Botcazou
> I successfully bootstrapped yesterday and have been very few
> patches recently.
I ran into a similar problem on SPARC/Solaris on Sunday morning (revision
115296). The same tree bootstrapped fine on AMD64/Linux.
--
Eric Botcazou
> /tmp/ccK4i3re.s:5107:FATAL:Symbol LFBB43 already defined.
Same breakage on SPARC/Solaris 2.[56] and Alpha/Tru64.
--
Eric Botcazou
tupid for the FSF to
assume that the only way a user will use the software is that they build it
themselves. There should be an innate ability and a simple and easy method
for relocation of the software.
Eric Weddington
nk it is for. This list is for
contributors to gcc to talk about the development _of_ gcc.
Oh sorry I wasn't entirely certain from the description "general development
discussions" seemed likely. Would gcc-help be more suitable?
Exactly. :)
Good luck with your project.
-eric
27;re not sure.
Obvious question: what of the RTL expander(s)?
> Please adjust MAINTAINERS accordingly -- and then please fix PRs and
> approve patches for same. :-)
I see... :-)
--
Eric Botcazou
pointer (via
__attribute__((mode))), but cc1plus then aborts.
So... who is right? Are we supposed to support multiple pointer sizes
in the same compilation unit, or not?
Hmm... this worked when I put this in for s390 at one point - for
exactly the reason that you have with the attribute.
-eric
out of the office due to
other reasons. I will be looking at it shortly, especially as I've got
x86_64 patches. :)
-eric
support).
FWIW this works for me with the TImode patch that Geoff posted (that I
need for x86_64 anyhow)...
-eric
Jack Howarth wrote:
Eric,
Does that imply that the TImode patch is a must have
for Darwin x86_64 in the gcc 4.2 release? If so you might try
to convince Geoff that it really should go into gcc trunk
before the branch occurs. Frankly I was aghast to discover
yesterday that the folks doing the
Jack Howarth wrote:
Eric,
Does the following test fail for you under your x86_64 patch set for
Macintel?
No, but that's because I have a patch to fix it :)
-eric
ze of the frame went down from 216 to 200 bytes at -O2.
--
Eric Botcazou
you try
the above check on x86_64 and see how many regressions you have when the
linker warnings suppressed?
For i386 vs x86_64 I'm getting a different set of pass/fail between the
two. I do, however, have those 4 failures on x86_64 and not on i386.
-eric
ptr = ldst_entry (dest);
> + ptr->invalid = 1;
> + }
> +
> + }
> }
> else
> invalidate_any_buried_refs (PATTERN (insn));
Why not simply mimicing the "load" case and calling invalidate_any_buried_refs
on DEST, with a comment mentioning the (ZERO_EXTRACT (MEM)) corner case?
--
Eric Botcazou
k with the cctools
that was handed out at WWDC though. I've been looking around and can't
find them though. I'll keep you updated.
-eric
Jack Howarth wrote:
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Seems reasonable to expect that it could be made to happen.
-eric
h nothing wrong with the autoconf check as
well for now.
-eric
still notice if they start linking correctly and can move them to
run then.
thoughts? pre-approved? :)
-eric
Joseph S. Myers wrote:
On Tue, 12 Sep 2006, Eric Christopher wrote:
So, these are xfailed, but still produce quite a bit of noise on both
x86_64-darwin and x86_64-linux since they fail to produce a working executable
and then xfail. Should we move them to skip or link only and xfail them. With
Does anyone recognize any sort of pattern to these failures which might suggest
why they
fail on Darwin PPC at -m64 and not on ppc64?
We do have a radar about the lack of aligned uninitialized variable
support, i.e. .comm x,size,align that references t001 and t025.
-eric
Jack Howarth wrote:
Eric,
Do you see the same set of failures...
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o
Eric, Do you mean that they're noisy because of the WARNINGs? I always
find warnings annoying, perhaps test_summary should filter them out.
Yeah, that's what I meant.
Notice that for -m32, the message from the linker includes "In function
`main':"; this causes p
umber for that
bug to my PR so they are marked as the same bug?
There's no comment in the Radar as to the exact code, it just mentions
it as a likely cause.
ps I assume there are no fixes in-house at Apple for this one yet?
No.
-eric
> 3. Update sparc-sun-solaris2.9 to sparc64-sun-solaris2.10?
No strong opinion on the Solaris 9 -> Solaris 10 transition, but why switching
to a 64-bit compiler? The 32-bit compiler is multilib by default on Solaris
and AFAIK the vendor compiler is still 32-bit too.
--
Eric Botcazou
econdary is a good thing, and about time
too. Thank you for proposing this.
What would it take to get the avr target to secondary platform status? Not
that I believe it will happen immediately.
Thanks
Eric Weddington
tly replace the entire installed base of machines in the world.
Whereas I was hoping for the reverse with x86-darwin as primary and
ppc-darwin as secondary. :)
While we don't instantly replace the installed base there's an awful lot
of replacement going on AFAICT.
-eric
m target, but I can understand someone wanting linux instead.
Either is fine for me.
-eric
compiler options, require more memory than a 32-bit
compiler provides.
Just a comment.
You may or may not have noticed that there are no 64-bit native targets
for darwin.
-eric
I've gotten a
request for that to not warn. This seems reasonable, for example, if you
deprecate an entire API or something, but still need to compile the library.
Thoughts?
-eric
On Oct 4, 2006, at 10:53 AM, Bradley Lucier wrote:
On Sep 22, 2006, at 9:20 PM, Eric Christopher wrote:
Bradley Lucier wrote:
Right now, it seems that one may not be able to build a 64-bit
version of the compiler itself
You may or may not have noticed that there are no 64-bit native
Bradley Lucier wrote:
On Oct 4, 2006, at 1:57 PM, Eric Christopher wrote:
FWIW I think a 64-bit native version might be nice as a separate
target, but I've been told there's no real advantage there either on ppc.
Perhaps I'm misunderstanding your comment, but with a 64-
Jack Howarth wrote:
Eric,
I had always thought 90% of the advantage of
x86_64 was the extra registers in EMT64. Actually
the only gripe I have with Apple's transient to
Intel is that they didn't junk the i386 model and
only use chips that could do EMT64 so we would always
have t
that you'll know and might as well
pass --disable-multilib and start the build again :)
-eric
It's presumably a 1-
line change in the reverse_storage_order_for_component_p predicate.
--
Eric Botcazou
,
build_int_cst (TREE_TYPE
(*expr_p), 1));
--
Eric Botcazou
> 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
entence 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
> 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
osing these hours is to debug the code at -O0.
--
Eric Botcazou
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
,
but I'll catch up to you guys eventually :)
So at least we know for sure that this particular instance of extra
characters is coming from Wine. Maybe Wine can be smart enough to
only translate \n into \r\n instead of translating \r\n into \r\r\n.
Jacek / Eric, comments here? I'm happy t
> You will get the warnings with -pedantic.
> >
> > Martin
> >
> > Am Donnerstag, dem 19.10.2023 um 07:39 -0400 schrieb Eric Sokolowsky via
> > Gcc:
> > > I am using gcc 13.2 on Fedora 38. Consider the following program.
> > >
> > > #
On Thu, Oct 19, 2023 at 6:43 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-10-19T11:57:33+0200, Andreas Schwab wrote:
> > On Okt 19 2023, Thomas Schwinge wrote:
> >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> >>> I guess I can ask, why there is not a recursive approach
Personally, since GCC is in stage 3 now, I would push that schedule
back a release and move deprecation to GCC 15, and then only remove it
for GCC 16 if no one objects, but then again I don't actually use
-fgnu-tm myself, so I wouldn't be too upset if the faster schedule is
chosen instead.
Eric Gallager
Hello, I unintentionally stumbled upon some strange behaviour that
occurred due to a typo.
I reproduced the behaviour where an object (std::string in my case) can
be passed to a function by reference, uninitialized, WITHOUT a compiler
warning.
Changing the code to pass the object by value DOES
how to configure
> everything to match.)
./configure sparc-sun-solaris2.9 --prefix=xxx --enable-mpfr
--
Eric Botcazou
[CALL_EXPR]: Make return
slot explicit.
--
Eric Botcazou
> So now what? Not build shared libraries for gmp? Add /pkgs/gmp-4.1.4
> to my LD_LIBRARY_PATH?
The latter.
> This is supposed to be straightforward?
I guess so. :-)
--
Eric Botcazou
the PR).
>
> The C test case only fails on 4.0.0.
Man that's ugly.
Richard, were you going to look into this?
-eric
greater performance or
> efficiency, please do make the change but offer a switch to disable it and
> let the old code still compile. This way we it seems everybody can be
> happy.
My impression is that this has nothing to do with performance and efficiency,
unfortunately.
--
Eric Botcazou
of the array for example.
See the Ada front-end for practical references (ada/gcc-interface).
--
Eric Botcazou
eone
> tells me how I can join gcc developers group for sparc v8's custom core.
There is no formal group, just individuals on the GCC lists.
--
Eric Botcazou
with 0) or an AND (and r0, r0, r0)?
> Doesn't seem right to add peepholes for each of those cases.
>
> Is that something the RTL optimisers should be able to remove?
Maybe, but it is hardly doable to recognize every RTL variant of a no-op, so
I'd suggest fixing the pass that generates it instead.
--
Eric Botcazou
SAGE are taken into account; if it is
false, they are not. Then mark_referenced_resources is called with true or
false from reorg.c depending on the context.
> How can I tell whether an insn "only" sets a call arg register, and is
> otherwise permutable with the call insn itself?
You need to parse CALL_INSN_FUNCTION_USAGE.
--
Eric Botcazou
> Not any longer, 4.9 has AB edges to setjmp from longjmp or potential longjmp
> callers.
And all 4.x (x >= 1) compilers have AB edges to (lowered) __builtin_setjmp
from __builtin_longjmp or potential __builtin_longjmp callers.
--
Eric Botcazou
s GCC 4.7-based
implementation for the Ada compiler to this branch. Once this is done, I'll
welcome suggestions and ideas to support this new feature in other languages.
--
Eric Botcazou
onsistently (i.e. the storage order
only changes at byte boundaries), although you may need FE assistance here.
The only (big) limitation is thay you cannot take the address of an individual
field in these aggregate types, but in Ada it's not a problem since it's the
default for any field in any aggregate type.
--
Eric Botcazou
y answer not including the
> word 'reload'.
Very likely in sched-deps.c:find_modifiable_mems and related functions.
--
Eric Botcazou
elf how the 'int' and the 'double' are laid out on the SPARC.
--
Eric Botcazou
_expr), if you want to be able to compile
big codebases with a reasonable amount of resources.
--
Eric Botcazou
> the compiler goes wrong, or for a user, to check if his/her code contains
> alias set problems.
> Would this be suitable for a GSOC project?
I don't know, that seems to be a bit daunting for a GSOC project.
--
Eric Botcazou
of auto-increment.
> Any ideas?
The general principle is to avoid pseudo-registers with long live ranges
because this unnecessarily contraints the RTL optimizers.
--
Eric Botcazou
we have two live registers and it seems hard to eliminate.
>
> So could the unrolled codes be like below?
I'd try the opposite first, i.e to do more renaming so as to get smaller live
ranges for the pseudo-registers and thus help the auto-inc-dec and RA passes.
--
Eric Botcazou
is passed -Av8 as is currently done for LEON/LEON3. As a matter of fact,
I just installed a patch to add basic LEON3 support on the trunk so almost
everything is already there as far as the compiler is concerned.
--
Eric Botcazou
> Hi Eric, do you mean that you already have a patch to solve this issue
> which is just not merged to mainline? If yes could you send me your patch
> and tell me to how enable this feature? Thank you!
No, I only installed a patch on the trunk that adds the basic infrastructure
fo
binutils side,
because a 'cas' is currently rejected by the assembler:
eric@hermes:~/leon-elf> gcc/xgcc -Bgcc -c cas.adb -mcpu=leon3
/tmp/ccOuqOpo.s: Assembler messages:
/tmp/ccOuqOpo.s:24: Error: Architecture mismatch on "cas".
/tmp/ccOuqOpo.s:24: (Requires v9|v9a|v9b; requested
cannot be renamed since they are meant to be
compiled by the C compiler; only the ones under ada/gcc-interface can.
--
Eric Botcazou
I have tried to copy QuickSort c++ programs:
---
#include
using namespace std;
class Element
{
public:
int getKey() const { return key;};
void setKey(int k) { key=k;};
private:
int key;
// other fields
};
#define InterChange(list, i, j) t
Hello, I follow your suggestion change from Macro to function, it improved a
little bit, but still not correct result
--
root@eric-laptop:/home/eric/fundamentalsofdatastructuresincpp/ch7# ./a.out
26 5 1 37 61 11 59 15 48 19
bal[1]= 5
bal[1]= 5
bal[1]= 5
bal[1]= 5
bal[1]= 5
bal[1
tream_Attributes.I_I.Part': call is unlikely and code size would grow
[-Winline]
gnat1: warning: called from here [-Winline]
because small external functions marked inline are now split instead of being
fully inlined.
Thoughts?
--
Eric Botcazou
trap in a valid program or may generate a fault if it appears in a
context that isn't appropriate.
--
Eric Botcazou
EXEC_PREFIX=\"$(libexecdir)/gcc/\" \
-DDEFAULT_TARGET_VERSION=\"$(version)\" \
-DDEFAULT_TARGET_MACHINE=\"$(target_noncanonical)\" \
-DSTANDARD_BINDIR_PREFIX=\"$(bindir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(libsubdir_to_prefix)$(prefix_to_exec_prefix)\" \
\
$(VALGRIND_DRIVER_DEFINES) \
$(and $(SHLIB),$(filter yes,yes),-DENABLE_SHARED_LIBGCC) \
-DCONFIGURE_SPECS="\"\""
which looks correct.
--
Eric Botcazou
> In this particular case it looked easy to reimplement using $(if).
>
> Could you please try this patch with make 3.80?
It works fine, thanks.
--
Eric Botcazou
Ping?
> Here's the corrected ChangeLog entry.
>
> 2013-09-30 Tom Tromey
>
> * Makefile.in (DRIVER_DEFINES): Use $(if), not $(and).
--
Eric Botcazou
> Sorry, I think it requires a review.
> I'll send it to gcc-patches.
IMO it clearly falls into the obvious category.
--
Eric Botcazou
mandatory to handle delay slot of conditionnal jump instructions ?
This looks like a bug in the dbr pass (several of them have been fixed since
4.5.2) but it's impossible to be more precise without further details. The
support of annulled instructions is not required for proper operation.
--
Eric Botcazou
value, then (reg:V8HI 125 d31) should not be
generated under normal circumstances. Here it's a var location so this might
be less clear, but still. How are the REG and SUBREG generated exactly?
--
Eric Botcazou
27;t think it would
> be good for GCC for a bootstrap break to depend on me.
In contrast to that, the FSF repository is the master repository for GNAT and
breakages can be quickly fixed by anyone with write access.
--
Eric Botcazou
ven those results if one of
> the key goals is to reduce waiting time.
If everyone has the same figures as you, I cannot disagree.
--
Eric Botcazou
years ago:
http://gcc.gnu.org/ml/gcc/2010-10/msg00506.html
with the Ada vs Java part:
http://gcc.gnu.org/ml/gcc/2010-11/msg00451.html
including some numbers:
http://gcc.gnu.org/ml/gcc/2010-11/msg00452.html
--
Eric Botcazou
> Eric, would emitting GIMPLE from gigi make that a lot more
> complicated? That is, would you prefer to have an even
> higher-level early GIMPLE (considering stuff like TARGET_EXPR
> and WITH_CLEANUP_EXPR, etc.)?
This would mean privatizing in gigi all the machinery needed to s
hy I also mentioned fold-const.c, all the size_* routines and their
dependencies would need to be privatized as well. I can think of marginal
benefits like more direct transfert of optimization hints on loops for
example, but nothing really decisive.
--
Eric Botcazou
lot of things, unlike GIMPLE which is much more narrow.
--
Eric Botcazou
.
>
> And, yes I'm aware of the wonderful irony that I'm debugging a bootstrap
> problem with Ada related to my recent work :-)
>
> Thoughts on the updated proposal?
IMO we need a non-call-exception language in the default mix, whatever it is.
--
Eric Botcazou
; -j4
instead of a bare make -j4 on the machine?
--
Eric Botcazou
other
places with the same TYPE_PRECISION/GET_MODE_BITSIZE check, in particular the
very similar transformation done in fold_single_bit_test_into_sign_test.
--
Eric Botcazou
> Would appreciate a fix/work around!
Configure with --disable-libsanitizer.
--
Eric Botcazou
CXX at the configure stage:
CC="gcc -m32" CXX="g++ -m32" $(srcdir)/configure ...
--
Eric Botcazou
f unaligned memory accesses can never
generate a fault on the architecture. But, in practice, you might want to
take into account performance considerations.
--
Eric Botcazou
not duplicate the treatment applied for nonzero_sign_valid?
--
Eric Botcazou
ode);
*nonzero &= mask;
return NULL;
}
--
Eric Botcazou
re it's not beneficial altogether?
I can think of 3 possible solutions:
- WORD_REGISTER_OPERATIONS,
- promote_mode,
- optabs.
The 3rd solution seems to be the most straightforward, but this would be the
first time that we test optabs from simplify-rtx.c.
--
Eric Botcazou
add new
passes in order to mitigate them.
> IMO combine should just be about instruction selection. The patch
> still seems good to me from that POV.
The patch is in simplify-rtx.c though, not in combine.c, so it's more general.
--
Eric Botcazou
ally when you're manipulating the RTL.
--
Eric Botcazou
the point exactly? What do we gain here?
Look for example at comment #4 in PR rtl-optimization/58295.
> If you think the patch was wrong or if you feel the fallout is too great
> then please feel free to revert it.
I think that the fallout is too great for RISC targets, yes, so I'm trying to
find a reasonable compromise.
--
Eric Botcazou
nal then I think we should revert it. But like I say I think
> it would be better to make combine recognise the redundancy even with
> the new form. (Or as I say, longer term, not to rely on combine to
> eliminate redundant extensions.) But I don't have time to do that myself...
It helps x86 so we won't revert it. My fear is that we'll need to add code in
other places to RISCify back the result of this "simplification".
--
Eric Botcazou
ombine.c to
undo the effects of the simplication in simplify-rtx.c? And move the latter
simplification back to combine.c in the process?
--
Eric Botcazou
LUS or a MINUS:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01682.html
The outer operation sort of guarantees that operating in this mode is OK for
the target, so the transformation can be done unconditionally. It could be
also done in simplify-rtx.c instead of combine.c.
--
Eric Botcazou
32.html
http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg01074.html
that (very likely) rely on simplify_gen_subreg distributing the SUBREG.
OK, at this point I'm going to propose the minimal kludge...
--
Eric Botcazou
> No. This example was working in 4.6 and broken in 4.7 and 4.8.
> Well, 4.7 should have warned about that.
The 4.7 branch is not closed so it's not too late to add the warning there.
--
Eric Botcazou
1101 - 1200 of 1858 matches
Mail list logo
