I'm approving Bernd's patch referenced here:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00421.html
I've added a comment why we're ignoring the REG_DEAD notes for this
particular case with a pointer back to the PR. I've also added a test
to the testsuite.
A prior discussion can be found
On 18/01/2013, at 2:18 PM, Mike Stump wrote:
> On Jan 17, 2013, at 5:05 PM, rbmj wrote:
>> On 05-Jan-13 23:18, rbmj wrote:
>>> On 06-Dec-12 10:14, rbmj wrote:
On 26-Nov-12 13:27, rbmj wrote:
> On 11/13/2012 10:22 PM, rbmj wrote:
>> On 11/5/2012 12:57 PM, rbmj wrote:
>>> This remo
On Jan 17, 2013, at 5:05 PM, rbmj wrote:
> On 05-Jan-13 23:18, rbmj wrote:
>> On 06-Dec-12 10:14, rbmj wrote:
>>> On 26-Nov-12 13:27, rbmj wrote:
On 11/13/2012 10:22 PM, rbmj wrote:
> On 11/5/2012 12:57 PM, rbmj wrote:
>> This removes warnings about implicit declarations and fixes one
On 05-Jan-13 23:18, rbmj wrote:
On 06-Dec-12 10:14, rbmj wrote:
On 26-Nov-12 13:27, rbmj wrote:
On 11/13/2012 10:22 PM, rbmj wrote:
On 11/5/2012 12:57 PM, rbmj wrote:
This removes warnings about implicit declarations and fixes one of the
function calls in vxlib-tls.c for vxworks targets.
I g
On Fri, Jan 18, 2013 at 12:45:06AM +0100, Steven Bosscher wrote:
> --- testsuite/gcc.target/i386/pr55934.c (revision 0)
> +++ testsuite/gcc.target/i386/pr55934.c (revision 0)
> @@ -0,0 +1,10 @@
> +/* PR inline-asm/55934 */
> +/* { dg-do compile } */
> +/* { dg-require-effective-target sse } */
Don
Hello Vlad,
Attached is my attempt to fix PR55934, an error recovery issue in LRA
with incorrect constraints in an asm.
I'm not 100% sure this is all correct (especially the LRA insn data
invalidating in lra-assigns.c) but it appears to fix the PR without
introducing test suite failures.
Can you
On Fri, Jan 18, 2013 at 01:19:37AM +0200, Janne Blomqvist wrote:
>
> the attached patch gets rid of the "enum try" in the Fortran runtime
> library, replacing its usage with the standard C99 _Bool/bool.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> 2013-01-18 Janne Blomqvist
>
Hi Jürgen,
> > Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit
> > data type is involved. Of course that also requires a 64-bit ABI, either
> > n64 or n32, as these are 64-bit instructions -- from what you wrote thus
> > far I've gathered, perhaps incorrectly, that yo
On 17 January 2013 15:48, Michael Witten wrote:
> The documentation here:
>
> http://gcc.gnu.org/install/download.html
>
> says:
>
> It is possible to download a full distribution or
> specific components... If you choose to download
> specific components, you must download the core
> GCC
Hello Maciej,
> > > Please note that the issue of LLD and SCD remains open -- these
> > > instructions are a part of the base MIPS III 64-bit ISA and therefore
> they
> > > are assumed by glibc and elsewhere to be present, and they are not
> > > emulated by Linux. So not only you'll have to fi
On Wed, Jan 16, 2013 at 4:21 PM, Cary Coutant wrote:
>
> > 2013-01-16 Sterling Augustine
> >
> > * gcc/dwarf2out.c (resolve_addr): Delete call to
> > remove_addr_table_entry.
>
> OK for google/gcc-4_7. The commit log entry should say "Google ref:
> b/8013197" instead of "PR ..."
On Jan 16, 2013, Jakub Jelinek wrote:
> for i686-linux tree-ssa-pre.o is different, and
> for x86_64-linux go/export.o is different.
I looked into the latter first, and that revealed a few major bugs:
1. I'd failed to fully implement what I'd planned. The canonicalization
function would still
On Jan 17, 2013, at 12:39 PM, Jack Howarth wrote:
> The attached revised patch disables three asan tests introduced in r194458
> which are invalid on darwin.
> Okay for gcc trunk?
Ok.
The attached revised patch disables three asan tests introduced in r194458
which are invalid
on darwin. The g++.dg/asan/interception-test-1.C test should be dg-skip-if'd on
darwin since
mac function interposition is used instead of interception. The
c-c++-common/asan/swapcontext-test-1.c
tes
On Fri, Jan 18, 2013 at 3:39 AM, Mike Stump wrote:
> On Jan 17, 2013, at 11:11 AM, minux...@gmail.com wrote:
>> some systems (notably NetBSD), doesn't place the path where libgmp,
>
> I think gcc should try and build and run a gmp program and fail to configure
> if the binary can't also run. Thi
On Jan 17, 2013, at 11:11 AM, minux...@gmail.com wrote:
> some systems (notably NetBSD), doesn't place the path where libgmp,
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
On Jan 17, 2013, at 11:11 AM, minux...@gmail.com wrote:
> I assume all the linkers that gcc bootstraps with have support for
> the -rpath flag.
I don't know that that is true either.
On Thu, Jan 17, 2013 at 07:11:12PM +, minux...@gmail.com wrote:
> Reviewers: bonzini_gnu.org, dj_redhat.com, neroden_gcc.gnu.org,
> aoliva_redhat.com, ralf.wildenhues_gmx.de,
>
> Message:
> some systems (notably NetBSD), doesn't place the path where libgmp,
> libmpfr, libmpc resides into /etc/
Reviewers: bonzini_gnu.org, dj_redhat.com, neroden_gcc.gnu.org,
aoliva_redhat.com, ralf.wildenhues_gmx.de,
Message:
some systems (notably NetBSD), doesn't place the path where libgmp,
libmpfr, libmpc resides into /etc/ld.so.conf, and instead rely on
the binary providing correct -rpath; this pat
Reviewers: gerald_pfeifer.com, joseph_codesourcery.com,
Message:
two trivial typo fixes.
Description:
2013-01-16 Shenghou Ma
* doc/invoke.texi: fix typo.
* doc/objc.texi: fix typo.
PS: my copyright assignment id is 782920.
Please review this at https://codereview.appspot.c
Hi!
If target (the real part thereof) overlap op1 (i.e. the imag part of
COMPLEX_EXPR
to be stored), we end up with first overwriting the real part and then
using wrong value in op1.
Fixed by testing for overlap, and either, if possible, doing the writes
in different order if overlap is detected
On 2013-01-16 20:16, Alexandre Oliva wrote:
Be conservative about negative sizes on symbols, use abs elsewhere
From: Alexandre Oliva
for gcc/ChangeLog
PR rtl-optimization/55547
PR rtl-optimization/53827
PR debug/53671
PR debug/49888
* alias.c (memrefs_c
On 2013-01-16 18:40, Alexandre Oliva wrote:
That said, I question the change of <= to == 0. If negative, we don't
know how much overlap there is as far as I can see.
Why not? Since the addresses are constants, and the negative sizes are
just the adjusted sizes, negated to indicate they were c
Hi Janis,
> 2013-01-16 Janis Johnson
>
>* gcc.target/arm/ftest-support.h: Replace for compile-only tests.
>* gcc.target/arm/ftest-support-arm.h: Delete.
>* gcc.target/arm/ftest-support-thumb.h: Delete.
>* gcc.target/arm/ftest-armv4-arm.c: Replace with compile-only test.
>*
Hi Janis,
Now I get it. This version is more selective about which multilibs
are skipped. I tested it by using multilib test flags for all valid
values for -march, with and without -mthumb as appropriate for the
arch. The ones that are now skipped are the ones that used to fail
with complaint
On Thu, Jan 17, 2013 at 2:18 PM, Kumar, Venkataramanan wrote:
> Hi Honza,
>
> There is no change when I find top 10 symbols using nm -t d --size-sort ./cc1
> | c++filt | tail.
More interesting would be the output of genautomata with the "-stats" flag.
Ciao!
Steven
Hi Honza,
There is no change when I find top 10 symbols using nm -t d --size-sort ./cc1 |
c++filt | tail.
Before and after the patch is same.
(snip)
00085808 B default_target_expmed
00093960 r bdver3_fp_transitions
00098957 T c_common_nodes_and_builtins()
001077
On 17/01/13 13:10, Yufeng Zhang wrote:
Hi,
The attached patch fixes a bug in the AArch64 __clear_cache
implementation in which the loop iterating through the cache lines to
clear started from the first address to clear, incrementing by the size
of the cache line, and potentially missing to clear
Hi,
The attached patch fixes a bug in the AArch64 __clear_cache
implementation in which the loop iterating through the cache lines to
clear started from the first address to clear, incrementing by the size
of the cache line, and potentially missing to clear the last cache line.
Patch passes
On 15.01.2013 17:31, Janis Johnson wrote:
On 01/14/2013 03:04 PM, Janis Johnson wrote:
Test gcc.target/arm/neon-vld1_dupQ.c started failing with r194594, a C
front end change that causes the test to get warnings. The test passes
local variables of type int64x1_t to functions declared with argum
> On Thu, Jan 17, 2013 at 8:17 AM, Kumar, Venkataramanan
> wrote:
> > Hi Maintainers,
> >
> > This patch adds pipeline descriptions for -march=btver2.
> >
> > Completed bootstrap and gcc regression test passes with r194705
> >
> > Is this ok for trunk?
> >
> >
> > Change log
> > --
>
On Thu, Jan 17, 2013 at 12:59 PM, Jakub Jelinek wrote:
> Hi!
>
> Is it ok to backport
> https://github.com/atgreen/libffi/commit/0de3277b18cf54be3b81d509b9be9b47d9bc1e82
> fix from upstream to gcc's libffi copy? The tests fail on various targets.
Ok.
Thanks,
Richard.
> 2013-01-07 Thorsten Gla
Hi!
Is it ok to backport
https://github.com/atgreen/libffi/commit/0de3277b18cf54be3b81d509b9be9b47d9bc1e82
fix from upstream to gcc's libffi copy? The tests fail on various targets.
2013-01-07 Thorsten Glaser
* testsuite/libffi.call/cls_uchar_va.c,
testsuite/libffi.call/cls_us
On Wed, Jan 16, 2013 at 5:13 PM, Jan Hubicka wrote:
> Hi,
> this patch fixes ICE seen in PR51083 on PPC. Here the flags ^= 0x8000
> expression
> is translated as PLUS. This makes us to consider flags to be IV and work out
> that the
> loop do not really iterate. It is a missed optimizati
Apologies for this post linking to the thread only by subject - the
maillist archive does not appear to contain references which would allow
this post to link solidly. (I've only subscribed a few minutes ago.)
On: Mon, 07 Jan 2013 20:59:03 +0100, Georg-Johann Lay wrote:
(In http://gcc.gnu.org/ml/g
On 17 January 2013 07:53, Daniel Krügler wrote:
> 2013/1/17 Jonathan Wakely :
>> This fixes a regression since 4.6 when -Wsystem-headers is used. The
>> initialization of the __atomic_flag_base base class has a narrowing
>> conversion from int (the macro) to either bool or unsigned char. The
>>
36 matches
Mail list logo
