On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build with the system gcc, I'd think we want
the just-built gnat1 to find the system libgcc.
In stage 2, when we build with the stage 1 gcc, we want the just-built
gnat1 to find the stage 1 libgcc.
In neither case do we want
Il 20/08/2013 15:58, Tom Tromey ha scritto:
> This changes the handling of SHLIB so that it is inlined into
> DRIVER_DEFINES. This is ok because SHLIB is defined in a Makefile
> fragment that is included by the generated Makefile.
>
> The rationale for this is that it simplifies some .o targets,
Il 16/09/2013 16:39, Tom Tromey ha scritto:
> Richard> Where's that automatic dependency patch blocked ...
>
> No build machinery maintainer has reviewed it.
/me gets out of coma...
Someone said "automatic dependency" and "build machinery maintainer" in
the same sentence???
Paolo
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is an order-only dependency in gcc/Makefile.in that tries to
> build the generated files before compiling regular objects. However,
> this appears too early, and so at the time it is seen by make,
> GCOV_OBJS and GCOV_DUMP_OBJS have not yet been
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This adds the configury needed for automatic dependency tracking. It
> also adds some bits to the Makefile so we can begin converting
> (removing) explicit dependencies.
>
> * Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
> (COMPI
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This removes manual dependencies for the c-family .o files.
>
> * Makefile.in (c-family/cppspec.o, c-family/c-common.o)
> (c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o)
> (c-family/c-gimplify.o, c-family/c-lex.o, c-
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This converts LTO.
>
> This also fixes a latent buglet in lto/Make-lang.in. lto_OBJS should
> hold all the objects for a language, but LTO never defined this.
>
> * Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H)
> (lto/lto-lang.o,
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This removes most of the explicit dependencies for host objects.
> It also fixes a few rules to use $(COMPILE) in the process.
>
> build objects are not affected, and are one reason that the various _H
> macros are not yet removed.
>
> * Makefil
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This is a small change to make out_object_file use automatic
> dependencies.
>
> * Makefile.in ($(out_object_file)): Use COMPILE and POSTCOMPILE.
> ---
> gcc/Makefile.in | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> d
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is a single reference to TREE_GIMPLE_H in the source tree.
> Since it is not defined anywhere, we might as well remove the use.
>
> * config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H.
> ---
> gcc/config/i386/t-i386 | 2 +-
> 1 file cha
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is a single definition of CROSS_FLOAT_H in the source.
> As far as I can tell, this is never used anywhere.
> So, this patch removes it.
>
> * config/mcore/t-mcore (CROSS_FLOAT_H): Remove.
> ---
> gcc/config/mcore/t-mcore | 3 ---
> 1 file
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> I used this perl script to find unused _H macros in the Makefile. I
> deleted the definitions it reported and re-ran the script, until there
> was no more output.
>
> The script also makes note of _H variables which are used but never
> defined. That
Il 26/08/2013 18:09, Tom Tromey ha scritto:
>> "Ian" == Ian Lance Taylor writes:
>
> Ian> I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
> Ian> at the new definition of $(COMPILE).
>
> I believe the depcomp script takes care of this.
I think that would be the "compile"
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> A few generated files were not mentioned in the generated_files
> variable. This fixes the problem.
>
> * Makefile.in (generated_files): Add options.h,
> target-hooks-def.h, insn-opinit.h,
> common/common-target-hooks-def.h, pass-ins
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This converts the C front end.
>
> Note that this fixes a latent bug in gcc/Makefile.in's definition of
> C_TREE_H. This is needed to avoid breaking this build with this
> patch.
>
> * Makefile.in (C_TREE_H): Reference c/c-tree.h.
>
> *
Il 16/09/2013 19:23, Tom Tromey ha scritto:
> Tom> I can try a test build using a setting for CC that rejects -c -o.
>
> I did this and the build died pretty early on:
>
> /home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I.
> -I../../gcc/libiberty/../include -W -Wall -Wwrite-s
Il 16/09/2013 22:58, Tom Tromey ha scritto:
> Paolo> The series looks okay to me with that change.
>
> Two last questions while I'm testing my rebase --
>
> First, do you mind if I resend the whole series? Otherwise I can try to
> pick out just the patches that have changed, plus the additional
Il 25/09/2013 06:37, Alexandre Oliva ha scritto:
> On Sep 23, 2013, Tom Tromey wrote:
>
>> First, I believe I've addressed all of the comments in Paolo's review.
>
> That's my feeling as well. Sorry that I didn't manage to go through
> earlier versions of the patch before; I've just reviewed v4
Il 27/09/2013 21:45, Gerald Pfeifer ha scritto:
> I believe this may be breaking all my testers on FreeBSD
> (i386-unknown-freebsd10.0 for example). The timing of when this
> patchset went in fits pretty much when my builds started to break
> and I am wondering about some code.
>
> Here is the f
Il 02/10/2013 12:39, Rainer Orth ha scritto:
> Inspired by the t-i386 changes, the following patch moves SPARC and
> Solaris files over to automatic dependencies.
>
> Bootstrapped without regression on sparc-sun-solaris2.11, verified that
> dependencies were generated for affected files.
>
> Ok f
Il 28/09/2012 00:57, Vladimir Makarov ha scritto:
> LRA creates a lot of new pseudos. So the following patch implements
> ahead allocation reg info information which is important for LRA
> compilation speed.
>
> 2012-09-27 Vladimir Makarov
>
> * reginfo.c (max_regno_since_last_resize): Ne
Il 03/08/2012 17:08, Richard Henderson ha scritto:
> On 2012-08-03 08:01, Uros Bizjak wrote:
>> On Fri, Aug 3, 2012 at 4:40 PM, Richard Henderson wrote:
>>> On 2012-08-03 01:51, Uros Bizjak wrote:
The same reasoning goes for dynamic negation: for neg %eax,%eax value
0x8000 stays the
Il 02/10/2012 09:28, Steven Bosscher ha scritto:
>> My experience shows that these lists are usually 1-2 elements. Although in
>> > this case, there are pseudos with huge number elements (hundreeds). I
>> > tried
>> > -fweb for this tests because it can decrease the number elements but GCC (I
>
Il 02/10/2012 10:49, Steven Bosscher ha scritto:
> On Tue, Oct 2, 2012 at 10:29 AM, Paolo Bonzini wrote:
>> Il 02/10/2012 09:28, Steven Bosscher ha scritto:
>>>> My experience shows that these lists are usually 1-2 elements. Although
>>>> in
>>>>&g
Il 30/09/2012 11:02, Richard Sandiford ha scritto:
> Uros Bizjak writes:
>> On Thu, Sep 27, 2012 at 8:20 PM, Jakub Jelinek wrote:
>>> On Thu, Sep 27, 2012 at 08:04:58PM +0200, Uros Bizjak wrote:
After some off-line discussion with Richard, attached is v2 of the patch.
2012-09-27 U
Il 07/10/2012 19:18, Steven Bosscher ha scritto:
> Hello,
>
> The attached patch adds a DF changeable flag to compute a subset of
> reaching definitions that are also live at the program points they
> reach. This is an idea I discussed with Paolo many years ago already,
> but until today it hadn't
Il 13/10/2012 00:25, Steven Bosscher ha scritto:
> On Fri, Oct 12, 2012 at 11:16 PM, Jan Hubicka wrote:
>>> On Fri, Oct 12, 2012 at 10:44 PM, Jan Hubicka wrote:
1) computing liveness with REG_EQUAL included prior RD that means a lot
of shuffling of REG_DEAD notes
>>>
>>> I was alre
Il 15/10/2012 07:10, Joern Rennecke ha scritto:
> 2012-10-02 Joern Rennecke
>
> * web.c (union_match_dups): Properly handle OP_INOUT match_dups.
>
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00189.html
>
Ok.
Paolo
Il 14/10/2012 22:59, Steven Bosscher ha scritto:
> On Sun, Oct 14, 2012 at 9:02 AM, Paolo Bonzini wrote:
>> Can we just simulate liveness for web, and drop REG_EQUAL/REG_EQUIV
>> notes that refer to a dead pseudo?
>
> I don't think we want to do that. A REG_EQUAL/REG_EQU
Il 15/10/2012 10:13, Steven Bosscher ha scritto:
> > I disagree that it is valid. At least it is risky to consider it valid,
> > because a pass that simulates liveness might end up doing something
> > wrong because of that note. If simulation is done backwards, it doesn't
> > even require any int
Il 15/10/2012 10:37, Steven Bosscher ha scritto:
>> I prefer to declare the notes invalid and drop the notes.
> Then, afaic, our only option is to drop them all in web, as per attached
> patch.
>
> I strongly disagree with this approach though. It destroys information
> that is correct, that we ha
Il 15/10/2012 14:53, Steven Bosscher ha scritto:
> I think I've shown above that we're all looking at the wrong pass...
I think you have... so we want a patch like this?
Index: df-problems.c
===
--- df-problems.c (revisione 183
Il 16/10/2012 12:35, Steven Bosscher ha scritto:
> On Tue, Oct 16, 2012 at 12:15 PM, Steven Bosscher wrote:
>> On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
>>> On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
>>>> Il 15/10/2012 14:53, Steven Bosscher
Il 19/10/2012 19:01, Eric Botcazou ha scritto:
> PR bootstrap/54820 (stage #1 bootstrap failure)
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01093.html
This one is okay, thanks.
Paolo
Il 15/10/2013 00:28, Gerald Pfeifer ha scritto:
> - The problem is not actually the set of flags being used. On a
>different tester clang is the bootstrap compiler, and this is
>also the one invoked for `gmake install`. If anything, shouldn't
>the just built compiler be used _if_ an
Il 24/10/2013 03:17, Tom Tromey ha scritto:
> Jan-Benedict> I'd like to get some comments on this patch, which works
> Jan-Benedict> for me for stage-1 builds with gcc/g++ (on a amd64-linux
> Jan-Benedict> box) as well as with xlC/g++ on gcc111 (the mentioned AIX
> Jan-Benedict> machine):
>
> FW
Il 18/09/2013 11:45, Zhenqiang Chen ha scritto:
> +;; Expand conditional compare according to the instruction patterns.
> +(define_expand "conditional_compare"
> + [(set (match_operand 0 "s_register_operand" "")
> + (match_operator 1 ""
> + [(match_operator:SI 2 "arm_comparison_operator"
Il 30/10/2013 16:47, Jason Merrill ha scritto:
> I find -Wformat warnings about unknown % codes when building with an
> older GCC to be mildly annoying noise; this patch avoids them by passing
> -Wno-format during stage 1.
>
> Tested x86_64-pc-linux-gnu. Is this OK for trunk?
Ok.
Il 02/12/2013 20:34, Richard Sandiford ha scritto:
>>> >> I followed Joseph's suggestion and reused longlong.h. I copied it from
>>> >> libgcc rather than glibc since it seemed better for GCC to have a single
>>> >> version across both gcc/ and libgcc/. I can put it in include/ if that
>>> >> see
Il 06/12/2013 01:56, Tom de Vries ha scritto:
>>
>>
>> This patch series adds analysis of register usage of functions for
>> usage by IRA.
>> The original post is here
>> ( http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01234.html ).
>>
>> This patch uses the information of which registers are clobbe
Il 09/12/2013 11:46, Gerald Pfeifer ha scritto:
> Hmm, it looks like this has not been approved/applied, but I also
> have not seen any NACK.
>
> This does address an annoying (and hard for novices to understand)
> roadblock for someone installing GCC manually. Can this go in?
I'm not sure why t
Il 09/12/2013 12:08, Gerald Pfeifer ha scritto:
> On Mon, 9 Dec 2013, FX wrote:
>> > Look at this as a diagnostics bug: our current diagnostics for this
>> > pretty common situation sucks. It comes late in the compilation, and
>> > the message itself isn’t helpful.
> Totally seconded.
>
> Paolo,
From: bonz...@gnu.org
In this PR, a lot of time is spent doing the same ipa_load_from_parm_agg
query over and over. Luckily a memoization scheme is already there, it's
just not used by ipa-inline-analysis.c. The patch moves the cache struct
(struct func_body_info) to ipa-prop.h and modify ipa-in
On 13/07/2015 13:55, Martin Jambor wrote:
> I can't approve it, but FWIW, I'm generally fine with the patch.
> Although the original idea was to share one func_body_info in between
> ipa-cp and ipa-inline analyses, this is certainly better than what we
> have now and perhaps even good enough gene
On 13/07/2015 14:34, Martin Jambor wrote:
> You might want to use Martin's shiny new
> function_summary class in symbol-summary.c. That is a mechanism
> specifically designed to append to a cgraph_node information specific
> to an optimization pass (or two, as ipa-cp and ipa-inline already both
On 13/07/2015 15:45, Richard Biener wrote:
> It would be nice to have a patch that can be backported to the GCC 5 branch
> as well. We can improve this on trunk as followup,no?
The patch I've already posted can be backported. O:-)
Paolo
On 15/07/2015 18:01, Martin Jambor wrote:
> > So unless Martin objects consider the patch approved for trunk and for
> > backporting after 5.2 is released and trunk shows no issues.
> >
> > Martin - can you take care of committing if you are fine with it?
>
> I have commitred the patch to trunk
On 08/10/2015 06:59, Richard Henderson wrote:
> +/* Address space support.
> +
> + This is not "far pointers" in the 16-bit sense, but an easy way
> + to use %fs and %gs segment prefixes. Therefore:
> +
> +(a) All address spaces have the same modes,
> +(b) All address spaces have the
On 05/11/2015 17:28, David Edelsohn wrote:
> [Explicitly copying build maintainers.]
>
> Paolo and Alexandre,
>
> Could you review and help with this patch?
>
> TLS symbols in AIX display a new, different symbol type in nm output.
> Libtool explicitly creates a list of exported symbols for sha
On 05/11/2015 17:38, David Edelsohn wrote:
> On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini wrote:
>>
>>
>> On 05/11/2015 17:28, David Edelsohn wrote:
>>> [Explicitly copying build maintainers.]
>>>
>>> Paolo and Alexandre,
>>>
>>&
GCC's -fwrapv option does not affect code generation for shifts
because currently GCC does not rely on the fact that certain
signed shifts trigger undefined behavior. However, the definition
of signed arithmetic overflow does extend to shifts; it is only
code generation that is limited to addition
On 17/11/2015 13:58, Joseph Myers wrote:
>> > GCC's -fwrapv option does not affect code generation for shifts
>> > because currently GCC does not rely on the fact that certain
>> > signed shifts trigger undefined behavior. However, the definition
>> > of signed arithmetic overflow does extend to
Left shifts into the sign bit is a kind of overflow, and the
standard chooses to treat left shifts of negative values the
same way.
However, the -fwrapv option modifies the language to one where
integers are defined as two's complement---which also defines
entirely the behavior of shifts. Disable
On 17/11/2015 16:27, Joseph Myers wrote:
> > Can you suggest a wording for "if the GNU C language definition changes
> > [which, no matter how unlikely, is explicitly not ruled out by the
> > manual] -fwrapv will be extended to signed shifts, and shifts of
> > negative numbers would return A*2^B
On 17/11/2015 17:02, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Paolo Bonzini wrote:
>
>> * it doesn't promise that GCC will never rely on undefined behavior
>> rules for signed left shifts
>
> I think we should remove the ", but this is subject to cha
On 17/11/2015 17:02, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Paolo Bonzini wrote:
>
>> * it doesn't promise that GCC will never rely on undefined behavior
>> rules for signed left shifts
>
> I think we should remove the ", but this is subject to cha
On 20/11/2015 14:14, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote:
>>
>> Status
>> ==
>>
>> We plan to do a GCC 5.3 release candidate at the end of next week
>> followed by the actual release a week after that.
>>
>> So now is the time to look at your regress
Eric, can you help committing this patch to libtool?
http://article.gmane.org/gmane.comp.gcc.patches/356566
Thanks,
Paolo
On 03/11/2015 15:23, David Edelsohn wrote:
> TLS symbols in AIX display a new, different symbol type in nm output.
> Libtool explicitly creates a list of exported symbols fo
GCC's -fwrapv option does not affect code generation for shifts
because currently GCC does not rely on the fact that certain
signed shifts trigger undefined behavior. However, the definition
of signed arithmetic overflow does extend to shifts; it is only
code generation that is limited to addition
Left shifts into the sign bit is a kind of overflow, and the
standard chooses to treat left shifts of negative values the
same way.
However, the -fwrapv option modifies the language to one where
integers are defined as two's complement---which also defines
entirely the behavior of shifts. Disable
On 24/11/2015 16:57, David Edelsohn wrote:
> > > We plan to do a GCC 5.3 release candidate at the end of next week
> > > followed by the actual release a week after that.
> > >
> > > So now is the time to look at your regression bugs in bugzilla and
> > > do some backporting for things already fi
maybe_warn_shift_overflow is checking for patterns such as (1 << 31)
and not warning for them.
However, if the shifted value is negative, a shift by a non-zero
amount will always shift *out* of the sign bit rather than into it.
Thus it should be warned about, even if the value only requires
one bi
On 25/11/2015 14:55, Paolo Bonzini wrote:
> Left shifts into the sign bit is a kind of overflow, and the
> standard chooses to treat left shifts of negative values the
> same way.
>
> However, the -fwrapv option modifies the language to one where
> integers are defined a
> >> gcc:
> >>PR sanitizer/68418
> >>* c-family/c-ubsan.c (ubsan_instrument_shift): Disable
> >>sanitization of left shifts for wrapping signed types as well.
> >>
> >> gcc/testsuite:
> >>PR sanitizer/68418
> >>* gcc.dg/ubsan/c99-wrapv-shift-1.c,
> >>gcc.dg/ubsan/c99-wrapv-
On 04/12/2015 23:48, Jeff Law wrote:
>>
>> Why would pointer types be shifted at all (at the ubsan level,
>> which is basically the AST)?
> BTW, if you argument is that we can never get into this code with a
> shift of a pointer object, I'd like to see some kind of analysis to back
> up that asse
Left shifts into the sign bit is a kind of overflow, and the
standard chooses to treat left shifts of negative values the
same way.
However, the -fwrapv option modifies the language to one where
integers are defined as two's complement---which also defines
entirely the behavior of shifts. Disable
which I considered but did not implement is to mark
the UNPOISON calls so that they do not cause the parameter to escape.
Any suggestions on how to proceed here (or approval is welcome too :))?
Paolo
2018-02-09 Paolo Bonzini
* passes.def: add pass_sandce before first DSE pass
On 09/02/2018 17:40, Richard Biener wrote:
> On February 9, 2018 5:08:24 PM GMT+01:00, Paolo Bonzini
> wrote:
>> Another possibility which I considered but did not implement is to mark
>> the UNPOISON calls so that they do not cause the parameter to escape.
>
> I'
On 12/02/2018 09:56, Richard Biener wrote:
>>> I think it does, for both ASAN_CHECK and ASAN_MARK the pointer argument
>>> is the second one, the first one is an integer argument with flags.
>>> And ASAN_MARK, both poison and unpoison, works kind like a clobber on
>>> the
>>> referenced variable, b
On 09/02/2018 19:07, Jakub Jelinek wrote:
> On Fri, Feb 09, 2018 at 07:01:08PM +0100, Richard Biener wrote:
>>> which indeed fixes the testcase and seems not to break asan.exp.
>>
>> Huh. Need to double check why that makes sense ;)
>
> I think it does, for both ASAN_CHECK and ASAN_MARK the point
On 13/02/2018 10:32, Martin Liška wrote:
> Hello.
>
> It caused PR84340, I'm suggesting following fix:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340#c3
I don't think EAF_DIRECT is the issue. You could think of ASAN_MARK as
writing a global variable, which it can do because it's not const.
On 13/02/2018 00:49, Jakub Jelinek wrote:
> On Tue, Feb 13, 2018 at 12:41:28AM +0100, Paolo Bonzini wrote:
>> On 09/02/2018 19:07, Jakub Jelinek wrote:
>>> On Fri, Feb 09, 2018 at 07:01:08PM +0100, Richard Biener wrote:
>>>>> which indeed fixes the testcas
On 13/02/2018 14:00, Jakub Jelinek wrote:
>> Certainly, for now I'll revert.
> Reversion is not the right thing, the "fn spec" attributes were clearly
> incorrect. So, we should change them to something more conservative that
> will work.
That would only be "all dots", that is no fnspec at all. M
On 13/02/2018 14:35, Jakub Jelinek wrote:
> On Tue, Feb 13, 2018 at 12:21:55PM +0100, Jakub Jelinek wrote:
>> On Tue, Feb 13, 2018 at 12:15:36PM +0100, Paolo Bonzini wrote:
>>> The issue is that the ASAN_CHECK doesn't exist at early DSE time, and
>>> thus causes the
Il 08/11/2013 10:37, Richard Biener ha scritto:
> /* If we have a gate, combine the properties that we could have with
> and without the pass being examined. */
> if (pass->has_gate)
> properties &= new_properties;
> else
> properties = new_properties;
>
Il 06/11/2013 19:33, Joseph S. Myers ha scritto:
> +dnl GCC_GLIBC_VERSION_GTE_IFELSE(MAJOR, MINOR, IF-TRUE, IF-FALSE)
> +dnl -
> +dnl If the target glibc version ($glibc_version_major.$glibc_version_minor)
> +dnl is at least MAJOR.MINOR, c
Il 14/11/2013 15:08, Rainer Orth ha scritto:
> libcilkrts.so fails to link on Solaris 9/x86 with Sun as since this
> configuration lacks visibility support:
>
> Text relocation remains referenced
> against symbol offset in file
> __cilkrts_get_tls_
Il 13/11/2013 15:06, Rainer Orth ha scritto:
>
> This happens because there's no installed amd64 libgcc_s.so.1 on the
> system, and toplevel Makefile only sets LD_LIBRARY_PATH for the default
> multilib. Initially, I thought that there were something special going
> on, but it turned out that oth
Il 18/11/2013 20:09, Jan Hubicka ha scritto:
>>> > > this patch switches the default for fat-lto-objects as was documented
>>> > > for a while.
>>> > > -ffat-lto-objects doubles compilation time and often makes users to not
>>> > > notice that
>>> > > LTO was not used at all (because they forgot
Il 19/11/2013 11:05, Markus Trippelsdorf ha scritto:
> On 2013.11.19 at 09:44 +0100, Paolo Bonzini wrote:
>> Il 18/11/2013 20:09, Jan Hubicka ha scritto:
>>>>>>> this patch switches the default for fat-lto-objects as was documented
>>>>>>
Il 19/11/2013 12:19, Markus Trippelsdorf ha scritto:
>> >
>>> > > So, maybe it is just time to upgrade libtool everywhere in gnu-land?
>> >
>> > Yes, that would be better but no need to do that now.
> So would Patches 1 and 2 be OK in the interim?
Yes. And Jan's answer suggests that patch 3 is
> (Once -fuse-linker-plugin is made the default, -ffat-lto-objects in
> config/bootstrap-lto.mk could be dropped.)
>
> LTO-Bootstrapped on x86_64-linux (with default -fuse-linker-plugin).
> The patch was already approved by Paolo Bonzini.
>
> Please apply, because I don't have
Il 22/11/2013 13:14, Rainer Orth ha scritto:
> I'm including the following in this weekend's bootstraps (Solaris and
> Linux).
>
> 2013-11-22 Rainer Orth
>
> * configure.ac (GCC_LIBSTDCXX_RAW_CXX_FLAGS): Remove.
> * configure: Regenerate.
>
Ok if it passes.
Paolo
Il 25/11/2013 16:45, Rainer Orth ha scritto:
> Uros prompted me to look into why we were still getting warnings
> compiling the soft-fp code in libgcc despite this in config/t-softfp:
>
> $(soft-fp-objects) : INTERNAL_CFLAGS += -Wno-missing-prototypes
> -Wno-type-limit
> s
>
> It turned out that
Il 30/09/2014 02:12, Ian Lance Taylor ha scritto:
> Similar to a recent patch to libgo, this patch to the libffi configure
> script checks whether the compiler support -Qunused-arguments. If it
> does, it passes -Qunused-arguments when invoking the compiler on .s
> files. This is because the clan
Il 26/06/2014 15:16, Rainer Orth ha scritto:
Hi Gerald,
sorry for the delay, I've been away for a couple of days.
On Tue, 3 Jun 2014, Rainer Orth wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
https://gcc.gnu.org/ml/gcc-patches/2014-0
On 09/06/2015 16:22, Michael Haubenwallner wrote:
> Hi build machinery maintainers,
>
> since we always build the C++ compiler now, I fail to see the need to still
> use RAW_CXX_TARGET_EXPORTS for libvtv.
>
> The situation to expose the problem is:
> * Use a multilib-enabled x86_64-linux box.
>
On 07/07/2015 11:08, Richard Biener wrote:
> Also I am not sure ceil_div and floor_div can be handled this way.
> (5 /[ceil] 2) * 2 == 6 but you compute it as 4. So I am only convinced
> trunc_div works this way.
Of course also floor_div for unsigned arguments.
For signed arguments, ceil_div w
On 03/02/2015 07:05, Andrew Pinski wrote:
> Likewise of:
> +(define_insn "abssi2"
> + [(set (match_operand:SI 0 "register_operand" "=r")
> + (abs:SI (match_operand:SI 1 "register_operand" "r")))
> + (clobber (match_scratch:SI 2 "=&r"))]
> + ""
> + "ashr.l\t%2,%1,31\;xor.l\t%0,%1,%2\;sub.l\t%
On 10/02/2015 22:46, Joseph Myers wrote:
> It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the
> choice of definition is a matter of what's convenient for the
> implementation (and which choice you make determines which existing code
> in GCC should be considered incorrect
On 10/24/2014 06:32 AM, Hans-Peter Nilsson wrote:
> It seems "more correct" to just disable the config.cache sharing
> between the differently-configured build-subdirectories, as is
> already is done for host-libraries and target-libraries, even if
> that may slow down the builds.
Yes, please do.
On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
> It would be nice to have libcc1 built just once, not bootstrap it, but
> it is a build module, is that possible?
> In toplevel configure.ac I'm seeing:
> host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
> gdb gprof etc
On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
> If this passes bootstrap/regtest, is it ok for trunk (should fix
> two bootstrap issues)? Is the
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
> patch ok too (that one already tested; another bootstrap issue)?
Both seem okay, though I'
On 10/29/2014 11:45 AM, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
>> On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
>>> shouldn't libcc1 be in build_tools instead?
>>> I mean, it is a library meant to be dlopened by gdb a
On 10/29/2014 11:51 AM, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote:
>>
>>
>> On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
>>> If this passes bootstrap/regtest, is it ok for trunk (should fix
>>> two bootstrap issu
On 10/29/2014 11:58 AM, Phil Muldoon wrote:
> My archaeology into the source repository has not revealed why
> we needed bootstrap. Perhaps we included it out of a sense of
> paranoia for testing. I've CC'd Tom on this, so he may have an
> opinion or insight. From my point of view, I see no valu
On 10/29/2014 11:59 AM, Jakub Jelinek wrote:
>> > Ah, got it. Is it hard to move the inclusion to the actual users?
> I think it is hard. I think it has been moved to system.h very much
> intentionally, as including gmp.h only in selected headers was causing lots
> of troubles, e.g. because of #p
On 10/29/2014 09:10 PM, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:45:51AM +0100, Jakub Jelinek wrote:
>> On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
>>> On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
>>>> shouldn't libcc1 be in build_
y
for both -pedantic (as before) and -Wextra.
Bootstrapped and regression tested x86_64-pc-linux-gnu, ok?
Paolo
libcpp:
2016-08-09 Paolo Bonzini
* include/cpplib.h (struct cpp_options): Add new member
warn_expansion_to_defined.
(CPP_W_EXPANSION_TO_DEFINED): New e
On 09/08/2016 20:30, Manuel López-Ibáñez wrote:
>>
>>
>> + cpp_opts->warn_expansion_to_defined = cpp_warn_expansion_to_defined;
>> + if (cpp_warn_expansion_to_defined == -1)
>> +cpp_warn_expansion_to_defined = pedantic || extra_warnings;
>> +
>
> Instead of the above, plase use LangEnabled
1 - 100 of 575 matches
Mail list logo
