Hello,
Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to
evaluate GDB (6.4) debugging capabilities currently yields very
unpleasant results compared to what we obtain with a GCC 3.4 based
compiler (80+ extra failures out of 1800+ tests).
We so far presumed that this is caused by l
I wrote:
<< I'd appreciate feedback on general questions from these observations:
Is it generally known/expected that xcoff/stabs debugging capabilities
degrade when moving from 3.4 to 4.x ?
If yes, how is that considered by AIX GCC developers ? (how serious the
issue, is it fixable
Hello,
PPC EABI targets are currently configured with both BIGGEST_ALIGNMENT and
PREFERRED_STACK_BOUNDARY set to 128, I believe to accomodate
"a long double member within a structure or union shall start at the lowest
available offset aligned on a 16byte boundary"
Besides, for 32bit non-alt
Dave Korn wrote:
> > "a long double member within a structure or union shall start at the
> >lowest available offset aligned on a 16byte boundary"
> It only implies that the offset should be such a multiple, but since the
> struct itself will have to be aligned to a multiple of 16 if any o
Geoffrey Keating wrote:
> BIGGEST_ALIGNMENT is 128 for a number of reasons, but
> PREFERRED_STACK_BOUNDARY is 128 primarily so that code compiled with
> -meabi can also be used on Linux and other SVR4 targets, and for
> Altivec support.
I see. Both would deserve comments, IMHO.
Thanks for your
Hello,
As mentioned in a previous discussion at
http://gcc.gnu.org/ml/gcc/2005-04/msg01416.html
we have troubles with the expand_main_function code to adjust the stack
pointer to PREFERRED_STACK_BOUNDARY on entry points.
It currently aligns the stack pointer by applying explicit operations on
Richard Henderson wrote:
> > A possible way to address that is to have expand_main_function compute the
> > distance between the current and aligned values of the stack pointer and
> > resort to allocate_dynamic_stack_space to allocate exactly that amount.
> Sure, if it works.
OK, I'll test my
Hello,
Is there a rationale for the list of bss patterns matched by
default_section_type_flags_1 ?
<< if (strcmp (name, ".bss") == 0
|| strncmp (name, ".bss.", 5) == 0
|| strncmp (name, ".gnu.linkonce.b.", 16) == 0
|| strcmp (name, ".sbss") == 0
|| strncmp (name, ".sbss."
Hello,
Can GCC 4.X be used to generate code running properly on a MPC5554
processor ?
>From the current sources, it seems to me that the closest explicitly
supported CPU is the 8540, but I'm a bit unclear if code for the
latter would be fully compatible for the former, or if other variants
would
Hello,
In a number of places, the gimplifier simply discards what involves
zero sized entities. For instance:
in "gimplify_init_ctor_eval"...
FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value)
...
if (zero_sized_field_decl (purpose))
continue;
or in "gimplify_mod
Daniel Berlin wrote:
> Even if you "fixed" init_ctor_eval (modify_expr gimplifies the lhs and rhs
> and throws away the assignment), you're going to run into problems in
> the subvar machinery if you really have 0 sized field accesses with side
> effects.
>
> I'm not sure what the heck a "0 siz
Dave Korn wrote:
> Surely returning the vaule of this uninitialised variable makes your code
> invalid?
Well, sure. Adding an initializer in one_raw_spinlock doesn't help.
The t03.gimple dump reads:
main ()
{
struct spinlock_t D.1783;
int D.1784;
struct spinlock_t lock;
Daniel Berlin wrote:
> > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
>
> What exactly is this code expected to do?
> Call one_raw_spinlock and then throw away the result?
Yes. As you said, the result is nothing anyway, but the function should
still be called IMO.
>
Andrew Pinski wrote:
> > I have been experimenting with a simple patch adding side effects
> > checks to the conditions, like "! TREE_SIDE_EFFECTS (value)"
> > in init_ctor_eval
>
> Yes the one in needs to gimplify only the expression as a statement
> and not add a modify statement. More on the t
Olivier Hainque wrote:
> I'm not yet clear why the call is not issued there. This is my first
> dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, despite the presence of a function c
Hello,
To:
> Can GCC 4.X be used to generate code running properly on a MPC5554
> processor ?
[...]
> What are the GCC 3.4 capabilities on the same account ?
David Edelsohn replied:
<< The base PowerPC Book-E UISA generated by GCC should work on the
MPC5554. I am not sure about the differen
Andrew Pinski wrote:
> > FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
> > set on the constructor, despite the presence of a function call in
> > the components.
> No, that is not the problem. The problem is that we gimplify the
> expression for side effects but don't actua
Richard Henderson wrote:
> Try
>
> cst_uchar_ptr_node
> = build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true);
>
> which is apparently in use by the Ada front end, but only if a
> certain pragma is given. Dunno how reliably that's likely to work.
We are seeing regressions in our
Daniel Berlin wrote:
> > Out of a preliminary look into this code (new to me), a possible
> > place to address that appears to be 'get_tmt_for', which
> > presumably should assign a zero alias set to tags for pointer
> > types with that bit set.
> Actually, you just want it to assign the same
Daniel Berlin wrote:
> > I am still unclear on one point: is it fine to reuse the same tag for
> > possibly different designated types ?
>
> Yes, as long as they have the same alias set.
OK. A last detail:
On the first tag_set 0 creation, we get into:
if (var_ann (ptr)->type_mem_tag =
Daniel Berlin wrote:
> Well, doesn't the pointed-to type have set 0 because of
> TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)?
Not quite: the pointer type has TYPE_REF_CAN_ALIAS_ALL, not the
pointed-to type:
/* Nonzero in a pointer or reference type means the data pointed to
by t
Hello,
The Ada testcase below, compiled with -O2 on x86-linux, triggers a
SEGV in the current mainline compiler, there:
do_simple_structure_copy
{ ...
for (; p && p->offset < last; p = p->next)
{ ...
q = first_vi_for_offset (q, q->offset + fieldoffset);
==>temprh
Daniel Berlin wrote:
> IOW, you are lying to the middle-end about the size of the fields.
> Why is the type not a 6 bit integer?
Because we avoid creating a different type for every possible
bitsize, which seems to be the purpose of DECL_SIZE in the
first place and is explicitly expected by the
Daniel Berlin wrote:
> >
> > size
> > > size
> > precision 3 min max >
>
> You'll note we actually created a new type for this :)
Indeed, and I think we also have that in Ada, my confusion. The
TYPE_SIZE is still larger than the DECL_SIZE above, and the field
rea
Richard Henderson wrote:
> > precision 3 min max >
> ^^^
>
> Actually, we did create a different type just for this bitsize.
Indeed, my comment was confused on that account.
> Not that that detracts from the fact that TYPE_SIZE is always a
> multiple of BITS_PER_UNIT.
Agr
Daniel Berlin wrote:
> Thinking harder about it, you might be better off then making
> everything based on TYPE_SIZE then, since we don't always have the
> FIELD_DECL's handy.
[...]
> i meant in tree-ssa-structalias.c. The results you get by doing this
> should be fine.
Oh, OK. Will look into
Bernd Trog wrote:
> Hello,
Hello Bernd,
> whats the status of -fstack-usage?
>
> Will it output the real or worst case stack usage?
The latter in any case, although I'm not sure what you mean by "real"
stack usage. Could you please enligthen ?
Olivier
Bernd Trog wrote:
> By "real" I ment the actual stack usage (which is -Ox dependent) and by
> "worst case" I ment by looking simply at the code before any optimization.
>
> The actual stack usage would be most interesting, of course.
Of course, and is actually what -fstack-usage will report. I h
Hello,
Ioannis E. Venetis wrote:
> Having followed this thread and searched a little bit more, I understand
> that -fstack-usage will dump information into a file at compile time.
Right.
> However, I was wondering whether something similar would be possible at
> run-time.
>
> I am working o
Hello,
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on June 12-14, 2020.
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2020
The conference is free to attend, registration in advance is require
Dear all,
With the current evolution of the COVID-19 crisis worldwide, we are
unfortunately not in a position to maintain the organization of this
year’s GNU Tools Cauldron as originally planned in June.
We are working on the finalization of postponement options and will
let everyone know as soon
Dear all,
> On 19 Mar 2020, at 15:58, Olivier Hainque wrote:
>
> Dear all,
>
> With the current evolution of the COVID-19 crisis worldwide, we are
> unfortunately not in a position to maintain the organization of this
> year’s GNU Tools Cauldron as originally planned
Hello,
Since April 14 or so, I am not receiving any more messages
from the gcc or gcc-patches mailing lists.
This turns out to coincide with the date I sent to multiple
lists the message announcing the unfortunate cancellation of
the 2020 GNU Tools Cauldron.
https://gcc.gnu.org/pipermail/gcc/2
Hi Frank,
> On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote:
>
> Hi -
>
>>> A re-subscription attempt to the gcc mailing list just
>>> failed, expectedly I guess.
>
> I see no sign in the logs of Olivier being banned in any form. Please
> resubscribe online and forward complete failure sympt
> On 23 Apr 2020, at 19:39, Jonathan Wakely wrote:
> Patch submitted for approval now:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html
Thanks Jonathan :)
Thanks Rasmus and Jonathan for your comments and suggestions.
> On 20 May 2020, at 12:07, Jonathan Wakely wrote:
>
> On Wed, 20 May 2020 at 09:44, Rasmus Villemoes
> wrote:
>>
>> Hi
>>
>> The condition variable implementation added in commit 806dd0472f56fd
>> seems to fall into the trap(s) p
Hi Rasmus,
> On 26 May 2020, at 16:52, Rasmus Villemoes wrote:
>
> Hi Olivier et al
>
> I'm having quite a bit of trouble getting gcc 10 to build for our
> vxworks 5 (5.5.1) target.
Thanks for your message.
VxWorks 5 was transitioned
to End Of Life long ago so we're not testing for it any mor
Hi Rasmus,
> On 26 May 2020, at 16:52, Rasmus Villemoes wrote:
>
> Hi Olivier et al
>
> I'm having quite a bit of trouble getting gcc 10 to build for our
> vxworks 5 (5.5.1) target. The first thing I hit is
>
> #if !defined(_WRS_VXWORKS_MAJOR)
> #error "VxWorks version macros needed but not de
> On 26 May 2020, at 16:52, Rasmus Villemoes wrote:
>
> _VXW_PRE_69 was introduced in 806dd0472f, then replaced by
> _VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed.
>
> Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks)
> ---
> libgcc/config/gthr-vxworks.h | 2 +
Hi Rasmus,
> On 04 Jun 2020, at 15:31, Rasmus Villemoes wrote:
>
>> Unfortunately, no, not really: while we don't break it
>> intentionally, it was transitioned to End Of Life a couple
>> of years a ago and we don't test on such configurations
>> any more.
>>
>> We are gradually going to a simi
> On Sep 26, 2016, at 14:15 , Ramana Radhakrishnan
> wrote:
>
> I am pleased to announce that the GCC Steering Committee has
> appointed Oliver Hainque as co-maintainer for the VxWorks port.
>
> Please join me in congratulating Oliver on his new role.
>
> Oliver, please update your listing in
Hello,
Here is a quick description of changes we would like to contribute to the
VxWorks ports, with a preliminary query to maintainers on what would be the
most appropriate form for such changes to be deemed acceptable:
On a few CPU families, variants of the VxWorks OS are available.
Typically
On May 19, 2014, at 15:41 , Olivier Hainque wrote:
> For vxsim or smp, having entirely separate toolchains with different triplets
> for so minor differences seemed overkill and impractical for users, so we have
> added "-vxsim" and "-vxsmp" command line opti
On Oct 3, 2014, at 06:15 , Jan Hubicka wrote:
>> I'm bisecting it (on powerpc64-linux, where it also shows up); it needs
>> full bootstrapping every time, so will be another one to two hours.
>>
>> I just hope it isn't mine, that's going to be "fun" to debug :-)
>
> Nono, it is mine - the devir
Hello Jakub,
On Nov 3, 2014, at 10:18 , Jakub Jelinek wrote:
> The trunk is scheduled to transition from Stage 1 to Stage 3 at the end
> of Saturday, November 15th (use your timezone to your advantage)
...
> What larger merges are still planned for GCC 5?
> What else have been people working
> o
Hi Segher,
> On Feb 14, 2017, at 04:07 , Segher Boessenkool
> wrote:
>
> Hi all,
>
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SP
Hi David,
> On Feb 17, 2017, at 01:10 , David Edelsohn wrote:
>
> This is not a new issue. The maintainer did not suddenly resign last
> week. There have been numerous efforts to reach out to the SPE
> community for over a *decade*, cajoling them to step up with
> maintenance for the port. I
> On 21 Feb 2017, at 17:14, David Edelsohn wrote:
>
> Hi, Olivier
>
> There are three main areas that require attention:
>
> 1) Regular builds of the SPE configuration and regular GCC testsuite
> runs that are reported to the gcc-testsuite mailing list.
>
> 2) Timely reports of any regression
Hello Andrew,
> On Mar 13, 2017, at 19:01 , Andrew Jenner wrote:
>
> I volunteer to be the point of contact for the SPE port.
>
> Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE
> *not* being deprecated (we actively ship toolchain products with SPE
> multilibs, and
> On Mar 15, 2017, at 15:26 , Segher Boessenkool
> wrote:
> I do not think VLE can get in, not in its current shape at least. VLE
> is very unlike PowerPC in many ways so it comes at a very big cost to
> the port (maintenance and otherwise -- maintenance is what I care about
> most).
>
> Sinc
Hello,
A question on the stack/frame_tie circuitry for a ppc/V4_abi target, to
check about a potential remaining latent problem in this area.
With gcc 4.3, we had a case where the prologue generation emitted
a sequence like
(insn 191 190 192 9 t.adb:30:8 (set (reg:SI 25 25)
(mem/c:SI (pl
Olivier Hainque wrote:
> do we still have a latent problem in this case ?
I believe we do. Here is a C testcase recreating one problematic
situation artificially
char mysym;
char * volatile g;
void foo (long x)
{
char volatile s [x];
register c
Hi Joel,
Joel Sherrill wrote:
> I can't seem to find the patch. Do you have a link?
The initial submission, with a description of the problem we were
having, is at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00759.html
We have been using a slightly adjusted version for our gcc 4.3 based
lin
Michael Eager wrote:
> I'll reverse-engineer the table unless I can find something
> more descriptive than the comments in gcc or gdb.
FWIW, I did a similar exercise long ago and synthesized my
understanding in ada/raise-gcc.c, where the Ada personality routine
is implemented.
Olivier
Working on a collect2 related patch resubmission for ppc-aix, I
stumbled on regressions in the c++ series for a problem unrelated to
my change. Not sure how you'd typically deal with these, so providing
the datapoints here.
tmpdir-g++.dg-struct-layout-1/t027 and a couple of other tests failed
from
Hello Paolo,
It seems to me that this piece of your r149032 change ...
* expr.c (expand_expr_real_1): Just use do_store_flag.
--- expr.c (revision 149031)
+++ expr.c (revision 149032)
@@ -9109,50 +9109,9 @@
temp = do_store_flag (exp,
modifier
Paolo Bonzini wrote:
> I'm reverting the expand_expr_real_1 part (the part that introduced the
> assertion).
I see, thanks for your prompt feedback,
Olivier
David Edelsohn wrote:
> > .csect .data[RW],4
> > ^^^
> > .align 6
> > ^^^
> > a2661:
> > .space 10240
>
> The default alignment of CSECTs is 4, but using -fdata-sections should
> place the object in its own CSECT with stricter alignment.
H
Hello Luke,
Luke A. Guest wrote:
> I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM.
Thanks :-)
> Any pointers would be gratefully received. I'm fairly sure I know where
> to start.
A few general points, jic.
The first thing will be to adjust your target system.ads to
Luke A. Guest wrote:
> Well, I'm reading as much as I can regarding this, but finding it hard
> to work some things out.
That's a pretty complex and very precise machinery overall.
> I've been reading through:
> http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example
> code in C+
[resending a reply sent to a private copy]
From: Olivier Hainque
To: "Luke A. Guest"
Subject: Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Date: Mon, 27 Sep 2010 15:18:59 +0200
Luke A. Guest wrote:
> > A quick glance suggests that your arm-linux port might be using the
>
Hello Luke,
Luke A. Guest wrote:
> Can anyone give me a pointer here? I'm totally new to this :/
> a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a
> predefined library unit
> a-exexpr.adb:39:06: "Ada.Exceptions (body)" depends on
> "Ada.Exceptions.Exception_Propagation (body)"
Hello Ioannis;
Ioannis E. Venetis wrote:
> > Would __builtin_stack_size (F) retrieve information about F's stack frame
> > only, or would it also recursively account for every other function that
> > F may call ?
> >
> > Implementing the former is probably possible, though I'm not sure
> > exactl
Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> acats test cxg2014 hangs forever on hppa2.0w-hp-hpux11.00.
> ,.,. CXG2014 ACATS 2.5 06-02-10 18:02:32
> - CXG2014 Check the accuracy of the SINH and COSH functions.
>* CXG2014 sinh(1) actual: 7.49632E
Rainer wrote:
> The patch proposed by Olivier applied to 4.1 gives 0 failures for the whole
> acats testsuite,
John David wrote:
> While not quite as good as your 4.1.0 results, I had a similar improvement
> on 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00815.html
Many thanks to bo
Mark Mitchell wrote:
> > Mark, is it ok for Olivier to apply the patch mentioned here on
> > 4.1?
> Yes, thanks.
I have been away for a couple of days and see that the patch has been
committed to the various branches. Thanks :)
Hello,
Working on an arm-vxworks port for Ada, we noticed that both
NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL are defined, the former from
config/vxworks.h and the latter from arm/aout.h.
Is it really intended this way ?
NO_DOT_IN_LABEL is actually #undef'ed from config/vxworks.h, but the
arm/aout.
Hello all,
>From a call like
categorize_ctor_elements (ctor, &num_nonzero_elements,
&num_nonconstant_elements,
is 'num_nonconstant_elements == 0' expected to convey the same as
initializer_constant_valid_p (ctor, TREE_TYPE (ctor)) ?
The code in gimplify
Hello,
First a short description of a problem we are seeing, then a couple
of related questions on addressability checks in the gimplifier.
>From a simple Ada testcase which I can provide if need be, the front-end
is producing a MODIFY_EXPR with a lhs of the following shape when we get
to gimplif
or your help,
With Kind Regards,
Olivier
2006-06-19 Olivier Hainque <[EMAIL PROTECTED]>
* tree-gimple.c (is_gimple_lvalue, is_gimple_addressable): Account for
possibly nested bitfield component refs, not addressable while still
valid lvalues.
*** tree-gimple.c.
Hello,
To address
/* The AIX linker will discard static constructors in object files if
nothing else in the file is referenced [...] */
collect2 on AIX builds the ctor/dtor tables from an explicit scan of
all the objects and libraries.
The scan actually also considers frame tables, so we
Ian Lance Taylor wrote:
> Why do you need the double scan? Why can't you just consistently
> ignore the frame tables?
Because we need the tables associated with every "useful" object to be
registered for exception handling to work, and what is registered is
currently what collect2 finds while
Mike Stump wrote:
> On Sep 26, 2006, at 2:36 AM, Olivier Hainque wrote:
> > /* The AIX linker will discard static constructors in object files
> > if nothing else in the file is referenced [...] */
> Darwin has this same sort of issue and solves it by not wiring up
>
On Jul 17, 2012, at 17:34 , Alan Modra wrote:
> The ICE is
>
> combine.c:5318:1: error: insn does not satisfy its constraints:
> (insn 4211 1484 1493 140 (set (mem/c:DI (plus:SI (reg/f:SI 19 19 [2736])
>(const_int 32760 [0x7ff8])) [3 __gcov0.subst+816 S8 A64])
>(reg:DI 6 6
On Aug 1, 2012, at 13:18 , Alan Modra wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
> I like the idea.
:-)
> It is worth pursuing for code improvement we'll see
> even if we avoid the "o" constraint everywhere. For example,
> long long llo (long long *x) { return x
On Aug 1, 2012, at 16:04 , Ulrich Weigand wrote:
> I've been wondering about mode_dependent_address_p myself. It currently
> appears to cover two quite separate questions:
>
> - If I have a valid address, will it remain valid if I change its mode to
> something else?
>
> - If I have a valid ad
Richard Guenther wrote:
> I am mostly interested in the Ada <-> middle-end interaction, specially
> where Adas requirements on the middle-end exceed that of C, and how this
> is currently handled. [...]
Thanks. There is indeed a lot to say/discuss on that ground and we'd
certainly be very happy
Hello,
(Having a great time in Ottawa :)
move_invariant_reg has this code:
/* Replace the uses we know to be dominated. It saves work for copy
propagation, and also it is necessary so that dependent invariants
are computed right. */
if (inv->def)
{
Olivier Hainque wrote:
> move_invariant_reg has this code:
>
> /* Replace the uses we know to be dominated.
> and we're observing a case where this updates only one of two
> match_dup related operands. This is on i386-mingwin [...]
This is causing nasty miscompilation
Joel Brobecker wrote:
> > If you care about GDB on mips-irix, I strongly advise caring about GCC as
> > well, or finding someone to care about it. Right now, it is on the list
> > of targets to be deprecated in GCC 4.4 because we wish to remove fixproto
> > and it is one of the few targets stil
Hello,
According to comments in PR/35493, when DECL_INITIAL is null on a
TREE_READONLY decl, the middle-end may assume the value to be zero.
This is not explicit from the current definitions in tree.h, we'd
like to understand if this is actually the case and to suggest a doc
extension to this eff
Olivier Hainque wrote:
[...]
While we're at it, it would be nice to settle similar notions
about TREE_CONSTANT. There was an exchange along similar lines at
http://gcc.gnu.org/ml/gcc/2005-08/msg00686.html
Richard Guenther wrote:
> A doc extension is ok.
Understood, as soon as we agree on what it should say :)
> > We'd also like to get to an agreement on what TREE_READONLY means on a
> > decl with non static storage, if anything at all.
>
> Good question...
> > Ada front-end sets TREE_RO and D
Richard Guenther wrote:
> > Don't set TREE_RO on the decl if !TREE_STATIC, in gigi (we might
> > decide it doesn't make sense and document accordingly).
>
> That would work.
Both doing the thing in gigi and deciding that TREE_RO only makes
sense if TREE_STATIC as well ?
(I have no strong
Hi Richard,
Still looking into this issue.
Our current understanding is that our initial bug was indirectly
caused by the Ada front-end setting TREE_STATIC on a DECL_EXTERNAL
constant, which it shouldn't do.
The straightforward fix to that uncovered corner issues with the
way we set DECL_CONTEXT
Hello,
genmodes.c uses the %n capabilities of printf to compute the width of
pieces it outputs. This causes troubles on Windows Vista, because ...
<< Because of security reasons, support for the %n format specifier is
disabled by default in printf and all its variants. ... the default
Ian Lance Taylor wrote:
> What is the security issue here? I'm not seeing it. Are they
> concerned that attackers will modify the print control string somehow?
I don't know. We simply have observed bootstrap problems during
preliminary experiments on Vista, found them to be caused by
uninitia
Paolo Bonzini wrote:
> * genmodes.c (tagged_printf, emit_insn_modes_h): Don't
> use %n on printf.
Almost identical to what we have been doing internally to circumvent
the issue, Thanks.
Olivier
Hello,
As part of our Ada front-end maintainership, we (AdaCore) would like
to introduce a subdirectory of 'ada' where we would relocate all the
files implementing the Ada-front-end/GCC interface (the "gigi" sources
for the internal GNAT/GCC tree interfacing, plus the build
infrastructure bits: Ma
Hello Joseph,
Joseph S. Myers wrote:
> If moving files, I'd encourage moving the sources built from the libada/
> and gnattools/ toplevel directories to be physically located in those
> directories (or subdirectories of them) as far as possible, as one step in
> the rearrangement.
> I don't ho
Hello Paolo,
Paolo Bonzini wrote:
> Would it be possible to add a --enable-small option to libada, which
> would enable compilation of the subset used by GNAT? Then, one could
> make libada build twice: as a host module with --enable-small, and as a
> target module without the option.
Humm,
Paolo Bonzini wrote:
> > It would seem to me that if everything was moved to libada, this
> > would not be necessary anymore.
> Sorry, I wanted to write "everything related to the Ada RTS".
Oh, I see.
> Of course Gigi is not going to be moved into libada.
Right :-)
And even if "everything r
Hi Rasmus,
> On 7 Dec 2021, at 16:09, Rasmus Villemoes wrote:
>
> Hi Olivier
>
> One thing I've been meaning to ask: Is there a reason VX_CRTBEGIN_SPEC
> and VX_CRTEND_SPEC are given as
>
> #define VX_CRTBEGIN_SPEC "vx_crtbegin.o%s"
> #define VX_CRTEND_SPEC "-l:vx_crtend.o"
>
> so for vx_crtb
93 matches
Mail list logo
