Thanks Uros!
I think you mean the amdfam10 ISA mismatch between march=native and
march=amdfam10.
The below patch fills the gap.
"make -k check" passes.
Regards
Ganesh
2013-05-07 Ganesh Gopalasubramanian
* config/i386/i386.c (processor_alias_table): Mismatch in ISAs
Between march=na
On Tue, May 14, 2013 at 9:26 AM, Gopalasubramanian, Ganesh
wrote:
> I think you mean the amdfam10 ISA mismatch between march=native and
> march=amdfam10.
> The below patch fills the gap.
Yes, but please also review other AMD processor entries that possibly
miss these two flags.
Uros.
Hello!
> I would need a way to use GS segment register instead of FS for x86-64 for
> target RDOS since
> RDOS cannot use FS for TLS. It seems like the code related to this is
> concentrated to two
> different places:
> Especially the second reference would become hard-to-read if more
> condit
> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.
Let's remove the FIXME instead. Applied to mainline.
2013-05-14 Eric Botcazou
* config/sparc/sp64-elf.h (CPP_SUBTARGET_SPEC): Delete.
* config/sparc/openbsd64.h (CPP_SUBTARGET_SPEC): Likew
On Mon, 13 May 2013, Jakub Jelinek wrote:
> On Fri, May 10, 2013 at 07:15:38PM +0200, Jan Hubicka wrote:
> > It seems to me that it is not different from normalizing reg-10 into
> > reg+(-10)
> > we do for years (and for good reason). It is still target preference when
> > use
> > add and when
On Mon, 13 May 2013, Richard Biener wrote:
>
> This fixes a virtual SSA updating problem with sinking clobbers.
> Namely when sinking into a block with multiple predecessors and
> no virtual use we lack a convenient PHI node that serves as a
> merge of the virtual operands from the predecessors.
On Tue, May 14, 2013 at 08:58:55AM +0200, Uros Bizjak wrote:
> I think that the option should be named -mtarget-builtins.
There shouldn't be an option for it at all. If constructing the builtins is
slow (it is), we should just create them lazily, the
*builtin_decl_{explicit,implicit}* APIs were a
On Mon, May 13, 2013 at 7:23 PM, DJ Delorie wrote:
>
>> Can you add that (partial int modes have fewer bits than int modes)
>> as verification to genmodes.c:make_partial_integer_mode?
>
> I could, but it would be a no-op for PARTIAL_INT_MODE()
>
>> I wonder if this should not use GET_MODE_PRECISIO
> On 05/13/13 14:09, Jan Hubicka wrote:
> >>Index: varasm.c
> >>===
>
> >I think DECL_COMDAT is not what you really want to return true for. So
> >perhaps
> >you really want (TREE_PUBLIC (decl) && decl_binds_to_current_def_p)?
>
>
> This unch_memory in struct resources is a left-over from
> RTX_UNCHANGING_P, but it looks like the change-over to MEM_READONLY_P
> was done incorrectly: The resource_conflicts_p code now reports
> conflicts for insns reading readonly memory and insns reading "normal"
> memory or no memory at all.
On Mon, May 13, 2013 at 10:28 PM, Jeff Law wrote:
> On 05/13/2013 02:16 PM, Steve Ellcey wrote:
>>
>> Here is the latest version of my SSA optimization pass to do the switch
>> statement optimization described in PR 54742 (core_state_transition from
>> coremark).
>>
>> I have tested this optimizat
Hi,
this patch fixes with weakrefs seen on building latest firefox. The problem is
that currently we handle weakrefs as external variables/functions that makes us
to merge them. In firefox there are two weakrefs with different aliases used
in different units. This is correct and well defined eve
Hi,
On Tue, 14 May 2013, Uros Bizjak wrote:
> I'd propose to introduce:
>
> a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS
>
> b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS
This would break -m32.
> c) #undef and #define DEFAULT_TLS_SEG_REG in rdos.h to SEG_GS
>
> Then u
On Tue, 14 May 2013, Jakub Jelinek wrote:
> Hi!
>
> This patch adds safelen field to struct loop, teaches expand_omp_simd
> to set it on the simd loops and then uses it in a few places:
> 1) because the loops are explicitly marked for vectorization by the user,
>we'll try to ifconvert them an
The patch to use -z ignore/-z record for libgcc_s on Solaris caused far
more problems than it initially seemed:
* Before Solaris 11 where dl_iterate_phdr is used, crtbegin.o contains
references to
__register_frame_info_bases/__deregister_frame_info_bases which cause
libgcc_s.so.1 to be dragg
On Tue, May 14, 2013 at 11:12 AM, Jan Hubicka wrote:
> Hi,
> this patch fixes with weakrefs seen on building latest firefox. The problem
> is
> that currently we handle weakrefs as external variables/functions that makes
> us
> to merge them. In firefox there are two weakrefs with different al
On Tue, May 14, 2013 at 11:13 AM, Michael Matz wrote:
> On Tue, 14 May 2013, Uros Bizjak wrote:
>
>> I'd propose to introduce:
>>
>> a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS
>>
>> b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS
>
> This would break -m32.
Uh, yes.
So in
On Tue, May 14, 2013 at 11:28:43AM +0200, Richard Biener wrote:
> > + /* If non-NULL, an INTEGER_CST, where the user asserted that for any
> > + I in [ 0, nb_iterations ) and for any J in
> > + [ I, min ( I + safelen, nb_iterations ) ), the Ith and Jth iterations
> > + of the loop can
On Tue, May 14, 2013 at 10:39 AM, Jakub Jelinek wrote:
> On Tue, May 14, 2013 at 08:58:55AM +0200, Uros Bizjak wrote:
>> I think that the option should be named -mtarget-builtins.
>
> There shouldn't be an option for it at all. If constructing the builtins is
> slow (it is), we should just create
This must have fallen through the cracks.
I realized we also need it in the 4_7 branch. Could you backport the
change there, too, if it is not too much trouble?
On Mon, Apr 22, 2013 at 10:53 PM, Jonathan Wakely wrote:
> On 22 April 2013 12:13, Evgeniy Stepanov wrote:
>> Thanks a lot.
>> Forgot to
On 05/13/13 04:15, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression in thumb2 mode for
CoreMark. However, looking at
On 14 May 2013 10:45, Evgeniy Stepanov wrote:
> This must have fallen through the cracks.
It's still in my Git branch at home. I've been too busy to push any
commits recently, but I haven't forgotten it.
> I realized we also need it in the 4_7 branch. Could you backport the
> change there, too,
This backports a piece of Nathans patch to avoid opening two
gcov files at once (which ICEs).
Profiledbootstrap / regtest ongoing on x86_64-unknown-linux-gnu.
Richard.
2013-05-14 Richard Biener
PR gcov-profile/57269
Backport from mainline
2012-06-30 Nathan Sidwell
All,
I have just backported the following revisions from trunk to
linaro/gcc-4_8-branch: 197838, 198191, 198490-198496, 198575-198575, and 198677.
I have also merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision 198615.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working
On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
> When trying with -O2 -mno-avx:
> #ifndef __AVX__
> #pragma GCC push_options
> #pragma GCC target("avx")
> #define __DISABLE_AVX__
> #endif
> typedef float __v8sf __attribute__ ((__vector_size__ (32)));
> typedef float __m256 __attribu
On Tue, 14 May 2013, Jakub Jelinek wrote:
> On Tue, May 14, 2013 at 11:28:43AM +0200, Richard Biener wrote:
> > > + /* If non-NULL, an INTEGER_CST, where the user asserted that for any
> > > + I in [ 0, nb_iterations ) and for any J in
> > > + [ I, min ( I + safelen, nb_iterations ) ), th
Thanks Eric. This is better. spaec64-elf should not define it either.
Eric Botcazou wrote:
> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.
Let's remove the FIXME instead. Applied to mainline.
2013-05-14 Eric Botcazou
* config/sparc/sp64-elf
On Tue, May 14, 2013 at 12:04 PM, Jakub Jelinek wrote:
> On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
>> When trying with -O2 -mno-avx:
>> #ifndef __AVX__
>> #pragma GCC push_options
>> #pragma GCC target("avx")
>> #define __DISABLE_AVX__
>> #endif
>> typedef float __v8sf __attri
On Tue, May 14, 2013 at 12:16:07PM +0200, Richard Biener wrote:
> > The loop was previously containing EDGE_ABNORMAL edges (that is something
> > to prevent any optimizations on those until ompexp had a chance to deal with
> > those), so there is no loop at all, just the loop->num == 0 for the whol
The new gcc.dg/fstack-protector-strong.c testcase is currently failing
on Solaris/x86 like this:
FAIL: gcc.dg/fstack-protector-strong.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/fstack-protector-strong.c:113:13:
warning: incompatible implicit declar
On Tue, May 14, 2013 at 12:26:31PM +0200, Rainer Orth wrote:
> Tested with the appropriate runtest invocations on i386-pc-solaris2.11
> and x86_64-unknown-linux-gnu, installed on mainline.
I'd say the test should just use __builtin_alloca instead.
> 2013-05-14 Rainer Orth
>
> * gcc.dg/f
On 14/05/13 00:24, Chung-Lin Tang wrote:
On 13/5/13 11:15 AM, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression in th
Hi,
in this PR Jonathan noticed that we don't enforce the first part of
8.4.2/2, about compatibility of the exception-specification of defaulted
functions in general, not the special case of those defaulted on the
first declaration. Extending the existing check beyond
DECL_DEFAULTED_IN_CLASS
On Tue, May 14, 2013 at 12:22:05PM +0200, Richard Biener wrote:
> > The problem is that in the first testcase, the VAR_DECL c (guess also b and
> > a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector
> > types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode
> > (i
Hi,
This patch defines the "simd" attribute for the *movdi_aarch64 pattern.
Tested successfully with a full regression run on aarch64-elf.
OK for trunk?
Thanks
Sofiane
aarch64-set-simd-att.diff
Description: Binary data
2013/5/13 Joern Rennecke
>
> All the gcc.c-torture/compile/limits-externdecl.c currently give an
> error: size of array is too large, followed by an ICE in
> avr_encode_section_info, which goes on to try to find the address space
> of error_mark_node.
>
> Given the size of the array, it makes sens
Hello,
in an earlier patch I apparently introduced a platform dependent signed /
unsigned comparison, so here is a fix. I am taking the chance to fix the
host_integerp second argument nearby: we want non-negative integers.
Passes bootstrap+testsuite on x86_64-linux-gnu and apparently bootstra
On Mon, May 13, 2013 at 1:40 PM, Marc Glisse wrote:
> On Mon, 13 May 2013, Richard Biener wrote:
>
>> On Sat, May 11, 2013 at 11:38 AM, Marc Glisse
>> wrote:
>>>
>>> Second try.
>>>
>>> I removed the fold_single_bit_test thing (I thought I'd handle it, so I
>>> started by the easy part, and never
I forgot to ask. Did you put this on the open branches as well? 4.7 and 4.8.
Please and thank you
Eric Botcazou wrote:
> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.
Let's remove the FIXME instead. Applied to mainline.
2013-05-14 Eric Botcazou
On Tue, May 14, 2013 at 1:23 PM, Marc Glisse wrote:
> Hello,
>
> in an earlier patch I apparently introduced a platform dependent signed /
> unsigned comparison, so here is a fix. I am taking the chance to fix the
> host_integerp second argument nearby: we want non-negative integers.
>
> Passes bo
On Tue, 14 May 2013, Richard Biener wrote:
On Tue, May 14, 2013 at 1:23 PM, Marc Glisse wrote:
Hello,
in an earlier patch I apparently introduced a platform dependent signed /
unsigned comparison, so here is a fix. I am taking the chance to fix the
host_integerp second argument nearby: we wan
On Tue, 14 May 2013, Richard Biener wrote:
On Mon, May 13, 2013 at 1:40 PM, Marc Glisse wrote:
On Mon, 13 May 2013, Richard Biener wrote:
On Sat, May 11, 2013 at 11:38 AM, Marc Glisse
wrote:
@@ -8274,28 +8269,34 @@ fold_unary_loc (location_t loc, enum tre
{
elem =
On Tue, May 14, 2013 at 1:34 PM, Marc Glisse wrote:
> On Tue, 14 May 2013, Richard Biener wrote:
>
>> On Tue, May 14, 2013 at 1:23 PM, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> in an earlier patch I apparently introduced a platform dependent signed /
>>> unsigned comparison, so here is a fix. I a
On Tue, May 14, 2013 at 1:47 PM, Marc Glisse wrote:
> On Tue, 14 May 2013, Richard Biener wrote:
>
>> On Mon, May 13, 2013 at 1:40 PM, Marc Glisse wrote:
>>>
>>> On Mon, 13 May 2013, Richard Biener wrote:
>>>
On Sat, May 11, 2013 at 11:38 AM, Marc Glisse
wrote:
>
> @@ -8274,28
I think the time has come to obsolete Solaris 9 support:
* According to
http://www.oracle.com/us/support/library/lsp-coverage-sun-software-309122.pdf,
p.17, Premier Support has already ended in October 2011 and even
Extended Support will end in October 2014, which means it's impossible
to
On 14/05/13 12:11, Sofiane Naci wrote:
Hi,
This patch defines the "simd" attribute for the *movdi_aarch64 pattern.
Tested successfully with a full regression run on aarch64-elf.
OK for trunk?
Thanks
Sofiane
OK
/Marcus
On 05/10/2013 04:17 PM, Paolo Carlini wrote:
this is the issue about the signatures of the erase member functions
of the sequence containers. Mostly rather straightfoward stuff within
the limits of the current infrastructure: the various _M_const_case
are normally simple enough, I only mention
OK.
Jason
On 05/13/2013 03:36 PM, Jakub Jelinek wrote:
What about the 4 other
maybe_constant_value on fold_non_dependent_expr_sfinae (something, tf_none)
calls in typeck.c (two for -Wdiv-by-zero and two for shift diagnostics)?
You're right, that was a poor approach to fixing the bug. This one
properly
On 05/14/2013 02:40 PM, Paolo Carlini wrote:
Then I suppose that the correct way to move forward to C++11 the
ext/pointer.h stuff would be adding a pointer_traits specialization
for those pointer-like types, which would also wrap the cast
operations in pointer_to. Then, in __normal_iterator::_M
Hi Steven,
> Should new ports be allowed in if they rely so heavily on reload?
As it happens I am currently working on enabling LRA for the MSP430
target. Although I have run into a roadblock with a possibly
unacceptable patch to simplify_subreg_regno:
http://gcc.gnu.org/ml/gcc-patches/20
On 05/14/2013 04:31 AM, Jakub Jelinek wrote:
On Tue, May 14, 2013 at 12:26:31PM +0200, Rainer Orth wrote:
Tested with the appropriate runtest invocations on i386-pc-solaris2.11
and x86_64-unknown-linux-gnu, installed on mainline.
I'd say the test should just use __builtin_alloca instead.
Yea,
Jeff Law writes:
> On 05/14/2013 04:31 AM, Jakub Jelinek wrote:
>> On Tue, May 14, 2013 at 12:26:31PM +0200, Rainer Orth wrote:
>>> Tested with the appropriate runtest invocations on i386-pc-solaris2.11
>>> and x86_64-unknown-linux-gnu, installed on mainline.
>>
>> I'd say the test should just us
Hi,
this patch merges r192458 into gcc-4_7 to fix separate configure/build
of libstdc++.
A bit of history: a similar patch was committed to trunk & 4.7 back in
Oct'12, then reverted from both, than this patch was committed to
trunk only. I wonder if it was simply lost for some reason?
Is it OK f
On 14 May 2013 14:14, Evgeniy Stepanov wrote:
> Hi,
>
> this patch merges r192458 into gcc-4_7 to fix separate configure/build
> of libstdc++.
>
> A bit of history: a similar patch was committed to trunk & 4.7 back in
> Oct'12, then reverted from both, than this patch was committed to
> trunk only.
On 05/14/2013 03:24 PM, Jonathan Wakely wrote:
I'd like to know what problem it solves and why it was reverted before
making that change on a stable release branch.
Indeed.
And please always post a clear ChangeLog and don't post regenerated
files, which are normally big and only add to the co
This is the original thread:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00525.html
This exact patch was never reverted. It seems to be a second attempt,
that was only applied to trunk that time. I'm cc-ing the original
author.
Smaller patch attached.
* config/gthr.m4: New. Define G
On Tue, May 14, 2013 at 12:16:07PM +0200, Richard Biener wrote:
> Works for me.
...
Ok, here is what I've committed to gomp-4_0-branch.
tree-vect-data-refs.c was kept (almost) unchanged, as per IRC discussion,
something ++todo for the future.
2013-05-14 Jakub Jelinek
* cfgloop.h (str
On 14 May 2013 13:51, Paolo Carlini wrote:
> On 05/14/2013 02:40 PM, Paolo Carlini wrote:
>>
>> Then I suppose that the correct way to move forward to C++11 the
>> ext/pointer.h stuff would be adding a pointer_traits specialization for
>> those pointer-like types, which would also wrap the cast ope
Hi,
For a statement like:
INT = FLOAT > FLOAT ? INT : INT.
The vcond implementation in AArch64 is broken. We will try to force
the INT value to a FLOAT register and will ICE.
This patch fixes this.
Regression suite run for aarch64-none-elf with no regressions,
and more cases added to the te
The following patch makes the vectorizer cost model more finegrained
by splitting -f[no-]vect-cost-model into
-fvect-cost-model=[unlimited|dynamic|cheap], thereby consuming
the -ftree-vect-loop-version flag. The cost model will be always
enabled after this patch (as opposed to currently where
-O
Hi,
On 05/14/2013 03:41 PM, Jonathan Wakely wrote:
I'd forgotten about the existence of __const_pointer_cast etc. in
...
Me too ;) I resorted to it as a sort of temporary kludge.
I agree that in C++11 mode __normal_iterator::_M_const_cast should not
rely on the existence of a get() member on
On 05/14/2013 12:49 AM, Alexandre Oliva wrote:
However, rather than implementing the locking in Makefiles, I'm thinking
it might be wiser to do so in a script that takes the lock name and the
command to run while holding the lock.
Good point.
trap 'rmdir "$lockdir"; exit $status' 0 1 2 15
I
On 05/13/2013 03:20 PM, Jason Merrill wrote:
If we don't like the designator, we should fail pleasantly.
And we ought to accept this case, anyway.
commit 6a9489bb28a4caf64e1b27ce35522990590a74a4
Author: Jason Merrill
Date: Tue May 14 09:08:15 2013 -0400
PR c++/57041
* pt.c (tsu
As requested by Tobias, this patch supports -z ignore with Solaris ld
instead of GNU ld's --as-needed.
i386-pc-solaris2.10 and x86_64-unknown-linux-gnu bootstraps are still
running. In both cases, the correct options were detected and written
into libgfortran.spec. AFAICS the -static-libgfortran
OK
/M
On 14 May 2013 14:43, James Greenhalgh wrote:
>
> Hi,
>
> For a statement like:
>
> INT = FLOAT > FLOAT ? INT : INT.
>
> The vcond implementation in AArch64 is broken. We will try to force
> the INT value to a FLOAT register and will ICE.
>
> This patch fixes this.
>
> Regression suite ru
... I'm finishing testing the below.
Paolo.
Index: include/bits/stl_iterator.h
===
--- include/bits/stl_iterator.h (revision 198885)
+++ include/bits/stl_iterator.h (working copy)
@@ -63,7 +63,7 @@
#include
#incl
On Mon, 2013-05-13 at 15:03 -0700, Lawrence Crowl wrote:
> I still have not heard from i386 or ia64 folks. Anyone?
The IA64 part looks OK to me.
Steve Ellcey
sell...@imgtec.com (sell...@mips.com)
Hi Jeff,
I would like to apply the patch below to allow simplify_subreg_regno()
to treat the frame pointer register in the same way as the stack
pointer register when the LRA pass is running.
Ew.
Before accepting this, I'd like to see more of the rationale behind the
change.
*s
Rainer Orth wrote:
As requested by Tobias, this patch supports -z ignore with Solaris ld
instead of GNU ld's --as-needed.
For reference, my request was motivated by
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00425.html
(The patch has been approved, but it does not seem to be in, yet.)
i38
On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin
wrote:
> Hi,
> I attached an updated version of the patch. Looks like the 64-bit issue is
> resolved in it (now a vector mode is explicitly chosen instead of TI- or
> another integer mode). Also, some of remarks are fixed in it - some
> others
> How can you then ever "truncate" from SImode to PSImode?
If you use PARTIAL_INT_MODE(), you get a PSImode that has a "default"
bitsize (i.e. the value stored in the data structure) that's the same
as SImode, that is, 32. There is no way to specify the usable
bitsize, so it's "undefined/unspeci
I've made a patch along these lines (enclosed).
Change log:
* gcc/config/i386/i386.c: Use DEFAULT_TLS_SEG_REG to access TLS
* gcc/config/i386/i386.h: Define default segment register for TLS
* gcc/config/i386/rdos.h: Added TLS configuration for RDOS
Regards,
Leif Ekblad
- Original Message
2013/5/14 nick clifton :
> Hi Steven,
>
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> simplify_subreg_regno:
>
>
On 13/4/26 4:00 AM, Joseph S. Myers wrote:
> On Thu, 18 Apr 2013, Chung-Lin Tang wrote:
>
>> +nios2-*-linux*)
>> +tmake_file="$tmake_file nios2/t-nios2 nios2/t-linux t-libgcc-pic
>> t-slibgcc-libgcc"
>> +extra_parts="$extra_parts crti.o crtn.o"
>> +md_unwind_header=nios2/linux-unwind.
On Tue, May 14, 2013 at 2:51 PM, nick clifton wrote:
> Hi Steven,
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> sim
This patch dumps the column number as part of dump_loc making the
output similar to inform(). This allows these messages to be pattern
matched by dg_message. Bootstraps with this change. Ok for trunk?
- Easwaran
-
2013-05-14 Easwaran Raman
* dumpfile.c (dump_loc): Print column number.
On 2013/4/26 04:35 AM, Joseph S. Myers wrote:
> I should ask the following general standard new-port questions:
>
> * Does the port build cleanly when configured with --enable-werror-always
> and built using a native compiler from current GCC trunk - for both 32-bit
> host, and 64-bit host? It
> On Tue, May 14, 2013 at 11:12 AM, Jan Hubicka wrote:
> > Hi,
> > this patch fixes with weakrefs seen on building latest firefox. The
> > problem is
> > that currently we handle weakrefs as external variables/functions that
> > makes us
> > to merge them. In firefox there are two weakrefs wit
> "Alexandre" == Alexandre Oliva writes:
Alexandre> However, rather than implementing the locking in Makefiles,
Alexandre> I'm thinking it might be wiser to do so in a script that
Alexandre> takes the lock name and the command to run while holding the
Alexandre> lock.
It seems to me you can
> > In the case where IN_GCC is defined, where are the types
> > dwarf_attribute, dwarf_form, and dwarf_tag defined?
>
> In GCC's own dwarf2.h as enum tags; dwarf.h uses anonymous enums.
Ah, I still should have typedef'ed those types to enum tags when IN_GCC. I've
verified the following patch bo
On 05/06/2013 03:05 PM, David Malcolm wrote:
Note that this code is for the gengtype build-time utility, rather than
in GCC proper, so this wasn't on my own mental hitlist for fixing global
state.
Yea, but we probably should be taking opportunities to clean this stuff
up even in the gen* utilit
On May 13, 2013, at 9:49 PM, Alexandre Oliva wrote:
> However, rather than implementing the locking in Makefiles, I'm thinking
> it might be wiser to do so in a script that takes the lock name and the
> command to run while holding the lock.
I worry about quoting. Anytime you accept and pass on
On Tue, May 14, 2013 at 6:45 PM, Leif Ekblad wrote:
> I've made a patch along these lines (enclosed).
>
> Change log:
> * gcc/config/i386/i386.c: Use DEFAULT_TLS_SEG_REG to access TLS
> * gcc/config/i386/i386.h: Define default segment register for TLS
> * gcc/config/i386/rdos.h: Added TLS configu
On May 10, 2013, at 5:27 PM, Kenneth Zadeck wrote:
> Assuming the patch has been tested on a public port, it is ok for commit.
Thanks. It turns out that my patch is necessary, but not sufficient, the code
that exists must be left in place, as there are pre-existing test cases in the
test suite
Hi!
Another regression caused by the delayed SIZEOF_EXPR evaluation.
For the purposes of -Wsequence-point warnings we should never
recurse into SIZEOF_EXPR operand, the expressions in there aren't
evaluated there.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8?
2013-05-1
Hi!
A few spots which print file:line or file:line:column info, but weren't
using locus color for it.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
also tested with ./xg++ -B ./ -S -fdiagnostics-color=auto test.ii on:
# 1 "test.c"
# 1 ""
# 1 "test.c"
# 1 "test1.h" 1
# 1 "te
On Tue, 2013-05-14 at 11:44 -0600, Jeff Law wrote:
> On 05/06/2013 03:05 PM, David Malcolm wrote:
[...snip review and comments about auto-checking of formatting...]
> Anyway, the patch is good to go. Please install.
Thanks for reviewing.
Probably a dumb question, but by "Please install", do y
Here is a trivial patch that improves the debuggability of recog_data. Without
this p recog_data in gdb on linux, didn't seem to work at all. My fingers were
not amused. :-)
Checked it in a obvious.
2013-05-14 Mike Stump
* recog.h: Rename struct recog_data to Recog_data.
Added its gcc/doc/ part. Previous pending post was:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00275.html
Message-ID: <20130506172221.ga21...@host2.jankratochvil.net>
--
Hi,
since
[patch] x86_64: CFI unwinding s
I was trying to debug with DF_REF_LOC in gdb on linux, and got:
(gdb) p DF_REF_LOC (*ref) == recog_data.operand_loc[op]
No symbol "__null" in current context.
My fingers were not amused. I found if I did:
(gdb) macro define __null 0
then I could do:
(gdb) p DF_REF_LOC (*ref) == recog_data.ope
OK.
On Tue, May 14, 2013 at 1:52 PM, Jakub Jelinek wrote:
> Hi!
>
> A few spots which print file:line or file:line:column info, but weren't
> using locus color for it.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> also tested with ./xg++ -B ./ -S -fdiagnostics-color=a
On Tue, May 14, 2013 at 12:18 PM, Mike Stump wrote:
> I was trying to debug with DF_REF_LOC in gdb on linux, and got:
>
> (gdb) p DF_REF_LOC (*ref) == recog_data.operand_loc[op]
> No symbol "__null" in current context.
>
> My fingers were not amused. I found if I did:
>
> (gdb) macro define __nul
Indeed, here is the patch to fix it. Also fix rendering of std::tr1
unordered containers.
2013-05-15 François Dumont
* python/libstdcxx/v6/printers.py (Tr1HashtableIterator): Fix
rendering of std::tr1 unordered containers iterator.
(StdHashtableIterator): New, render std unordered
> I forgot to ask. Did you put this on the open branches as well? 4.7 and 4.8.
No, on mainline only (as written in the previous message). I can backport to
4.8 though, but it's too late for 4.7.
--
Eric Botcazou
We should call complete_type before deciding that a type can't be completed.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit a0f9f1db9cb900ac3ab2aa1e61bc51616b4d2be4
Author: Jason Merrill
Date: Tue May 14 11:50:26 2013 -0400
PR c++/57243
* parser.c (cp_parser_range_for
On 05/14/2013 01:24 PM, Tom Tromey wrote:
It seems to me you can get the desired functionality in the Makefiles
using order-only dependencies -- just force some ordering of the
targets.
Order dependencies are the wrong solution: for one thing, they don't
allow for building just a single front
On 05/14/2013 02:04 PM, Mike Stump wrote:
I worry about quoting.
In my experience, "$@" does fine for passing on arguments.
Jason
Ok.
Jason
While Jeff works on the threader, I was wondering if I could get approval for
just the dominance.c part of the patch. This would allow me to use my pass as
a dynamically loaded optimization pass. But without this change to dominance.c,
the compiler aborts in iterate_fix_dominators when I do that
1 - 100 of 124 matches
Mail list logo
