On May 2, 2012, at 11:45 PM, Richard Henderson wrote:
> On 05/02/2012 12:26 PM, Steven Bosscher wrote:
>>> * config/alpha/vms.h (SUBTARGET_OVERRIDE_OPTIONS): For pic code,
>>> unset flag_jump_tables.
>>> * stmt.c (expand_case): Remove special flag_pic case conditional
>>>
On May 2, 2012, at 9:12 PM, Steven Bosscher wrote:
> Hello,
>
> alpha-vms is the only target that does not define
> ASM_OUTPUT_ADDR_DIFF_ELT. That makes the code in stmt.c to handle this
> case alpha-vms specific. But there is a better way to handle this:
> Just mimic -fno-jump-tables if flag_pi
On Wed, 2 May 2012, Jakub Jelinek wrote:
> Hi!
>
> single_nonlooparound_use ignores debug uses (otherwise we end up with
> -fcompare-debug failures), but when removing stmts we need to reset
> the debug uses, otherwise e.g. the testcase below ICEs. Alex, if you have
> better ideas how to reconst
On Apr 30, 2012, at 16:18 , Olivier Hainque wrote:
>> Can you formally relate those three representations and tell me why
>> VIEW_CONVERT_EXPR is useful (not only convenient because of less operands)
>> to use on lvalues (thus memory, compared to registers or constants)?
>
> I have ideas on how t
On Wed, May 2, 2012 at 11:46 PM, Marc Glisse wrote:
> Hello,
>
> I definitely don't expect the attached patch to be accepted, but I would
> like some advice on the direction to go, and a patch that passes the
> testsuite and does the optimization I want on a couple testcases seems like
> it may he
This fixes PR53144 - we were assigning a constant value-id to a
non-constant value. That breaks bitmap set invariants and thus
we end up endlessly inserting things. Oops.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and branch.
Richard.
2012-05-03 Richard Guenther
Hello,
Throwing away dominance info is wasteful if it is so easy to fix. The
immediate dominators are easily known, and iterate_fix_dominators()
can take care of the rest.
And if we're doing to free post-dominance info anyway, do it early to
save some work.
Bootstrapped&tested on x86_64-unknown-
David Miller writes:
> From: Richard Sandiford
> Date: Wed, 02 May 2012 20:37:58 +0100
>
>> I think the DSE assuption is fair though. If you reuse MEMs like
>> this, then they're no longer just serving the purpose described by
>> MEM_EXPR.
>
> The following seems to work, and matches what calls.
On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
wrote:
> David Miller writes:
>> From: Richard Sandiford
>> Date: Wed, 02 May 2012 20:37:58 +0100
>>
>>> I think the DSE assuption is fair though. If you reuse MEMs like
>>> this, then they're no longer just serving the purpose described by
>>>
On Thu, May 3, 2012 at 10:29 AM, Steven Bosscher wrote:
> Hello,
>
> Throwing away dominance info is wasteful if it is so easy to fix. The
> immediate dominators are easily known, and iterate_fix_dominators()
> can take care of the rest.
>
> And if we're doing to free post-dominance info anyway, d
Hi,
here is a port of Android support patch
(http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00944.html) for
google/gcc-4_6_2-mobile branch. Is it OK?
Bootstrapped on linux-x86_64. Successfullly used for NDK release build
and Android ICS build.
Thanks,
Ilya
---
2012-05-03 Enkovich Ilya
Richard Guenther writes:
> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
> wrote:
>> David Miller writes:
>>> From: Richard Sandiford
>>> Date: Wed, 02 May 2012 20:37:58 +0100
>>>
I think the DSE assuption is fair though. If you reuse MEMs like
this, then they're no longer just
From: Richard Guenther
Date: Thu, 3 May 2012 10:42:30 +0200
> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
> wrote:
>> David Miller writes:
>>> From: Richard Sandiford
>>> Date: Wed, 02 May 2012 20:37:58 +0100
>>>
I think the DSE assuption is fair though. If you reuse MEMs like
>>>
From: Richard Sandiford
Date: Thu, 03 May 2012 10:17:44 +0100
> Richard Guenther writes:
>> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
>> wrote:
>>> David Miller writes:
From: Richard Sandiford
Date: Wed, 02 May 2012 20:37:58 +0100
> I think the DSE assuption is fai
Committed as obvious.
Richard.
2012-05-03 Richard Guenther
* gfortran.dg/pr52621.f90: Add -w to avoid diagnostic about
unsupported prefetching support.
Index: gcc/testsuite/gfortran.dg/pr52621.f90
===
--- gcc/te
Dear all,
attached you find a patch for a -std=f95 diagnostic issue related to
F2003 constructors, which is a 4.7/4.8 rejects-valid regression.
It was build and regtested on x86-64-linux.
OK for 4.7 and the trunk?
Note that a valid-F95 special case is still rejected with -std=f95 (cf.
attach
On Thu, May 3, 2012 at 11:38 AM, David Miller wrote:
> From: Richard Sandiford
> Date: Thu, 03 May 2012 10:17:44 +0100
>
>> Richard Guenther writes:
>>> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
>>> wrote:
David Miller writes:
> From: Richard Sandiford
> Date: Wed, 02 Ma
From: Richard Guenther
Date: Thu, 3 May 2012 11:48:03 +0200
> calls.c is unsafe, too. Which is probably why making DSE stronger for
> calls using the usual alias predicates did not work.
Well, when calls.c does something more sophisticated we can do similarly
for cases like sparc's libcalls.
On Fri, Apr 27, 2012 at 2:43 PM, Paolo Bonzini wrote:
> Il 27/04/2012 13:16, Richard Guenther ha scritto:
>> In optabs.c we compare the CTZ_DEFINED_VALUE_AT_ZERO against two,
>> is != 0 really what you want here? The docs suggest to me
>> that as you are using the optab below you should compare a
On Fri, Apr 27, 2012 at 2:31 PM, Andrew MacLeod wrote:
> On 04/27/2012 04:37 AM, Richard Guenther wrote:
>>
>> Since integral atomics are always of an unsigned type , I could switch
>> over
>> and use 'unsigned size' instead of 'tree fntype' for them (I will rename
>> it), but then things may be
Hi!
On Wed, May 02, 2012 at 07:37:15PM +0400, Kirill Yukhin wrote:
> > Otherwise, this looks good.
> Thanks, I've applied inputs!
>
> Comitted to MT: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00047.html
As I mentioned in http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00730.html
this doesn't really
On Thu, May 3, 2012 at 12:05 PM, Jakub Jelinek wrote:
> On Wed, May 02, 2012 at 07:37:15PM +0400, Kirill Yukhin wrote:
>> > Otherwise, this looks good.
>
>> Thanks, I've applied inputs!
>>
>> Comitted to MT: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00047.html
>
> As I mentioned in http://gcc.gnu.
Hi!
During testing with older gas I've noticed failures, where 0xf2 was a pasto
instead of the right 0xf3 for xrelease insn.
Fixed thusly, regtested on x86_64-linux and i686-linux, ok for trunk?
BTW, I wonder if dg-options shouldn't select -march=i686 for !lp64,
if somebody configures gcc to def
Bin Cheng wrote:
> Thanks for reviewing, I modified the ChangeLog. Is it ok for trunk and 4.7?
Yes, this is OK for trunk.
Once it has been in trunk for a week or so and nobody reported any regressions,
it would also be OK to backport to 4.7.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolch
Hello,
This is a followup on an old issue first discussed at
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01290.html
The original problem is still visible today:
<< While some target linkers silently replace read-only output files,
others report an error in such circumstances. [...]
col
On Thu, May 3, 2012 at 12:08 PM, Jakub Jelinek wrote:
> During testing with older gas I've noticed failures, where 0xf2 was a pasto
> instead of the right 0xf3 for xrelease insn.
>
> Fixed thusly, regtested on x86_64-linux and i686-linux, ok for trunk?
>
> BTW, I wonder if dg-options shouldn't se
Hello,
Ping for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00661.html
Thanks in advance,
Olivier
On Apr 11, 2012, at 16:43 , Olivier Hainque wrote:
> We sometimes get to invoke Makefile targets with a CC variable value
> containing
> spaces (for extra options, typically). This causes failur
On Wed, May 2, 2012 at 4:06 PM, Tom de Vries wrote:
> On 27/04/12 11:01, Richard Guenther wrote:
>
>> I see you do not handle
>
>> struct S { int i; };
>> struct S foo (void);
>> struct S bar (void)
>> {
>> struct S s1, s2;
>> if (...)
>> s = foo ();
>>
Il 03/05/2012 11:57, Richard Guenther ha scritto:
> Hmm, I'll let target maintainers have a look at this - it's non-obvious
> for arm (the only case I looked at) at least. My guess is that the
> difference was to allow __builtin_ctz to be "optimized" and CTZ
> to be always well-defined (which inci
On Thu, May 3, 2012 at 10:21 AM, Olivier Hainque wrote:
>
> On Apr 30, 2012, at 16:18 , Olivier Hainque wrote:
>>> Can you formally relate those three representations and tell me why
>>> VIEW_CONVERT_EXPR is useful (not only convenient because of less operands)
>>> to use on lvalues (thus memory,
Hello,
Ping for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00274.html
Thanks in advance,
Olivier
On Apr 5, 2012, at 14:54 , Olivier Hainque wrote:
...
> install-no-fixedincludes remains a useful Makefile target
> and it misbehaves in two ways:
>
> 1) past the second invocation, it rebuilds
On Thu, May 3, 2012 at 11:52 AM, David Miller wrote:
> From: Richard Guenther
> Date: Thu, 3 May 2012 11:48:03 +0200
>
>> calls.c is unsafe, too. Which is probably why making DSE stronger for
>> calls using the usual alias predicates did not work.
>
> Well, when calls.c does something more sophi
Hi Joseph,
>
> On Tue, 17 Apr 2012, Terry Guo wrote:
>
> > 2012-04-17 Terry Guo
> >
> > * Makefile.in (s-mlib): Add new argument MULTILIB_REQUIRED.
> > * genmultilib (MULTILIB_REQUIRED): New.
>
> You need to add documentation in fragments.texi for MULTILIB_REQUIRED.
>
Thanks
Hello,
Ping for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00298.html
Thanks in advance,
Olivier
On Apr 5, 2012, at 17:30 , Olivier Hainque wrote:
...
> The original problem we had with this was the introduction of an
> artificial race condition in addition to the potential performance
> impa
Hi!
This patch fixes ICE in arm_select_dominance_cc_mode during combine,
which tries to match some rtl expression which has (unlt:SI (reg:CCFPE cc)
(const_int 0))
deep inside it (the match will fail), during simplification SELECT_CC_MODE is
used
and as arm_select_cc_mode returns CCmode for the u
Hi,
Here is updated version of patch. I added comments describing the algorithm.
> Hi Dinar. I'm afraid it gives the wrong results for some dividends
> * 82625484914982912 / 2023346444509052928: gives 4096, should be zero
> * 18317463604061229328 / 2023346444509052928: gives 4109, should be 9
>
Hello,
Ping for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00808.html
Thanks in advance,
Olivier
On Apr 13, 2012, at 10:08 , Olivier Hainque wrote:
...
> Relocation troubles (24bit reloc overflows) might show up when module
> instructions contain short references to kernel symbols and the mod
Hi!
What gcc-ar does to find the plugin is significantly different from
what gcc driver does. This patch makes it behave tiny bit closer to
what the driver does, in particular if GCC_EXEC_PREFIX isn't defined
in the environment, it will use standard_libexec_prefix if
gcc-{ar,nm,ranlib} program li
On Thu, May 3, 2012 at 12:49 PM, Jakub Jelinek wrote:
> Hi!
>
> What gcc-ar does to find the plugin is significantly different from
> what gcc driver does. This patch makes it behave tiny bit closer to
> what the driver does, in particular if GCC_EXEC_PREFIX isn't defined
> in the environment, it
On 05/03/2012 03:27 AM, Paolo Carlini wrote:
Hi,
Vincenzo reported today that the work done by Roberto on
devirtualizing final methods, doesn't cover operators (of all sorts).
Thus I prepared the below, which passes the testsuite on x86_64-linux.
... I have an alternate proposal, which probabl
On Thu, 3 May 2012, Terry Guo wrote:
> Thanks for your reminding.
> The attached patch added the missing documentation. Please help to review.
Please send the complete new patch, including documentation, for review
(unless the rest has been reviewed).
> +@item MULTILIB_REQUIRED
> +Sometimes wh
When looking at PR53168 I noticed that clean () can be optimized
and simplified quite a bit. Likewise that we do not dump whether
we find a partial or a partial partial redundancy, nor dump
the insert iteration. Also dumping the PRE sets is tedious
from inside gdb so this adds a debug function t
Hi,
This patch was reverted because of performance degradation. However,
it turns out to be an innocent performance loss. Thus we want to
reenable it in google branches.
Passed bootstrap and gcc regression tests and google performance tests.
OK for google branch?
Thanks,
Dehao
gcc/ChangeLog.go
On Thu, May 3, 2012 at 12:17 PM, Uros Bizjak wrote:
>> BTW, I wonder if dg-options shouldn't select -march=i686 for !lp64,
>> if somebody configures gcc to default to -march=i386, I guess xadd etc.
>> won't be emitted there.
>
> You can add -march=x86-64 unconditionally to these test. This arch i
Hello,
Ping for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00833.html
Thanks in advance,
Olivier
On Apr 13, 2012, at 15:06 , Olivier Hainque wrote:
> For several years now, Ada has support for a "Persistent_BSS" pragma
> that let users place data in a ".persistent.bss" section. This section:
Hello!
This #define is the same as in generic config/elfos.h.
2012-05-03 Uros Bizjak
* config/alpha/elf.h (MAX_OFILE_ALIGNMENT): Remove.
Tested on alphaev68-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: config/alpha/elf.h
=
Hi Joseph,
>
> On Thu, 3 May 2012, Terry Guo wrote:
>
> > Thanks for your reminding.
> > The attached patch added the missing documentation. Please help to
> review.
>
> Please send the complete new patch, including documentation, for review
> (unless the rest has been reviewed).
>
> > +@item
On Thu, 3 May 2012, Terry Guo wrote:
> 2012-05-03 Terry Guo
>
> * Makefile.in (s-mlib): Add new argument MULTILIB_REQUIRED.
> * genmultilib (MULTILIB_REQUIRED): New.
> * doc/fragments.texi: Document the MULTILIB_REQUIRED.
This is OK, with copyright dates on genmultilib
This moves handling of trapping ops to prune_clobbered_mems and
compute_avail, similar to how I moved handling of clobbered mems
earlier. It fixes one existing testcase even.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-05-03 Richard Guenther
* tree-s
Hi,
this removes the XXXs I added with my prev/next shuffling. A reason for
some conditionals in iterator setups is that ENTRY/EXIT bbs don't have
il.gimple setup, while all other blocks have it always initialized (well,
as long as !BB_RTL of course). That annoyed me, but instead of simply
a
What if we moved all the devirtualization logic from
build_new_method_call_1 to build_over_call?
Jason
On May 3, 2012, at 12:24 , Richard Guenther wrote:
>> One area of potential difference came to mind yesterday: regarding the
>> processing of type alignment differences. VCE to more aligned (of the
>> same size) would make a temp copy to yield a correctly aligned object.
>>
>> Would MEM_REF d
On 03/05/12 11:27, Dinar Temirbulatov wrote:
> Hi,
> Here is updated version of patch. I added comments describing the algorithm.
>
>> Hi Dinar. I'm afraid it gives the wrong results for some dividends
>> * 82625484914982912 / 2023346444509052928: gives 4096, should be zero
>> * 183174636040612
On 05/03/2012 03:08 PM, Jason Merrill wrote:
What if we moved all the devirtualization logic from
build_new_method_call_1 to build_over_call?
Doh, you are absolutely right, the below, very simple, appears to work
well. Probably I was afraid that we could have issues with the other
build_over_ca
OK. Seems safe enough for 4.7.1.
Jason
On 05/02/2012 09:14 AM, Richard Henderson wrote:
On 05/02/2012 05:48 AM, Andreas Krebbel wrote:
configure.ac:26: error: Please use exactly Autoconf 2.64 instead of 2.65.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:26: the top level
autom4te: m4 failed w
On Thu, May 3, 2012 at 3:08 PM, Michael Matz wrote:
> Hi,
>
> this removes the XXXs I added with my prev/next shuffling. A reason for
> some conditionals in iterator setups is that ENTRY/EXIT bbs don't have
> il.gimple setup, while all other blocks have it always initialized (well,
> as long as !
This patch was posted for comment back in February during stage 4. It
addresses a performance issue noted in the EEMBC routelookup benchmark
on a common idiom:
if (...)
x = y->left;
else
x = y->right;
If the two loads can be hoisted out of the if/else, the if/else can be
replaced by
On 05/03/2012 04:00 PM, Jason Merrill wrote:
OK. Seems safe enough for 4.7.1.
Applied, thanks!
Paolo.
On Thu, May 3, 2012 at 6:19 AM, Olivier Hainque wrote:
>> We sometimes get to invoke Makefile targets with a CC variable value
>> containing
>> spaces (for extra options, typically). This causes failure at some stages on
>> powerpc-aix from mh-ppc-aix which has
>>
>> LDFLAGS = `case $(CC) in *g
On Fri, Apr 27, 2012 at 2:43 PM, Paolo Bonzini wrote:
Interesting, first time I hear about this...
... except that no target sets the macros to 2, and all of them could
(as far as I could see). Looks like the code trumps the documentation;
how does this look?
"No target sets to 2"? You mean
On 05/03/2012 03:23 AM, Paolo Bonzini wrote:
- ctzsi4 expands to bitrev + clz:SI, so it will return 32 too. ctz:SI
will never appear at all in the RTX stream, so you can define its value
at zero to be whatever you want. Hence the correct valid of
CTZ_DEFINED_VALUE_AT_ZERO is also 2.
That's for
Il 03/05/2012 17:10, Richard Henderson ha scritto:
>>>
>>>
>>> ... except that no target sets the macros to 2, and all of them could
>>> (as far as I could see). Looks like the code trumps the documentation;
>>> how does this look?
>
> "No target sets to 2"? You mean like mips? You forgot to lo
On May 3, 2012, at 16:45 , David Edelsohn wrote:
>>> * config/mh-ppc-aix (LDFLAGS): Quote $(CC).
> Okay.
Committed, thanks :)
Make sure a match_dup will still match the generated pattern later,
I've had problems with match_dup not matching two rtx that
rtx_equals() says are "the same" but not physically the same.
On 05/03/2012 08:33 AM, William J. Schmidt wrote:
This patch was posted for comment back in February during stage 4. It
addresses a performance issue noted in the EEMBC routelookup benchmark
on a common idiom:
if (...)
x = y->left;
else
x = y->right;
If the two loads can be hoi
Hi,
Richi made some good points about my last patch, related to struct
rtl_bb_info. Even though it's not that important to shrink it (only few
BBs are in RTL mode) there's no need to waste space. My last patch
created an unused pointer-sized hole in RTL mode, which we can just as
well use fo
This patch to the Go frontend fixes the dependency analysis for code
like
func foo() (int, int)
var c = b
var a, b = foo()
This code used to crash the compiler because the initialization of c
would refer to b, which would build the call, and then the
initialization of a would not be able to see t
ok. Is the change in google-47 branch?
Please also submit this to trunk (there was also a previous one pending).
thanks,
David
On Thu, May 3, 2012 at 4:44 AM, Dehao Chen wrote:
> Hi,
>
> This patch was reverted because of performance degradation. However, it
> turns out to be an innocent perfo
In libstdc++/44015, there is a request for doxygen markup on template
parameters, including default arguments. This is a kind of markup that
libstdc++ has mostly not done, or done inconsistently.
So, here's how I think it should be done, at least for io and
containers.
See generated files here:
Hello,
How does one turn random volunteer GCC hackers into spoiled brats?
Give them Big Iron to play with, like IBM's donation to the compile
farm aka gcc110. If you do "make -k 64" on a machine like that, a GCC
build takes _minutes_, and that's so slooow...
Part of the problem is insn-at
On 05/03/2012 05:59 AM, Richard Guenther wrote:
the type can be removed from the structure and now there would be no
wastage. Is that reasonable?
types in ops is a bad idea (tried that once - heh), it wrecks too much generic
code.
heh, no doubt. As I Iooked at handling the generic atomics,
The first, reported by David re a ppc32 build failure. I don't understand
why gcc_no_link would be true in that case, but it does point out a real
bug. And possibly the same one that was reported against darwin overnight.
The second, pointed out by Jason re enabling maintainer mode.
Both commi
Hi,
a bit late, but I do have two tiny comments nevertheless...
On Mon, Apr 16, 2012 at 06:09:40PM +0200, Jan Hubicka wrote:
> Hi,
> this patch moves cgraph/varpool hashes into symbol table hashes, so the
> symbol table is actually almost a symbol table ;)
> Work done.
>
> Bootstrapped/regtested
On 05/03/2012 08:23 AM, Paolo Bonzini wrote:
Yeah, not as I posted... of course config/mips/mips.h needs change, but
do you disagree that all targets_do_ have the same value at zero for
the optab as they have for RTL?
I don't agree without a port-by-port review, no.
If, as you suggest, we ge
On Thu, 2012-05-03 at 09:40 -0600, Jeff Law wrote:
> On 05/03/2012 08:33 AM, William J. Schmidt wrote:
> > This patch was posted for comment back in February during stage 4. It
> > addresses a performance issue noted in the EEMBC routelookup benchmark
> > on a common idiom:
> >
> >if (...)
> >
From: Richard Guenther
Date: Thu, 3 May 2012 12:25:11 +0200
> On Thu, May 3, 2012 at 11:52 AM, David Miller wrote:
>> From: Richard Guenther
>> Date: Thu, 3 May 2012 11:48:03 +0200
>>
>>> calls.c is unsafe, too. Which is probably why making DSE stronger for
>>> calls using the usual alias pred
This patch to the Go frontend fixes a bug that can arise when a type in
package A inherits from a type in package B, where the type in package B
has a hidden method, and a third package C tries to convert the package
A type to the B interface type. The compiler was failing to generate
the required
On 05/03/2012 10:47 AM, William J. Schmidt wrote:
Yes and no. What's important is that you don't want to introduce page
faults (or less urgently, cache misses) by speculating the load. So the
patch is currently extremely constrained, and likely will always stay
that way. Only fields that are
Richard Guenther writes:
> On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidt
> wrote:
>> This patch allows us to recognize that even if the argument to memcpy lives
>> across the call, we can allocate it to a call-used register by reusing the
>> return value of the function.
>>
>> First, the patch
This patch adds functionality to libgcov to enable user applications to
collect profile data only in regions of interest. This is useful, for
example, to collect profile data from a long-running server only
during the time when it is serving requests.
Specifically, the new routines __gcov_reset wi
In trying to build machine specific versions of glibc with newer compilers, we
ran into a bug where the current glibc would not build on power6. This was due
to glibc using the __builtin_swap64 builtin. Power6 sets the
-mavoid-indexed-addresses option. The splitter that I wrote when I wrote the
I will commit this as obvious shortly. Bootstrapped and regression
tested x86_64-linux-gnu languages=all,ada,obj-c++
2012-05-03 Manuel López-Ibáñez
gcc/
* flags.h (flag_permissive): Do not declare.
c-family/
* c.opt (fpermissive): Add Var(flag_permissive).
gcc/
* diagno
On Thu, 2012-05-03 at 11:44 -0600, Jeff Law wrote:
> On 05/03/2012 10:47 AM, William J. Schmidt wrote:
> >>
> > Yes and no. What's important is that you don't want to introduce page
> > faults (or less urgently, cache misses) by speculating the load. So the
> > patch is currently extremely cons
On May 3, 2012, at 9:31 AM, Steven Bosscher wrote:
> How does one turn random volunteer GCC hackers into spoiled brats?
> Give them Big Iron to play with, like IBM's donation to the compile
> farm aka gcc110. If you do "make -k 64" on a machine like that, a GCC
> build takes _minutes_, and that's s
On Thu, May 3, 2012 at 12:59 AM, Xinyu Qi wrote:
>> From: Matt Turner [mailto:matts...@gmail.com]
>> To: Xinyu Qi
>> Cc: Ramana Radhakrishnan; GCC Patches
>> Subject: Re: [PING] iwMMXt patches
>>
>> On Tue, Apr 17, 2012 at 4:17 PM, Matt Turner wrote:
>> > Are these patches ready to go in? It look
Ping for this patch to always supply a mode to plus_constant:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
I've done a diff of the changes since the original test revision
(which was r186448 FWIW) and there's only been one plus_constant-
related change since then: Alan's rs6000 pro
I've recently started getting “libstdc++-v3/include/functional:2057:63:
internal compiler error: tree check: expected tree_vec, have error_mark
in comp_template_args_with_info, at cp/pt.c:7038” on i686-linux-gnu,
building libstdc++-v3/src/c++11/functexcept.cc -fPIC, at stage1 and on
non-bootstrappe
On 05/03/2012 12:11 PM, William J. Schmidt wrote:
However, from the wiki page I see: "A speculative load which has its
results thrown away are considered to not have changed the semantics of
the program, and are therefore allowed." That seems to cover the case
here: the load is hoisted, but i
My recent patch for PR48866, that introduced dead_debug_insert_temp()
with DEBUG_TEMP_BEFORE_WITH_VALUE as a possibility for keeping
expressions about to be DCE'd, caused regressions on ppc because it
would take MEMs with autoinc addressing modes, which would be rejected
down the road.
This patch
A PRIVATE module variable, which is used in the specification expression
of a function result variable cannot be TREE_PUBLIC()=0, unless the
function itself is PRIVATE and also not accessible via type-bound
procedures or a generic name. (The issue is gfortran specific as most
compilers do not s
On May 2, 2012, Michael Matz wrote:
> my gimple_seq reshuffling broke boostrap on some machines. In particular
> on those for which contrib/compare-debug works, meaning that
> bootstrap-debug is selected as default BUILD_CONFIG (none of my machines
> pass the respective configure.ac test, an
Hi,
this patch fixes one place where I misupdated cgraph_remove_unreachable_nodes
while removing
reachable flag.
Bootstrapped/regtested x86_64-linux and comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 187113)
+++ Cha
Hi,
this patch fixes a bug I apparently intoduced while updating the code for new
alias API.
Instead of creating alias of emutls var it now creates alias of target var that
leads
to ICE later (or a wrong code when ICE is worked around).
Bootstrapped/regtested x86_64-linux with emutls and comitte
On 05/03/2012 11:15 AM, Richard Sandiford wrote:
Ping for this patch to always supply a mode to plus_constant:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
Ok.
r~
Richard Sandiford wrote:
Ian Lance Taylor writes:
Richard Sandiford writes:
Does anyone else have any thoughts before I make that change?
I think that one of you should try to write a test case where it makes a
difference, and add the test case to the testsuite.
I originally took that to m
Here's the patch to perform that optimization I was talking about on the
DWARF list: if we have multiple sig8 or symbolic references to another
type, build up a local stub and redirect all the references there so
that we are left with only one.
If we left a skeleton in this CU when we split ou
On 05/03/2012 09:31 AM, Steven Bosscher wrote:
+/* This gen* file is unique, in that it writes out multiple files.
+
+ Before GCC 4.8, insn-attrtab.c was written out containing many large
+ functions and tables. This made insn-attrtab.c_the_ bottle-neck in
+ a parallel build, and even mad
> Incidentally, I notice that we have unnecessary duplication in the type
> units. For instance, with nested-3.C:
>
> .uleb128 0x2 # (DIE (0x25) DW_TAG_namespace)
> .long .LASF0 # DW_AT_name: "thread"
> # DW_AT_declaration
> .long 0x34 # DW_AT
On 05/03/2012 04:17 PM, Cary Coutant wrote:
I believe I was just replicating the existing practice of putting
definitions at the top level, with a DW_AT_specification pointing to a
declaration DIE within the namespace/class hierarchy when necessary.
Yeah, I seem to remember there being a debugg
1 - 100 of 123 matches
Mail list logo
