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
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
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 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 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 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 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 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'
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 19/03/2017 22:17, Gunther Nikl wrote:
> Hello Paolo!
>
> Building older GCC releases with clang tends to issue warnings. This
> can be annoying especially when they originate from a header. While
> backporting r242743 I noticed that the non-C++ cases of the changed
> macro definitions in gcc/
On 09/12/2016 20:26, Jakub Jelinek wrote:
> +tree ctype = TREE_TYPE (@1);
> + }
> + (if (shift >= 0)
> +(bit_and
> + (convert (rshift @0 { build_int_cst (integer_type_node, shift); }))
> + @1)
> +(bit_and
> + (lshift (convert:ctype @0) { build_int_cst (integer_type_nod
On 30/11/2016 13:46, Segher Boessenkool wrote:
>if (JUMP_P (use_insn))
> continue;
>
> + /* Also don't substitute into a conditional trap insn -- it can become
> + an unconditional trap, and that is a flow control insn. */
> + if (GET_CODE (PATTERN (use_insn)) == T
mitted already.
Bootstrapped/regtested x86_64-pc-linux-gnu, ok?
Paolo
2016-11-26 Paolo Bonzini
* match.pd: Simplify X ? C : 0 where C is a power of 2 and
X tests a single bit.
2016-11-26 Paolo Bonzini
* gcc.dg/fold-and-lshift.c, gcc.dg/fold-and-rshift-1.c,
g
On 29/11/2016 11:16, Richard Biener wrote:
>>> >> (bit_and
>>> >> (if (shift > 0)
>>> >>(lshift (convert @0) { build_int_cst (integer_type_node, shift); })
>>> >>(convert (rshift @0 { build_int_cst (integer_type_node, -shift); })))
>>> >> @3)
>>> >>
>>> >> What do you think?
>> >
>>
On 27/11/2016 00:28, Marc Glisse wrote:
> On Sat, 26 Nov 2016, Paolo Bonzini wrote:
>
>> --- match.pd(revision 242742)
>> +++ match.pd(working copy)
>> @@ -2554,6 +2554,19 @@
>> (cmp (bit_and@2 @0 integer_pow2p@1) @1)
>> (icmp @2 { build_zero_cst
sall$7, %eax
Bootstrapped/regtested x86_64-pc-linux-gnu, ok?
Paolo
2016-11-26 Paolo Bonzini
* combine.c (simplify_if_then_else): Simplify IF_THEN_ELSE
that isolates a single bit, even if the condition involves
subregs.
* match.pd: Simplify X ? C : 0 where C i
On 24/11/2016 15:01, Michael Matz wrote:
>> > (set (reg:DI 69)
>> > (zero_extract:DI (reg:DI 65 [ v_x ]) <-
>> > (const_int 32 [0x20])
>> > (const_int 20 [0x14])))
> Hmm, this transformation (from v_x>>12 to zext(v_x,32,20) is only valid
> when the top 20 bits of v_
On 23/11/2016 11:26, Eric Botcazou wrote:
>> Does it really do that with a (set (reg1:QI)), as opposed to a
>> (set (strict_low_part (subreg:QI (reg1:DI)))?
>
> That's the question (note that REE runs after register allocation).
IIRC, strict_low_part is required even after register allocation,
On 23/11/2016 10:35, Eric Botcazou wrote:
> I now wonder
> whether this also matters for !WORD_REGISTER_OPERATIONS targets, e.g. x86:
>
> (set (reg1:DI) ...
> ...
>(set (reg1:QI) (expression:QI))
>...
>(set (reg2:DI) (any_extend:DI (reg1:QI)))
>
> It's not obvious to me whether this belongs in -Wextra. After all, this
> is a perfectly reasonable and useful GNU C feature, or at least some cases
> of it are (like "#define FOO (BAR || defined something)"). Is the
> argument that there are too many details of it that differ between
> impleme
On 10/08/2016 15:53, Paolo Bonzini wrote:
> From: Paolo Bonzini
>
> clang recently added a new warning -Wexpansion-to-defined, which
> warns when `defined' is used outside a #if expression (including the
> case of a macro that is then used in a #if expression).
>
> W
On 10/08/2016 17:58, Joseph Myers wrote:
> On Wed, 10 Aug 2016, Paolo Bonzini wrote:
>
>> There are indeed many pedwarn(loc, 0, ...) occurrences in C++ (most, but
>> not all, are "foo only available with -std=bar" which in the C front-end
>> would use OPT_Wpe
On 10/08/2016 17:33, Joseph Myers wrote:
> On Wed, 10 Aug 2016, Paolo Bonzini wrote:
>
>> - stuff that is not enabled by anything should use OPT_Wpedantic, and
>
> No, lots of pedwarns are for usages that are (a) dubious enough we want to
> diagnose them by default, a
On 10/08/2016 17:24, Manuel López-Ibáñez wrote:
> Perhaps we need something like -Wextra-pedantic, for things that are
> undefined by ISO C but defined by GNU. Thus, they would not trigger
> pedwarns and no error with -pedantic-errors.
I think this is overengineering it a bit. If they are annoy
On 10/08/2016 16:42, Manuel López-Ibáñez wrote:
> > > My only fear is that people not using -Wpedantic nor -pedantic-errors
> > > expect that GNU extensions work. This is a GNU extension that defines
> > > something that is undefined according to ISO. Enabling the warning
> > > with -Wextra is ju
From: Paolo Bonzini
clang recently added a new warning -Wexpansion-to-defined, which
warns when `defined' is used outside a #if expression (including the
case of a macro that is then used in a #if expression).
While I disagree with their inclusion of the warning to -Wall, I think
it is a
On 10/08/2016 13:31, Manuel López-Ibáñez wrote:
> My only fear is that people not using -Wpedantic nor -pedantic-errors
> expect that GNU extensions work. This is a GNU extension that defines
> something that is undefined according to ISO. Enabling the warning
> with -Wextra is just annoying thos
pansion-to-defined, and enables it automatically
for -Wextra instead of -pedantic.
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_
On 10/08/2016 02:48, Manuel López-Ibáñez wrote:
> TL;DR If the warning is enabled by -Wpedantic, it should be an error
> with -Werror=pedantic and it should use cpp_pedwarning. Whether it
> should be enabled by -Wpedantic is more difficult to say.
>
> -pedantic is equivalent to -Wpedantic. If -W
On 09/08/2016 20:44, Eric Gallager wrote:
> Hi, I'm just a lurker, but...
>
> On 8/9/16, Paolo Bonzini wrote:
>> Index: gcc/c-family/c.opt
>> ===
>> --- gcc/c-family/c.opt (revision 2
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
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
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 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
> >> 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 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
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 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
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
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
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
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
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 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
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 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
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 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,
>>>
>>&
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 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
There are plenty of targets that do not require -fPIC because they always
generate position independent code, but none of them feels the need to
complain with the user about an unnecessary but perfectly valid option,
on each and every .c->.o rule, and without a way to disable it.
Adding insult to
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 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 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 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
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 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 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 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 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 09/01/2015 15:24, Ian Lance Taylor wrote:
>> >
>> > This should work automatically, the only difference is that you must
>> > omit $(LIBGODEP) from the dependencies.
> What will happen if there is no installed gccgo at the right version?
Compilation fails.
> What should happen?
Compilation
On 08/01/2015 22:35, Ian Lance Taylor wrote:
>
> +if NATIVE
> +
> +# For a native build we build the programs using the newly built libgo
> +# and install them as regular programs.
> +
> +bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT)
> +libexecsub_PROGRAMS = cgo$(EXEEXT)
> +
> +go$(EXEEXT): $(go_cmd
On 19/12/2014 16:13, Segher Boessenkool wrote:
> Hi,
>
> Sorry for the quick ping, but this fixes bootstrap on AIX, powerpc-darwin,
> and 32-bit PowerPC Linux. Could a gentle soul please spare a minute to
> review, before the holidays? Thanks in advance!
I cannot approve it, but the patch is
On 15/12/2014 17:24, Segher Boessenkool wrote:
> On Mon, Dec 15, 2014 at 04:51:14PM +0100, Paolo Bonzini wrote:
>> Random questions:
>>
>> 1) did you check that it never triggers on e.g. an x86 bootstrap, and
>> that it doesn't trigger too often on PPC64?
&
On 15/12/2014 12:05, Segher Boessenkool wrote:
> If combine is given a parallel I2, it splits it into separate I1 and
> I2 insns in some cases (one case since the beginning of time; more
> cases since my r218248). It gives the new I1 the same UID as the I2
> already has; there is a comment that
On 05/12/2014 23:47, Jakub Jelinek wrote:
> On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote:
>>> As I've tried to explain, that is IMHO wrong though.
>>> If what you are after is the -B stuff too, then perhaps:
>>> ...
>>
>> Sorry but it does not work:
>
> Sorry, make that (j
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_
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 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: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: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: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: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/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.
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 17/09/2014 16:09, Jakub Jelinek ha scritto:
>> > Is the offloading compiler built together with GCC or previously? If
>> > the latter, what's the difference between the offloading compiler and
>> > say gmp? Setting the LD_LIBRARY_PATH would be the responsibility of
>> > whoever builds GCC; it
Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> It seems building of the host compiler requires the offloading compiler
> to be installed directly in the prefix, which is something really
> undesirable e.g. for distro builds where things are installed with
> non-empty $(DESTDIR).
Is the offloadin
Il 24/07/2014 19:32, Uros Bizjak ha scritto:
> Hello!
>
>> Well, I was lucky enough to gain access to an alpha pca56 for a day (I say
>> lucky, this may not be repeatable!). However I was not able to build the Ada
>>
>> frontend, due (AFAICT) to the image being too big for relocations.
>> (Moreov
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
Il 29/05/2014 19:20, pins...@gmail.com ha scritto:
What is your Pmode?
Pmode is dimode while ptr_mode is simode. Pointers are zero extended when
converting between si and di modes.
As you noted, the fundamental difference between x32 and aarch64 is that
aarch64 will still use 64-bit access
Il 26/03/2014 00:28, Tobias Burnus ha scritto:
Paolo Bonzini wrote:
Il 11/03/2014 07:42, Tobias Burnus ha scritto:
+XPCFLAGS=""
+CFLAGS="$CFLAGS -pthread"
+AC_LINK_IFELSE(
...
+ [XPCFLAGS=" -Wc,-pthread"],
XPCFLAGS is dead, I think?
Yes - contrary to libgomp
Il 25/03/2014 20:24, Jakub Jelinek ha scritto:
Hi!
This patch fixes a problem where build of host fixincludes fails
with --with-build-config=bootstrap-ubsan (and bootstrap-asan).
The problem is that fixincludes is linked against host libiberty
that is bootstrapped, but fixincludes is not bootstr
Il 20/03/2014 13:24, Jakub Jelinek ha scritto:
Hi!
We currently bootstrap both libsanitizer and libvtv, the former
just in case somebody decides to --with-build-config=bootstrap-asan
(or --with-build-config=bootstrap-ubsan), the latter if somebody decides
to --enable-vtable-verify.
This patch c
Il 11/03/2014 07:42, Tobias Burnus ha scritto:
+# Check to see if -pthread or -lpthread is needed. Prefer the former.
+# In case the pthread.h system header is not found, this test will fail.
+XPCFLAGS=""
+CFLAGS="$CFLAGS -pthread"
+AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM(
+ [#include
+ void *g(
Il 23/03/2014 09:24, Rainer Orth ha scritto:
>> The following patch adds it and indeed macro_list now is non-empty, as
>> expected. I'm just not sure if cc1 is the correct one in
>> gcc/Makefile.in, or if it should rather be $(COMPILERS) instead.
>>
>> Anyway, with that patch a i386-pc-solaris2.
Il 21/03/2014 18:05, Rainer Orth ha scritto:
The following patch adds it and indeed macro_list now is non-empty, as
expected. I'm just not sure if cc1 is the correct one in
gcc/Makefile.in, or if it should rather be $(COMPILERS) instead.
Anyway, with that patch a i386-pc-solaris2.10 bootstrap c
Il 09/03/2014 07:24, Tobias Burnus ha scritto:
The attached patch installs cilk.h such that "#include "
works.
Bootstrapped on x86-64-gnu-linux.
OK for the trunk?
(If you wonder about the other changes in the generated-files diff: I
think they are due to r205357, where configure.ac changed and
Il 07/03/2014 11:45, Jakub Jelinek ha scritto:
On Fri, Mar 07, 2014 at 08:26:47AM +0100, Paolo Bonzini wrote:
> Il 06/03/2014 19:58, Jakub Jelinek ha scritto:
> >Bootstrapped/regtested on x86_64-linux and i686-linux and tested also
> >with make bootstrap-lean; make instal
Il 05/03/2014 16:53, Rainer Orth ha scritto:
When using GNU as with Solaris ld, the TLS local dynamic tests
(gcc.dg/torture/tls/run-ld.c etc.) FAIL to execute before Solaris 11:
the programs crash with an illegal instruction: e.g. in the
gcc.dg/lto/20090210 test, we have
0x8050ce0 : mov%gs:0
Il 06/03/2014 19:58, Jakub Jelinek ha scritto:
Hi!
As discussed in the PR, doing
make bootstrap-lean
make install
right now may fail (if host compiler is too old), or recompile various
objects of the compiler with system gcc before it is installed.
This happens because starting with the automati
Il 06/03/2014 12:55, Rainer Orth ha scritto:
Uros pointed me at PR libgcc/59339 where make install tries to install
the vtv_*.o files even if they aren't built, leading to install
warnings.
The following patch fixes this by ensuring that the files are only
installed if built.
Tested with make i
Il 17/01/2014 15:21, Rainer Orth ha scritto:
> As described in the PR, the 64-bit Solaris 10+/x86 libc contains an
> implementation of those _Unwind_* functions required by the AMD64 ABI,
> i.e. those contained in libgcc_s.so.1 at version GCC_3.0.
>
> If by some circumstance (use of -Bdirect, -z l
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,
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 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 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 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 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
> (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
1 - 100 of 575 matches
Mail list logo
