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 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
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 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
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 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
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 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: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 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 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_
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 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
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?
>> >
>>
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 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
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
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 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
> 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 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)))
>
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 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 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 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 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 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 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
Il 10/11/2012 07:44, H.J. Lu ha scritto:
> Hi,
>
> In
>
> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
> {*movti_internal_rex64}
> (expr_list:REG_DEAD (reg:SI 82)
> (expr_list:REG_EQUIV (mem/c:TI (plus:DI (r
Il 10/11/2012 05:30, Andrew Pinski ha scritto:
> Hi,
> The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
> the final installed binary name. This patch fixes the problem by
> changing if we got ld-new to just ld.
> Note this issue has been around since 4.6 but not many people t
Il 13/11/2012 18:03, H.J. Lu ha scritto:
>> > libsanitizer/ChangeLog.asan should probably be just libsanitizer/ChangeLog.
>> >
>> > In any case, I'd prefer if configury maintainers could review that.
> Sure.
Let's first remove the files that are duplicated between the toplevel
and libsanitizer/.
Il 13/11/2012 23:45, H.J. Lu ha scritto:
>> >
>> > Let's first remove the files that are duplicated between the toplevel
>> > and libsanitizer/. This is preapproved after a successful bootstrap,
>> > but please remember to rerun autoconf/automake in the libsanitizer/
>> > directory.
> We can't rem
Il 14/11/2012 00:16, H.J. Lu ha scritto:
>> > What has to be fixed about it? Anything except
>> > AC_PREREQ/AC_CONFIG_AUX_DIR?
>> >
>> > I really would prefer to do it in the order I mentioned above.
> We also need
>
> [hjl@gnu-tools-1 libsanitizer]$ cat acinclude.m4
> dnl --
Il 14/11/2012 00:27, H.J. Lu ha scritto:
> On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini wrote:
>> Il 14/11/2012 00:16, H.J. Lu ha scritto:
>>>>> What has to be fixed about it? Anything except
>>>>> AC_PREREQ/AC_CONFIG_AUX_DIR?
>>>>&g
Il 14/11/2012 00:43, H.J. Lu ha scritto:
> This works.
Ok, then please test remove install-sh and friends and do
autoconf/automake again. If it works, commit the result (I don't care
if you make it one or two commits).
Then, wait 24 hours for breakages and commit the multilib patch.
Paolo
Il 15/11/2012 17:02, H.J. Lu ha scritto:
>>> >> I can reproduce it with --enable-version-specific-runtime-libs. I am
>>> >> taking a look.
>>> >>
>> >
>> > I am checking in this patch.
>> >
> This is what I checked in.
libssp et al. do not need any of this stuff.
What's special about libsanitize
Il 15/11/2012 17:28, H.J. Lu ha scritto:
> On Thu, Nov 15, 2012 at 8:08 AM, Paolo Bonzini wrote:
>> Il 15/11/2012 17:02, H.J. Lu ha scritto:
>>>>>>> I can reproduce it with --enable-version-specific-runtime-libs. I am
>>>>>>> taking a lo
Il 18/11/2012 00:54, H.J. Lu ha scritto:
> +@if gcc-bootstrap
> +ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
> +LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
> +endif
> +@endif gcc-bootstrap
Do you need this to be here? POSTSTAGE1_*_EXPORT is only used when
bootstrapping,
Il 18/11/2012 16:59, Hans-Peter Nilsson ha scritto:
> On Sun, 18 Nov 2012, H.J. Lu wrote:
>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
>>> Il 18/11/2012 00:54, H.J. Lu ha scritto:
>>>> +@if gcc-bootstrap
>>>> +ifneq ($(filter bootstrap-asan,$
Il 19/11/2012 05:35, H.J. Lu ha scritto:
> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
>> Il 18/11/2012 00:54, H.J. Lu ha scritto:
>>> +@if gcc-bootstrap
>>> +ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
>>> +LIBASAN_LIBS=-B$$r/prev-$(TA
On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu wrote:
> On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini wrote:
>> Il 19/11/2012 05:35, H.J. Lu ha scritto:
>>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
>>>> Il 18/11/2012 00:54, H.J. Lu ha scritto:
>>
Il 27/11/2012 13:00, Steven Bosscher ha scritto:
> It all
> starts with PRE creating a REG_EQUAL note that references the register
> that's SET in the insn the note is attached to, but the register is
> live after the insn so from that point of view the note is not
> invalid.
This note seems very
u, regtest in progress; ok for
4.7 and trunk if it passes?
Paolo
2012-11-26 Paolo Bonzini
PR rtl-optimization/55489
* gcse.c (compute_transp): Precompute a canonical version
of XEXP (x, 0), and pass it to canon_true_dependence.
Ind
will always return NULL.
This patch fixes the VEC usage. Bootstrap/regtest in progress, but I'm
going to commit this as obvious as soon as bootstrapping finishes.
Paolo
2012-11-26 Paolo Bonzini
* alias.c (init_alias_analysis): Fix allocation of reg_known_value.
Index: ../.
Il 27/11/2012 17:40, Steven Bosscher ha scritto:
> > Note that the bug is present on older branches too, but it became much
> > worse sometime between 4.4 and 4.7.
>
> Probably around the time we (i.e. you and me) taught gcse.c to handle
> REG_EQUAL expressions?
Hmm, no, that was much earlier. L
Il 27/11/2012 17:07, H.J. Lu ha scritto:
> There is no reply for
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02121.html
That counts as lack of review...
Paolo
I cannot approve the collect2.c, gcc.c, opts.c, doc/invoke.texi. I'll
include some comments anyway, since the patch needs some more work.
> 2011-06-27 Doug Kwan
>
> Google ref 41164-p2
> Backport upstream patch under review.
>
> 2011-01-19 Nick Clifton
>
Il 16/11/2012 01:53, Andrew Pinski ha scritto:
> Hi,
> If the PATH contains the current working directory (yes a bad idea
> but it could happen with our users), the build fails because it finds
> the newly created g++ which might not find the correct cc1plus. See
> the thread starting at
> http:
Il 28/11/2012 20:11, H.J. Lu ha scritto:
> Here is the updated patch. OK for trunk?
Looks good to me, though of course there are many parts I cannot
approve. Thanks!
Paolo
Il 29/11/2012 23:47, Uros Bizjak ha scritto:
> This one-liner causes following runtime test failure [1] for
> alphaev68-linux-gnu:
>
> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
> -fomit-frame-pointer -finli
Il 01/12/2012 15:54, Eric Botcazou ha scritto:
>> Attached is a different fix. It splits DF_REF_IN_NOTE in two: One flag
>> > for each kind of note. This allows the dead note removal code to
>> > distinguish the source note for the EQ_USES. I needed to remove one
>> > flag to keep the df_ref_flags
Il 04/12/2012 23:30, H.J. Lu ha scritto:
> On Tue, Nov 27, 2012 at 8:00 AM, Paolo Bonzini wrote:
>> Hi,
>>
>> this bug triggers in the compilation of QEMU with GCC 4.7.2. It is
>> latent on trunk because reg_known_value is completely broken. I'll
>> send
Il 05/12/2012 15:22, Marc Glisse ha scritto:
> +
> + /* The x86 back-end uses VEC_CONCAT to set an element in a V2DF, but
> +VEC_MERGE for scalar operations that preserve the other elements
> +of a vector. */
> + if (GET_CODE (trueop1) == VEC_SELECT
> + && GET_MODE
Il 18/05/2013 04:29, Chung-Ju Wu ha scritto:
> Ping: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00429.html
>
> The patch is to fix dependency issue of libgcc Makefile.in
> by adding 'rm libgcc_tm.stamp' in the clean rule.
>
> That was fixed on main trunk (r187838) but not on gcc-4_7-branch.
> S
Il 18/05/2013 04:37, Chung-Ju Wu ha scritto:
> Hi all,
>
> Using current trunk repository, it is now able to build
> compiler with in-tree isl and cloog.
>
> This patch is to extend ./contrib/download_prerequisites
> usage to download isl and cloog conditionally in case
> people would like to bui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 29/05/2013 12:50, Thomas Schwinge ha scritto:
>>> How about we use something like the following [...] patch? In
>>> essence, replace the manual parsing in
>>> gcc/ada/gcc-interface/Makefile.in by using the values the
>>> configure script already c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 29/05/2013 23:36, Thomas Schwinge ha scritto:
> Hi!
>
> On Wed, 29 May 2013 16:21:38 +0200, Paolo Bonzini
> wrote:
>> Il 29/05/2013 12:50, Thomas Schwinge ha scritto:
>>>>> How about we use something like th
Il 30/05/2013 09:21, Eric Botcazou ha scritto:
>> However, it seems that the first androideabi snippet was dead code.
>> Can you delete it in a follow-up?
>
> No, it's not dead code, just broken at the moment, now fixed by:
>
>
> 2013-05-30 Eric Botcazou
>
> * gcc-interface/Makefile.in
Il 30/05/2013 09:33, Eric Botcazou ha scritto:
>> I don't think this fixes it. The problem is that the second eabi
>> > conditional overrides the first (the one for Android).
> Then let's fix the second eabi or swap them, but the first one must stay.
Yes, got it. Swapping them looks like the rig
Il 31/05/2013 10:03, Eric Botcazou ha scritto:
>> I don't understand this change. This used to match configurations
>> arm*-[vendor]-linux-androideabi; now it only matches
>> arm*-[vendor]-androideabi, which isn't in use (for a Android system is
>> always based on the Linux kernel, in my understan
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 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 26/02/2013 16:25, Rainer Orth ha scritto:
> I've received a report in private mail that a gcc build on Solaris might
> fail in libstdc++. It turned out that this was caused by a non-C locale
> which causes elfdump to produce translated headers and confuses
> make_sunver.pl. The following patch
Il 27/02/2013 17:01, Jakub Jelinek ha scritto:
> Hi!
>
> We can leak mw_hardregs memory in some cases.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?
>
> 2013-02-27 Jakub Jelinek
>
> PR middle-end/56461
> * df-scan.c (df_insn_delete): Use
Il 18/03/2013 01:01, Steven Bosscher ha scritto:
>> > someone else DF aware anyway. If it is 4.9 material perhaps
>> > it is simpler to place it after the patches that kill the basic
>> > block argument.
> Here is the updated patch. Bootstrapped&tested on
> powerpc64-unknown-linux-gnu. OK for trun
Il 26/03/2013 21:48, Gabriel Dos Reis ha scritto:
>
> Hi Paolo,
>
> The patchlet below allows uses of source file with .cc extension.
>
> This comes out of work being done on the C++ front-end and has merit of
> its own. OK to apply?
>
> Thanks,
>
> -- Gaby
>
> 2013-03-26 Gabriel Dos Reis
Il 10/04/2013 21:33, Steven Bosscher ha scritto:
> Hello,
>
> df_find_def and df_find_use do not work properly for hard registers
> because rtx_equal_p returns false for the case where
> REGNO(x)==REGNO(y) but the modes are different. This happened as
> follows in my case:
>
> Breakpoint 9, df_re
Il 11/04/2013 14:57, Amir Gonnen ha scritto:
> Hi Paolo,
>
> About 3 years ago I've sent a patch which was submitted by Kenneth
> Zadeck on revision 153924 (See
> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00232.html)
>
> Recently we tried to update our gcc port from gcc-4.4 to gcc-4.8 and
> di
e.g. x86_64-linux).
Thanks,
Paolo
> Thanks,
>
> Amir
>
> On Thu, Apr 11, 2013 at 4:06 PM, Paolo Bonzini wrote:
>> Il 11/04/2013 14:57, Amir Gonnen ha scritto:
>>> Hi Paolo,
>>>
>>> About 3 years ago I've sent a patch which was submitted by Ken
Il 13/04/2013 02:02, Steven Bosscher ha scritto:
>
> * emit-rtl.c (remove_insn): Do not call df_insn_delete here.
> * cfgrtl.c (delete_insn): Call it here instead.
> * lra-spills.c (lra_final_code_change): Use delete_insn.
> * haifa-sched.c (sched_remove_insn): Likewise.
>
Il 08/04/2013 14:20, Rainer Orth ha scritto:
> While the Solaris linker doesn't support the --as-needed/--no-as-needed
> options (yet), it long has provided the equivalent -z ignore/-z record
> options. This patch makes use of them, avoiding unnecessary
> dependencies on libgcc_s.so.1.
>
> Bootst
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 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 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 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 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 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 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 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 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 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 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 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 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 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 11/12/2012 14:47, H.J. Lu ha scritto:
> On Thu, Dec 6, 2012 at 7:07 AM, H.J. Lu wrote:
>> On Thu, Nov 29, 2012 at 10:30 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> Since libsanitizer is used for bootstrap and compiled with raw_cxx,
>>> we need to use explicit -I for libstdc++-v3 header files in
>>> lib
Il 11/12/2012 16:03, H.J. Lu ha scritto:
> diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
> index 3da1db3..45fb3b3 100644
> --- a/libsanitizer/asan/Makefile.am
> +++ b/libsanitizer/asan/Makefile.am
> @@ -5,6 +5,10 @@ gcc_version := $(shell cat $(top_s
Il 11/12/2012 17:55, H.J. Lu ha scritto:
>> > Does it use any GCC toplevel files except when regenerating the
>> > configury? But I think it's a useful refactoring anyway.
> libsanitizer started as standalone and it didn't work with GCC build.
> We removed all those extra files to get it compile a
Il 11/12/2012 20:27, H.J. Lu ha scritto:
> On Tue, Dec 11, 2012 at 6:36 AM, Paolo Bonzini wrote:
>
>>
>> As a followup please check if AM_MAKEFLAGS is needed at all.
>>
>>>>> diff --git a/libsanitizer/Makefile.in b/libsanitizer/Makefile.in
>>
Il 11/12/2012 22:39, H.J. Lu ha scritto:
> On Tue, Dec 11, 2012 at 6:36 AM, Paolo Bonzini wrote:
>> Il 11/12/2012 14:47, H.J. Lu ha scritto:
>>> On Thu, Dec 6, 2012 at 7:07 AM, H.J. Lu wrote:
>>>> On Thu, Nov 29, 2012 at 10:30 AM, H.J. Lu wrote:
>>>>&g
Il 11/12/2012 23:00, H.J. Lu ha scritto:
> ## The mysterious backslash in the grep pattern is consumed by make.
> -lib_gnu_awt_xlib_la_LDFLAGS = ../libstdc++-v3/src/libstdc++.la \
> +lib_gnu_awt_xlib_la_LDFLAGS = $(LIBSTDCXX_RAW_CXX_LDLAGS) \
> @X_PRE_LIBS@ @X_LIBS@ -lX11 @X_EXTRA_LIBS@ \
>
Il 12/12/2012 15:41, H.J. Lu ha scritto:
> MAKEOVERRIDES is used for multilib. I got
>
> /bin/sh ../libtool --tag=CXX --mode=compile -D_GNU_SOURCE -D_DEBUG
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -DASAN_HAS_EXCEPTIONS=1 -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0
> -
Il 12/12/2012 18:30, H.J. Lu ha scritto:
> On Wed, Dec 12, 2012 at 6:46 AM, Paolo Bonzini wrote:
>> Il 12/12/2012 15:41, H.J. Lu ha scritto:
>>> MAKEOVERRIDES is used for multilib. I got
>>>
>>> /bin/sh ../libtool --tag=CXX --mode=compile -D_GNU_SOURCE -
Il 12/12/2012 19:11, H.J. Lu ha scritto:
>>> >>
>>> >> in RAW_CXX_TARGET_EXPORTS. There is no need to do anything.
>> >
>> > Nope, if you remove this you get the wrong definition of CC and CXX from
>> > EXTRA_TARGET_FLAGS. Instead, you need to add RAW_CXX_FOR_TARGET to
>> > AM_MAKEFLAGS and EXTRA
Il 13/12/2012 00:23, H.J. Lu ha scritto:
> On Wed, Dec 12, 2012 at 3:01 PM, H.J. Lu wrote:
>> On Wed, Dec 12, 2012 at 2:13 PM, Paolo Bonzini wrote:
>>> Il 12/12/2012 19:11, H.J. Lu ha scritto:
>>>>>>>>
>>>>>>>> in RAW_CXX_TARGET
Il 17/12/2012 22:33, Jakub Jelinek ha scritto:
> Hi!
>
> If gen_lowpart_if_possible returns NULL, the default
> rtl_hooks.gen_lowpart_no_emit hook returns the original value, which is not
> of the desired mode. I bet in most passes for real insns such rtx is then
> meant to fail recog and thrown
Il 21/12/2012 06:17, Alexandre Oliva ha scritto:
> Revision 193063 brought in calls to fraiseexcept() into libquadmath,
> which caused a build regression on Fedora 16 (BLAG 160k actually) x86_64
> while building an i686-linux-gnu native toolchain.
>
> The problem is that glibc has an extern inline
Il 30/12/2012 01:13, Alexandre Oliva ha scritto:
> On Dec 24, 2012, Paolo Bonzini wrote:
>
>> Il 21/12/2012 06:17, Alexandre Oliva ha scritto:
>>> The problem is that glibc has an extern inline definition of
>>> fraiseexcept that is introduced by including fenv.h
Il 17/01/2013 21:05, minux ha scritto:
>> >
>> > I think gcc should try and build and run a gmp program and fail to
>> > configure if the binary can't also run. This prevents configuring and
>> > building on such a system. The gcc directions for building gmp and
>> > friends should say that th
Il 18/01/2013 18:48, Mike Stump ha scritto:
> Now, I'm happy to have a shared library expert weigh in and explain
> why we should not fail the build… I'm happy to defer to them, if
> there is a compelling reason why someone would compile things this
> way. I just can't help but think we serve the
101 - 200 of 575 matches
Mail list logo
