On Mon, Nov 19, 2012 at 2:45 AM, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
>
> Uros, there is i386.md part for which I need an approval. Without this
> change, GCC will still generate the same code even if LRA uses an
> alternative w
On Sat, Nov 17, 2012 at 11:10:04AM -0800, Richard Henderson wrote:
> On 11/16/2012 01:10 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > - PR54921 invalidate sp in cselib on fp setter insn
> > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html
> > (perhaps in light of PR54402 the single_succ (EN
I've merged trunk revision 193614 to the gccgo branch.
Ian
The gccgo frontend uses a slightly different representation for
interface values than the gc compiler: the gccgo frontend stores pointer
values directly, and all other values indirectly. That requires some
changes in the reflect package. There was a bug in those changes, which
showed up in that i
On Fri, Nov 16, 2012 at 11:07 AM, Jan Hubicka wrote:
>> This patch addresses the bogus "Invocation mismatch" messages seen in
>> parallel
>> profiledbootstrap builds of gcc. See PR bootstrap/55051 for a discussion of
>> why this is occurring and why this checking is inaccurate.
>>
>> Profileboots
Hi,
This patch adds explicit -I for libstdc++-v3 header files when building
libsanitizer so that it can be used for bootstrapping GCC. Othewise,
-funconfigured-libstcd++-v3 will be used to compile multilib
libsanitizer. OK to install?
Thanks.
H.J.
---
2012-11-18 H.J. Lu
* Makefile
Hi,
This patch adds STATIC_LIBASAN_LIBS so that one can simply use
"gcc -faddress-sanitizer -static-libasan". OK to install?
Thanks.
H.J.
---
2012-11-18 H.J. Lu
* gcc.c (ADD_STATIC_LIBASAN_LIBS): New macro. Defined
with STATIC_LIBASAN_LIBS.
(LIBASAN_SPEC): Add STAT
Hi,
This patch prepens -lasan before any other libraries added by language.
It also disallows -static with -faddress-sanitizer. OK to install?
Thanks.
H.J.
---
2012-11-18 H.J. Lu
PR driver/55379
PR driver/55374
* gcc.c (prepend_lang_specific_driver): New function.
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-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
>> +endif
>> +@endif gcc-bootstrap
>
> Do you need this
This patch is another installment in my series of copy-edits to the GCC user
documentation. Here I've cleaned up several Texinfo markup issues relating to
example environments. Checked in under the free-for-all write access policy.
-Sandra
2012-11-18 Sandra Loosemore
gcc/
On Mon, 12 Nov 2012, Eric Botcazou wrote:
> > This is a target-specific blockage insn, but with the general form
> > found in all targets defining it. The default blockage is an empty
> > asm-volatile, which is what cse_insn recognized. The blockage insn is
> > there to "prevent scheduling" of th
On Sun, Nov 18, 2012 at 5:14 PM, David Edelsohn wrote:
>
> The problem is AIX stdlib.h defines
>
> #define vec_free free
Ouch.
> I am not sure where
>
> #undef vec_free
>
> should be placed. In vec.h or system.h?
I think system.h.
Ian
On Sun, Nov 18, 2012 at 7:09 AM, Diego Novillo wrote:
> On Fri, Nov 16, 2012 at 6:29 PM, Ian Lance Taylor wrote:
>> On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo wrote:
>>> 2012-11-15 Diego Novillo
>>>
>>> Adjust for new vec API
>>> (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec)
>
Richard,
Consider the PR55124 example test.c:
...
int a, b;
long c;
static void inline
f2 (void)
{
unsigned long k = 1;
foo (b ? k = 0 : 0);
b = (((c = b)
? (k ?: (c = 0))
: a)
* c);
}
void
f1 (void)
{
f2 ();
a = b | c;
}
...
when compiling with -O2, we're run
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
Uros, there is i386.md part for which I need an approval. Without this
change, GCC will still generate the same code even if LRA uses an
alternative with 'm' constraint.
2012-11-18 Vladimir Makarov
PR ta
On Sun, Nov 18, 2012 at 8:03 PM, Diego Novillo wrote:
>> And now bootstrap fails on AIX using GCC 4.6.3 with the error:
>>
>> /nasfarm/dje/src/src/gcc/c-family/c-lex.c: In function 'c_fileinfo*
>> get_fileinfo(const char*)':
>> /nasfarm/dje/src/src/gcc/c-family/c-lex.c:107:39: error: overloaded
On Sun, Nov 18, 2012 at 4:28 PM, David Edelsohn wrote:
> Files were changed in gcc/c-family with no associated ChangeLog entry.
*gasp*
I mistakenly put them in c/ChangeLog. Not that they carry any useful
information, but I'll move them.
> And now bootstrap fails on AIX using GCC 4.6.3 with th
On Sun, Nov 18, 2012 at 4:37 PM, Jan-Benedict Glaw wrote:
> Hi!
>
> There was a discussion on the binutils mailing list recently, because
> shared files were out of sync and a merge error showed up afterwards.
>
> That made my write a small script to check the shared files between
> the `src' and
Hi!
There was a discussion on the binutils mailing list recently, because
shared files were out of sync and a merge error showed up afterwards.
That made my write a small script to check the shared files between
the `src' and `gcc' repos, as well as the `config' repo to both of
them.
The consens
On Sun, 18 Nov 2012, Paolo Bonzini wrote:
> Il 18/11/2012 16:59, Hans-Peter Nilsson ha scritto:
> > Nice, but I agree with the other poster that this'd IMHO be
> > better as --enable-checking=asan (or actually,
> > --enable-checking=all,asan).
>
> Yeah, that's a good thing to support too. However,
> I think this should fix it. Can't test it right now, so help
> appreciated (Honza: hint hint! ;-)
The change at
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01511/remove_dead_eq_notes.diff
(revision 192526) caused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006
Dominique
Files were changed in gcc/c-family with no associated ChangeLog entry.
And now bootstrap fails on AIX using GCC 4.6.3 with the error:
/nasfarm/dje/src/src/gcc/c-family/c-lex.c: In function 'c_fileinfo*
get_fileinfo(const char*)':
/nasfarm/dje/src/src/gcc/c-family/c-lex.c:107:39: error: overloaded
On Sun, 18 Nov 2012, Andreas Tobler wrote:
> On 18.11.12 20:11, Hans-Peter Nilsson wrote:
> > On Sun, 18 Nov 2012, Andreas Tobler wrote:
> >> Is there a minimum gcc to bootstrap current trunk?
> >> I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
> >> succeeds.
> >
> > A gcc-4.1.2 h
On 18.11.12 20:11, Hans-Peter Nilsson wrote:
> On Sun, 18 Nov 2012, Andreas Tobler wrote:
>> Is there a minimum gcc to bootstrap current trunk?
>> I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
>> succeeds.
>
> A gcc-4.1.2 has worked for me in the past, before this recent
> vec.h
On Sun, Nov 18, 2012 at 9:12 AM, Diego Novillo wrote:
> On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson
> wrote:
>> On Sat, 17 Nov 2012, Diego Novillo wrote:
>>> I have now committed all 25 parts of this patch as rev 193595. Please
>>> CC me on any problems that you think may be related to
On Sun, 18 Nov 2012, Andreas Tobler wrote:
> Is there a minimum gcc to bootstrap current trunk?
> I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
> succeeds.
A gcc-4.1.2 has worked for me in the past, before this recent
vec.h change. I think that's the minimum version reportedly
w
Just a comment about tsan.
Today, tsan works *only* on x86_64 linux (no 32-bits, no non-linux).
Other 64-bit platforms may be doable, but not as easy as for asan.
Non-linux is harder than non-x86_64 (need to support tons of libc interceptors).
32-bit platforms are very hard to port to, I would not
> OK, here are multiple issues.
> 1) recursive inlining makes huge loop nest (of 18 loops)
> 2) SCEV is very slow on answering simple_iv tests in this case becuase it
> walks the nest
> 3) unroller is computing loop body size even when it is clear the body is
> much larger than the limit (the outer
On 18.11.12 18:05, Hans-Peter Nilsson wrote:
> On Sat, 17 Nov 2012, Diego Novillo wrote:
>> I have now committed all 25 parts of this patch as rev 193595. Please
>> CC me on any problems that you think may be related to this rewrite.
>
> That seems to have trigged some bug in gcc-4.4-era. See
>
On Sun, Nov 18, 2012 at 12:43 PM, Hans-Peter Nilsson wrote:
> On Sun, 18 Nov 2012, Diego Novillo wrote:
>> My cris-elf builds worked fine, but config-list.mk only builds stage
>> 1, it does not build libgfortran. Can you give me instructions on how
>> to build your target on my x86 workstation?
>
On Sun, 18 Nov 2012, Diego Novillo wrote:
> My cris-elf builds worked fine, but config-list.mk only builds stage
> 1, it does not build libgfortran. Can you give me instructions on how
> to build your target on my x86 workstation?
Better see the PR for cc1 command-line and preprocessed C-file.
b
Eric Botcazou writes:
>> OK. The current recursive force-mem-to-reg cases in store_bit_field_1
>> and extract_bit_field_1 don't handle -fstrict-volatile-bitfields at all,
>> so this patch was trying to fix what seemed like an oversight. Is it OK
>> to leave the code as-is (not handling -fstrict-
Eric Botcazou writes:
>> This patch replaces:
>>
>> /* Stop if the mode is wider than the alignment of the containing
>> object.
>>
>> It is tempting to omit the following line unless STRICT_ALIGNMENT
>> is true. But that is incorrect, since if the bitfield uses part
>>
Eric Botcazou writes:
>> get_best_mode has various checks to decide what counts as an acceptable
>> bitfield mode. It actually has two copies of them, with slightly different
>> alignment checks:
>>
>> MIN (unit, BIGGEST_ALIGNMENT) > align
>>
>> vs.
>>
>> unit <= MIN (align, BIGGEST_ALIGNM
Richard Henderson writes:
> On 11/15/2012 04:10 AM, Richard Sandiford wrote:
>> "next" was supposed to be "find and return another mode" rather than "++".
>> Did you think it was confusing because "next" sounded too much like
>> the latter?
>
> I wasn't keen on "next" being find-and-return, though
On Sun, Nov 18, 2012 at 12:05 PM, Hans-Peter Nilsson wrote:
> On Sat, 17 Nov 2012, Diego Novillo wrote:
>> I have now committed all 25 parts of this patch as rev 193595. Please
>> CC me on any problems that you think may be related to this rewrite.
>
> That seems to have trigged some bug in gcc-4
> > > this patch reduces max-peeled-insns and max-completely-peeled-insns from
> > > 400
> > > to 100. The reason why I am doing this is that I want to reduce code
> > > bloat
> > > caused by my cunroll work that enabled a lot more unrolling then
> > > previously
> > > causing considerable code
On Sat, 17 Nov 2012, Diego Novillo wrote:
> I have now committed all 25 parts of this patch as rev 193595. Please
> CC me on any problems that you think may be related to this rewrite.
That seems to have trigged some bug in gcc-4.4-era. See
PR55381. There are a lot of suspicious warnings from v
> Hi,
>
> PR 55260 contains two testcases which trigger two different bugs in
> ipa-cp.c. The first problem is that at one place in
> find_aggregate_values_for_callers_subset we use variable info instead
> of caller_info when determining whether a callee is a clone which then
> leads to an ICE.
> > this patch reduces max-peeled-insns and max-completely-peeled-insns from 400
> > to 100. The reason why I am doing this is that I want to reduce code bloat
> > caused by my cunroll work that enabled a lot more unrolling then previously
> > causing considerable code size regression at -O3.
>
>
On Sun, Nov 18, 2012 at 7:59 AM, Hans-Peter Nilsson wrote:
> 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,$(BUILD_CONFIG)),)
>> >> +LIBASAN_
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,$(BUILD_CONFIG)),)
+LIBASAN_LIBS=-B$$r/p
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,$(BUILD_CONFIG)),)
> >> +LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
> >> +endi
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-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
>> +endif
>> +@endif gcc-bootstrap
>
> Do you need this
On Sun, 18 Nov 2012, Tobias Burnus wrote:
> I intent to commit the attached patch, but wouldn't mind if someone had first
> a look at the configure/host handling for the rounding.
The default in libquadmath should be to use fegetround to get the rounding
mode, not fpu_control.h or other architec
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,
On Fri, Nov 16, 2012 at 6:29 PM, Ian Lance Taylor wrote:
> On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo wrote:
>> 2012-11-15 Diego Novillo
>>
>> Adjust for new vec API
>> (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec)
>>
>> * c-common.c: Use new vec API in vec.h.
>>
> Did you notice that gcc.c-torture/compile/pr43186.c regressed? It now again
> takes a while to compile, so times out on slow machines:
> ...
On a 2.5Ghz Core2Duo, compiling the test with revision 192891 (2012-10-28)
takes a small fraction of a second, while with revision 193270 (2012-11-06)
it
Tejas Belagod writes:
> Hi,
>
> I seem to have uncovered what seems to be a bug with handling SUBREG (MEM)
> with
> the MEM having side-effects while testing aarch64-4.7. This bug seems to be
> latent on trunk.
>
> Here is a test case reduced from gcc.c-torture/execute/scal-to-vec1.c.
>
> #defin
Tom de Vries writes:
> 2012-11-17 Tom de Vries
>
> PR rtl-optimization/55315
>
> * rtlanal.c (nonzero_address_p): Don't assume a nonzero address plus a
> const is a nonzero address.
>
> * gcc.target/mips/pr55315.c: New test.
OK, thanks.
Richard
Matthias Klose writes:
> 2012-11-14 Matthias Klose
>
> * config/mips/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
OK, thanks.
Richard
> 2012-11-15 Diego Novillo
>
> Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec)
>
> * gcc-interface/decl.c: Use new vec API in vec.h.
> * gcc-interface/gigi.h: Likewise.
> * gcc-interface/trans.c: Likewise.
> * gcc-interface/utils.c: Likewis
> this patch reduces max-peeled-insns and max-completely-peeled-insns from 400
> to 100. The reason why I am doing this is that I want to reduce code bloat
> caused by my cunroll work that enabled a lot more unrolling then previously
> causing considerable code size regression at -O3.
Did you not
53 matches
Mail list logo
