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 this
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 clobbered by a
call
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
seems better.
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 r...@cebitec.uni-bielefeld.de
* configure.ac (GCC_LIBSTDCXX_RAW_CXX_FLAGS): Remove.
* configure: Regenerate.
Ok if it passes.
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 access.
Note that you need to regenerate all users
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 to use gcc-ar/gcc-nm
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
for a while.
-ffat-lto-objects doubles compilation time and often makes
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 not necessary
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, call
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
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 other
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;
which
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 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):
FWIW, I
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_
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 for
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
Il 25/09/2013 06:37, Alexandre Oliva ha scritto:
On Sep 23, 2013, Tom Tromey tro...@redhat.com 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
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 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, so
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)
(COMPILE,
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,
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.
* Makefile.in
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(-)
diff
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 changed,
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 is
Il 26/08/2013 18:09, Tom Tromey ha scritto:
Ian == Ian Lance Taylor i...@google.com 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,
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-strings
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 understanding).
-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 bonz...@gnu.org
wrote:
Il 29/05/2013 12:50, Thomas Schwinge ha scritto:
How about we use something like the following [...] patch
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 ebotca...@adacore.com
*
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 right
-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 computed for
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 build gcc
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.
Since
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.
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 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_reg_used
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
df_uses_record (collection_rec, XEXP (dst, 0),
Please submit a patch that applies cleanly (the above has mangled
whitespace) and mention whether you have bootstrapped/regression-tested
it on a primary platform (e.g. x86_64-linux).
Thanks,
Paolo
Thanks,
Amir
On Thu, Apr 11, 2013 at 4:06 PM, Paolo
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 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. Bootstrappedtested on
powerpc64-unknown-linux-gnu. OK for trunk?
Ok.
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 ja...@redhat.com
PR middle-end/56461
* df-scan.c
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
so it needs someone DF aware to review
and that makes it stage1 material as well I think.
Also good. I think the patch is quite safe but it's obviously not a
bug fix (except perhaps for making the dumps less confusing). Let's
consider this queued for GCC 4.9.
FWIW, I like to think of
Il 13/02/2013 22:12, Steven Bosscher ha scritto:
On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote:
Hi!
As agreed on in the PR, here is the revertion of 3 commits, so that
PCH works again for -gstabs and other debug info formats for 4.8
release. For 4.9 we should either remove support
Il 06/02/2013 12:22, Frediano Ziglio ha scritto:
I used an header from Linux which is derived from this GCC header when
GCC was still GPL2 so GPL3 does not apply. Xen is GPL2 too so there is
no problem using this header in Xen. The problem is including in the
public headers.
Actually I
Il 04/02/2013 17:46, Ian Lance Taylor ha scritto:
On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
frediano.zig...@citrix.com wrote:
I imported some headers from Linux kernel which mainly came from
gcov-io.h and the structures used internally by GCC.
Our problem is currently about the
Il 29/01/2013 13:42, Rainer Orth ha scritto:
As originally reported as binutils PR ld/15057, several gfortran tests
are failing on Solaris/SPARC with Sun as and GNU ld like this:
FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
(test for excess errors)
Excess
Il 25/01/2013 08:24, Uday P. Khedker ha scritto:
Exactly. We have been using our training program since 2007 (and have
been incrementally refining it on a continuously). Our experience has
been that it has brought down the ramp up period of novices to a couple
of week.
A couple of weeks is
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 they must be
Il 30/12/2012 01:13, Alexandre Oliva ha scritto:
On Dec 24, 2012, Paolo Bonzini bonz...@gnu.org 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 (it's in
bits/fenv.h
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 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 away,
Il 11/12/2012 22:39, H.J. Lu ha scritto:
On Tue, Dec 11, 2012 at 6:36 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 11/12/2012 14:47, H.J. Lu ha scritto:
On Thu, Dec 6, 2012 at 7:07 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Nov 29, 2012 at 10:30 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi
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 bonz...@gnu.org 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 -D_DEBUG
-D__STDC_CONSTANT_MACROS
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_TARGET_FLAGS.
We
Il 13/12/2012 00:23, H.J. Lu ha scritto:
On Wed, Dec 12, 2012 at 3:01 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Dec 12, 2012 at 2:13 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 12/12/2012 19:11, H.J. Lu ha scritto:
in RAW_CXX_TARGET_EXPORTS. There is no need to do anything.
Nope
Il 11/12/2012 14:47, H.J. Lu ha scritto:
On Thu, Dec 6, 2012 at 7:07 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Nov 29, 2012 at 10:30 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
Since libsanitizer is used for bootstrap and compiled with raw_cxx,
we need to use explicit -I for
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_srcdir)/../gcc/BASE-VER)
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 as the
Il 11/12/2012 20:27, H.J. Lu ha scritto:
On Tue, Dec 11, 2012 at 6:36 AM, Paolo Bonzini bonz...@gnu.org wrote:
As a followup please check if AM_MAKEFLAGS is needed at all.
diff --git a/libsanitizer/Makefile.in b/libsanitizer/Makefile.in
index 21c2711..53e0be9 100644
--- a/libsanitizer
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 (XEXP
Il 04/12/2012 23:30, H.J. Lu ha scritto:
On Tue, Nov 27, 2012 at 8:00 AM, Paolo Bonzini bonz...@gnu.org 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 a separate patch, but this one
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 16-bit,
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
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 dougk...@google.com
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
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
Lots of errors like the following:
-o build/genrecog.o ../../gcc/genrecog.c
In file included from ../../gcc/rtl.h:29,
from ../../gcc/genoutput.c:92:
../../gcc/vec.h:654: error: default argument missing for parameter 4 of
‘templateclass T, class A bool
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 very
in progress; ok for
4.7 and trunk if it passes?
Paolo
2012-11-26 Paolo Bonzini pbonz...@redhat.com
PR rtl-optimization/55489
* gcse.c (compute_transp): Precompute a canonical version
of XEXP (x, 0), and pass it to canon_true_dependence.
Index: gcse.c
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 pbonz...@redhat.com
* alias.c (init_alias_analysis): Fix allocation of reg_known_value
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. Like
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
Il 14/11/2012 15:27, Ian Lance Taylor ha scritto:
On Wed, Nov 14, 2012 at 5:36 AM, Richard Earnshaw rearn...@arm.com wrote:
On 13/11/12 14:56, Ian Lance Taylor wrote:
Currently -fPIC -fPIE seems to be the same as -fPIE. Unfortunately,
-fPIE -fPIC also seems to be the same as -fPIE. It seems
On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor i...@google.com wrote:
The main advantage is that you can compile a program with CFLAGS=-O2 -g
-fPIE, and libtool's adding of -fPIC for shared libraries will work
reliably. If -fPIE can still override -fPIC, the result depends on
whether -fPIC
Il 19/11/2012 05:35, H.J. Lu ha scritto:
On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini bonz...@gnu.org 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-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 19/11/2012 05:35, H.J. Lu ha scritto:
On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 18/11/2012 00:54, H.J. Lu ha scritto
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, and
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 bonz...@gnu.org 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
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 libsanitizer?
Paolo
Il 15/11/2012 17:28, H.J. Lu ha scritto:
On Thu, Nov 15, 2012 at 8:08 AM, Paolo Bonzini bonz...@gnu.org 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 look.
I am checking in this patch.
This is what I checked
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/. This is
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 remove duplicated
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 bonz...@gnu.org 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?
I really would prefer to do it in the order I mentioned above
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 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 (reg/f:DI
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 test
101 - 200 of 1512 matches
Mail list logo
