On Dec 7, 2011, at 5:32 AM, Richard Earnshaw wrote:
> So this, to some extent seems to conflict with your rules for only fixing
> regressions. This code has always been broken in one way or another,
> so technically this doesn't qualify for the 4.6 branch.
My take, does this fix improve the qual
On 12/09/2011 11:49 AM, Jakub Jelinek wrote:
> PR tree-optimization/51117
> * tree-eh.c (sink_clobbers): New function.
> (execute_lower_eh_dispatch): Call it for BBs ending with
> internally throwing RESX.
> * cfgexpand.c (add_scope_conflicts_1): Add SCRATCH argument.
In message <4ee2285b.3060...@arm.com>
Richard Earnshaw wrote:
> I think we've reached the point where the following target
> configurations should be End-of-Life'd. As such, I'd like to mark them
> as deprecated in gcc-4.7, prior to removal after the branch.
>
> I'd also like to remov
On Wed, 30 Nov 2011, Iain Sandoe wrote:
There is really no point in having a flag to control the Objective C (or
Objective C++) exceptions [@throw, as opposed to throw] scheme, since we
actually only support one scheme for each permutation of runtime and
ABI.
This removes the flag_objc_sjlj_e
On Fri, Dec 9, 2011 at 3:02 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Dec 9, 2011 at 2:47 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
Some my Linux system, system call numbers are defined as
#define __NR_x32_rt_sigaction __NR_X32_SYSCA
"H.J. Lu" writes:
> On Fri, Dec 9, 2011 at 2:47 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> Some my Linux system, system call numbers are defined as
>>>
>>> #define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
>>>
>>> and
>>>
>>> __NR_X32_SYSCALL(0) is expanded to (0x40
On Fri, Dec 9, 2011 at 2:47 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Some my Linux system, system call numbers are defined as
>>
>> #define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
>>
>> and
>>
>> __NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patc
The patch is good for google branches for now while waiting for upstream review.
David
On Sun, Dec 4, 2011 at 10:26 PM, Teresa Johnson wrote:
> Latest patch which improves the efficiency as described below is
> included here. Boostrapped and checked again with
> x86_64-unknown-linux-gnu. Could s
"H.J. Lu" writes:
> Some my Linux system, system call numbers are defined as
>
> #define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
>
> and
>
> __NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
> tries to deal with by checking '^// unknowndefine SYS_[a-z]' an
On 12/09/2011 01:44 PM, Aldy Hernandez wrote:
> PR/51291
> * tree.c (build_common_builtin_nodes): Do not use TM_PURE
> attribute unless language has support for TM.
> * config/i386/i386.c (ix86_init_tm_builtins): Exit gracefully in
> the absence of TM builtins.
Ok.
Compiling any fortran program with -fgnu-tm currently ICEs because the
TM builtins are defined in gtm-builtins.def which are not included (via
builtins.def) in the Fotran front-end.
Presently, there are no TM extensions for the Fortran language, but it
shouldn't ICE. We could error out early
Hi Ian,
Some my Linux system, system call numbers are defined as
#define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
and
__NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
tries to deal with by checking '^// unknowndefine SYS_[a-z]' and uses
"${CC} -E" to e
ple-fold.c (gimple_fold_stmt_to_constant_1) :
Also check the TYPE_MODE to recognize useless pointer conversions.
2011-12-09 Eric Botcazou
* gcc.c-torture/compile/20111209-1.c: New test.
--
Eric Botcazou
Index: gim
Attached patch applied.
2011-12-09 François Dumont
* include/bits/hashtable.h (_Hashtable<>::emplace,
_Hashtable<>::emplace_hint): Add.
* include/debug/unordered_set (unordered_set<>::emplace,
unordered_set<>::emplace_hint, unordered_multiset<>::emplace,
On 9 Dec 2011, at 19:45, Aldy Hernandez wrote:
On 12/09/11 13:19, Jakub Jelinek wrote:
On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
It works for me too.
Except that when matching just , (% it doesn't tes
On 12/09/2011 09:11 AM, Jakub Jelinek wrote:
> PR tree-optimization/51117
> * tree-eh.c (optimize_clobbers): Don't remove just one
> clobber, but all consecutive clobbers before RESX.
> Use gimple_clobber_p predicate.
Ok.
r~
On Fri, Dec 09, 2011 at 01:45:48PM -0600, Aldy Hernandez wrote:
> On 12/09/11 13:19, Jakub Jelinek wrote:
>> On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
>>>
>>> It works for me too.
>>
>> Except that when ma
With the infrastructure of the previous patch in place, this patch
easily uses TEMPLATE_ID_TYPE to represent unbound specializations of
alias templates, thus fixing PR c++/51239.
A new function introduced to fix that bug is also used to address PR
c++/51180 by fixing the representation of template
As presented in the cover message, this patch replaces the
BOUND_TEMPLATE_TEMPLATE_PARM tree with a TEMPLATE_ID_TYPE tree that
represents a template-id whose arguments haven't yet been applied to
its template. The template itself might have not been resolved to a
TEMPLATE_DECL yet, in which case i
Hello,
The little patch set of this thread addresses PRs c++/51239 and PRs
c++/51180 in a generic way, as you suggested.
It replaces the BOUND_TEMPLATE_TEMPLATE_PARM tree with a
TEMPLATE_ID_TYPE tree and makes bound template template parameters and
typename types use that new tree.
With this inf
This was caused by my earlier kludge to build normal conversions between
scalar types in templates; the instantiation code isn't prepared to deal
with all the various tree forms that can occur that way. So now I've
limited it to the identity conversion, which shouldn't require any added
trees
OK.
Jason
Hi!
Even with the optimize_clobbers changes, for e.g.
struct A { char buf[64]; };
void bar (A *);
void
foo ()
{
A c;
bar (&c);
try
{
{
A a;
bar (&a);
if (a.buf[13])
throw 1;
else if (a.buf[52])
throw 3;
}
{
A b;
bar (&b);
On 12/09/11 13:19, Jakub Jelinek wrote:
On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
It works for me too.
Except that when matching just , (% it doesn't test almost anything.
IMNSHO you should instead just
On 12/09/2011 10:02 AM, Ramana Radhakrishnan wrote:
> For Neon a further optimization to consider might be to use the vext
> instruction which could achieve permute masks that are monotonically
> increasing constants ? While I expect the latency for a vext or vtbl
> instruction to be about the same
On Thu, Dec 8, 2011 at 4:06 PM, Richard Henderson wrote:
> rs6000: Implement vec_perm_constv16qi for altivec.
> rs6000: Cleanup interleave/even_odd/vec_perm.
The rs6000 patches are okay with the changes that you, Mike and I
discussed on IRC.
Thanks, David
Bah, I ran make check in a different build directory. This fixes the
two failures I introduced with my warning patch.
Now tested on the proper build dir.
Diego.
cp/ChangeLog.pph
* pph-core.c (pph_include_handler): Use LOC instead of
INPUT_LOCATION.
testsuite/ChangeLog.pph
On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
> > +/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
>
> It works for me too.
Except that when matching just , (% it doesn't test almost anything.
IMNSHO you should instead just test it { target !fpic } or similar.
We currently emit hard errors when a PPH image is missing or invalid.
This is not ideal, because in these cases, what the compiler could do
is to simply use the original text header file. After all, they are
interchangeable.
Additionally, this helps the current implementation into finding other
> +/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
It works for me too.
Thanks,
Dominique
On 9 Dec 2011, at 18:52, Aldy Hernandez wrote:
there are 4 cases: {c,c++} {m32,m64} with 4 different asm outputs
if that is a 'reasonable' situation - then might need to include
ilp64/ip32 in the target spec ...
Both the 32 and 64 bit versions of the Darwin output are correct, so
perhaps
there are 4 cases: {c,c++} {m32,m64} with 4 different asm outputs
if that is a 'reasonable' situation - then might need to include
ilp64/ip32 in the target spec ...
Both the 32 and 64 bit versions of the Darwin output are correct, so
perhaps something like I had originally proposed, but taki
On 9 Dec 2011, at 17:50, Aldy Hernandez wrote:
scan-assembler can be target-dependent if that would (as I read the
above) help.
Well, whadayaknow...
In that case we can have an x86 variant for Darwin, and one for
everything else x86.
in principle, it should be OK ... with *-*-darwin*
On Fri, Dec 09, 2011 at 06:02:21PM +, Ramana Radhakrishnan wrote:
> On 8 December 2011 21:06, Richard Henderson wrote:
> > ---
> > gcc/config/arm/arm-protos.h | 3 +
> > gcc/config/arm/arm.c | 527
> > -
> > gcc/config/arm/neon.m
On 8 December 2011 21:06, Richard Henderson wrote:
> ---
> gcc/config/arm/arm-protos.h | 3 +
> gcc/config/arm/arm.c | 527
> -
> gcc/config/arm/neon.md | 59
> gcc/config/arm/vec-common.md | 26 ++
>
scan-assembler can be target-dependent if that would (as I read the
above) help.
Well, whadayaknow...
In that case we can have an x86 variant for Darwin, and one for
everything else x86.
OK?
testsuite/
* c-c++-common/cxxbitfields-3.c: Adjust regexp.
Index: testsuite/c-c++-common/c
Ping ..
On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
> Build the test case in the patch file with -finstrument-functions, the
> link will fail with unsat. The problem is gcc instruments the
> artificial wrappers that will won't be emitted. The patch fixes the
> problem. Bootstrap and
On 9 Dec 2011, at 17:35, Aldy Hernandez wrote:
This test is somewhat problematic in that it's entirely dependent on
the assembler output. It's not reproducible on non-x86, so I
couldn't make it part of the simulate-thread framework.
What we're really testing is that the last move into "va
This test is somewhat problematic in that it's entirely dependent on the
assembler output. It's not reproducible on non-x86, so I couldn't make
it part of the simulate-thread framework.
What we're really testing is that the last move into "var" happens as a
32/64 bit quantity:
movl
Hi!
When working on clobber sinking, I've noticed that
optimize_clobbers would mistakenly remove just one clobber
instead of all consecutive ones, because gsi_remove moves
the iterator to the next rather than previous stmt (i.e.
GIMPLE_RESX if no debug stmts) and we return in the next iteration.
Hi!
As mentioned in the PR, we ICE on the following testcase, because
there are DRs in a GIMPLE_CALL stmt and when there is just one, we
compute vectype for the call as if it were a load or store, but during
computation of vectorization factor we only consider the return value
of the call. As suc
> Windows doesn't have any concept of an rpath in executables, nor of
> LD_LIBRARY_PATH; all required DLLs must be found on the PATH when an exe is
> invoked. The Ada shared libraries are currently installed into adaobj/ in
> the gcc private dir, which is not (and should not be) on users' PATHs,
On Fri, Dec 09, 2011 at 10:03:47AM -0500, Jack Howarth wrote:
> On Fri, Dec 09, 2011 at 02:09:54PM +, Iain Sandoe wrote:
> >
> > On 8 Dec 2011, at 20:55, Iain Sandoe wrote:
> >> ... but, I'll bow out at this juncture -
> >
> > OK, I lied :-)
> >
> > The boehm-gc tests pass for m32 and m64 with
On Fri, Dec 09, 2011 at 05:26:47PM +0100, Rainer Orth wrote:
> Hi Jack,
>
> > The same argument could be made for PIC itself regarding the testsuite.
> > Aren't we still the only target that defaults to PIC objects? I would think
> > that
>
> certainly not: e.g. both Tru64 UNIX and IRIX are
Rainer Orth writes:
> This patch led to many (all?) execution tests to fail on Solaris:
>
> Undefined first referenced
> symbol in file
> libgo_log.syslog.syslog_c
> /var/gcc/regression/trunk/11-gcc-gas/build/i386-pc-solaris2.11/./libg
ARM's neon_vector_mem_operand does not allow eliminable or virtual registers
to be used as addresses. create_*_operand was supposed to cope with that by
replacing the address with a (non-virtual) pseudo register. The problem is
that I used the wrong function: force_reg rather than copy_to_mode_re
The predeclared print function in Go should print to stderr, not
stdout. This patch from Rémy Oudompheng fixes libgo to do that.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r e73cfc80d5d7 libgo/runtime/go-print.c
--- a/libgo/runtime/go-print.c
The buit-in functions that underlie ARM's vzip*() and vunzp*() functions
pass the result by reference rather than value. This leads to very poor
output, as demonstrated in PR 48941.
This patch makes them return the vectors by value instead, using the
structure modes TImode and OImode. Tested on
On 11-12-09 09:36 , Dmitriy Vyukov wrote:
This is for google-main branch.
Fix ThreadSanitizer pass required properties.
Turned out that PROP_gimple_lomp is not always present.
Index: gcc/tree-tsan.c
===
--- gcc/tree-tsan.c (revi
On 12/08/2011 10:08 PM, Hans-Peter Nilsson wrote:
> On Thu, 8 Dec 2011, Richard Henderson wrote:
>> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
>> index d3fd709..f1c3665 100644
>> --- a/gcc/config/mips/mips.c
>> +++ b/gcc/config/mips/mips.c
>
>> @@ -13021,8 +13015,8 @@ static cons
Hi Jack,
> The same argument could be made for PIC itself regarding the testsuite.
> Aren't we still the only target that defaults to PIC objects? I would think
> that
certainly not: e.g. both Tru64 UNIX and IRIX are PIC by default.
Rainer
--
-
Ian Lance Taylor writes:
> Rémy Oudompheng contributed a patch to upgrade the gccgo version of Go
> library to the weekly.2011-11-09 release. This patch commits the change
> to mainline. As usual with Go library updates, the patch is too large
> to include here, and simply repeats changes made
Richard Earnshaw writes:
> --- config.gcc(revision 182097)
> +++ config.gcc(local)
> @@ -242,7 +242,14 @@ md_file=
>
> # Obsolete configurations.
> case ${target} in
> + # Avoid special cases that are not obsolete
> + arm*-*-linux-gnueabi* \
> + | arm*-*-ecos-elf
These fixes to individual sms testcases are OK.
Thanks,
Ayal.
On Mon, Dec 5, 2011 at 3:07 PM, Revital Eres wrote:
> Hello,
>
> Ping: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02444.html
>
> Thanks,
> Revital
I think we've reached the point where the following target
configurations should be End-of-Life'd. As such, I'd like to mark them
as deprecated in gcc-4.7, prior to removal after the branch.
I'd also like to remove at that time support for some now obsolete
co-processor units, namely the FPA and
Hello Everyone,
This patch is for the Cilkplus branch affecting only the C compiler. This
patch will implement the 1D array notation triplets. Array notations are
indented to allow users directly express high-level parallel vector operations
in the code. More information about array notatio
OK.
Jason
On Fri, Dec 09, 2011 at 02:09:54PM +, Iain Sandoe wrote:
>
> On 8 Dec 2011, at 20:55, Iain Sandoe wrote:
>> ... but, I'll bow out at this juncture -
>
> OK, I lied :-)
>
> The boehm-gc tests pass for m32 and m64 with "-fpie/-fPIE" on both x86
> Darwin9 (XC3.1.4) and x86_64 Darwin10 (XC3.2.5);
This is for google-main branch.
Fix ThreadSanitizer pass required properties.
Turned out that PROP_gimple_lomp is not always present.
Index: gcc/tree-tsan.c
===
--- gcc/tree-tsan.c (revision 182099)
+++ gcc/tree-tsan.c (workin
Quoting Richard Henderson :
+GEN_INT
+ (trunc_int_for_mode
While you're at it, or as a followup, this is combination is gen_int_mode.
I mis-read the patch the first time and thought
On 8 Dec 2011, at 20:55, Iain Sandoe wrote:
... but, I'll bow out at this juncture -
OK, I lied :-)
The boehm-gc tests pass for m32 and m64 with "-fpie/-fPIE" on both x86
Darwin9 (XC3.1.4) and x86_64 Darwin10 (XC3.2.5);
I'm building with XC3.2.6 to check that too.
So I think you need to d
Jakub Jelinek wrote:
> On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote:
>> No, not OK.
>>
>> This leads to unacceptable code for devices that cannot shift easily like,
>> e.g.
>> AVR. This target can only shift by 1 and shifts with big offsets have to be
>> performed by means of a
> 2011-12-07 Tom de Vries
>
> * cfgcleanup.c (try_optimize_cfg): Replace call to delete_isns_chain by
delete_insn_chain
> call to delete_insn. Remove code to reorder BASIC_BLOCK note and
> DELETED_LABEL note, and move it to ...
> * cfg_rtl.c (delete_insn): Change retu
On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote:
> No, not OK.
>
> This leads to unacceptable code for devices that cannot shift easily like,
> e.g.
> AVR. This target can only shift by 1 and shifts with big offsets have to be
> performed by means of a loop at runtime.
Andrew's
Andrew Pinski wrote:
> Hi,
> After SSA-expand, the code which did the optimization for
> (a&(1<>C)&1 became not working because BIT_AND_EXPR
> would no longer be in there. This patch fixes the problem by using
> get_def_for_expr to get the BIT_AND_EXPR.
>
> OK? Bootstrapped and tested on x86_6
PING: For reviewing the modified CR16 port.
Hello,
Can some one please review the updated patch and let me know if any more
changes are required to be done in it?
The modified patch was posted at following URL:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02625.html
Thanks and Regards,
Jayant
This fixes PR46796 by making sure the types in the type variant chain
can be looked up again using get_qualified_type.
LTO bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-12-09 Richard Guenther
PR lto/46796
* lto.c (uniquify_nodes): Merge TYPE_DECLs
I'm testing the following to avoid ICEing when using LTO and
mismatched -g vs. -g0 during compile/link phase by not conditionally
clearing things in free_lang_data_in_decl.
(Similar code is in free_lang_data_in_type, but without a testcase
I don't want to remove it)
LTO bootstrap and regtest runn
>
> Bootstrap and gcc-check are passing without regression.
Sorry, it's taken me a while to get to this but I looked at this for
sometime last night and think this needs a bit of work .
1. Can the code for TARGET_APCS_FRAME be factored out into a separate
function from arm_expand_epilogue ?
E
On Fri, Dec 9, 2011 at 12:44 PM, Michael Zolotukhin
wrote:
> Hi, Richard,
> Accidentally, the first version of the patch (which contained changes
> in the original files without duplicating them, and which was approved
> by Ira Rosen) has already been checked-in to trunk - could you also
> approve
On Fri, Dec 09, 2011 at 10:35:57AM +0100, Richard Guenther wrote:
> > *shrug* Maybe just a new pass immediately before ehcleanup2?
> > It's just a quick pass over the basic blocks...
>
> I'd just not care for the ones preceeding a return. Not at this point
> at least.
After IRC discussion with r
Hi, Richard,
Accidentally, the first version of the patch (which contained changes
in the original files without duplicating them, and which was approved
by Ira Rosen) has already been checked-in to trunk - could you also
approve reverting the original tests back? With this revert I'll also
commit
On 9 Dec 2011, at 11:27, Joseph S. Myers wrote:
On Fri, 9 Dec 2011, Richard Guenther wrote:
On Fri, Dec 9, 2011 at 7:17 AM, H.J. Lu wrote:
gcc/Makefile.in has
gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \
gengtype-state.o version.o errors.o $(LIBDEPS)
Hi!
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to 4.6
branch.
2011-12-09 Jakub Jelinek
Backport from mainline
2011-12-08 Jakub Jelinek
PR tree-optimization/51466
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Also copy
On Fri, Dec 9, 2011 at 12:00 PM, Kai Tietz wrote:
> So this patch replace use of 'long long' in ira-color.c and in
> ira-conflict.c by HOST_WIDEST_INT.
Ok.
Thanks,
Richard.
> Kai
>
> ChangeLog
>
> 2011-12-09 Kai Tietz
>
> * ira-color.c (print_hard_regs_subforest): Use
> HOST_WI
On Fri, 9 Dec 2011, Richard Guenther wrote:
> On Fri, Dec 9, 2011 at 7:17 AM, H.J. Lu wrote:
> > gcc/Makefile.in has
> >
> > gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \
> > gengtype-state.o version.o errors.o $(LIBDEPS)
> > +$(LINKER) $(ALL_LINKERFLAGS) $(
This makes sure to not have ENUM/BOOL component type vectors.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-12-09 Richard Guenther
PR tree-optimization/51482
* tree-vect-stmts.c (get_vectype_for_scalar_type_and_size):
Make sure to only c
On Thu, Dec 01, 2011 at 11:49:55AM +, Sameera Deshpande wrote:
>
> --
> -;; Note: this is not predicable, to avoid issues with linker-generated
> -;; interworking stubs.
> -(define_insn "*thumb2_return"
> +(define_insn "*thumb2_rtl_epilogue_return"
Rename to *thumb2_return
>[(return)]
So this patch replace use of 'long long' in ira-color.c and in
ira-conflict.c by HOST_WIDEST_INT.
Kai
ChangeLog
2011-12-09 Kai Tietz
* ira-color.c (print_hard_regs_subforest): Use
HOST_WIDEST_INT_PRINT_DEC instead of %lld.
(allocno_hard_regs): Change type of cost memb
On Fri, Dec 9, 2011 at 11:32 AM, Kai Tietz wrote:
> 2011/12/9 Richard Guenther :
>> On Fri, Dec 9, 2011 at 11:10 AM, Kai Tietz wrote:
>>> 2011/12/9 Richard Guenther :
On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote:
> 2011/12/9 Richard Guenther :
>> On Fri, Dec 9, 2011 at 9:51 AM,
2011/12/9 Richard Guenther :
> On Fri, Dec 9, 2011 at 11:10 AM, Kai Tietz wrote:
>> 2011/12/9 Richard Guenther :
>>> On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote:
2011/12/9 Richard Guenther :
> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
>> Hi,
>>
>> this patch fixe
On Fri, Dec 9, 2011 at 11:10 AM, Kai Tietz wrote:
> 2011/12/9 Richard Guenther :
>> On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote:
>>> 2011/12/9 Richard Guenther :
On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
> Hi,
>
> this patch fixes for windows native target print-form
On Fri, Dec 9, 2011 at 11:05 AM, Kai Tietz wrote:
> Fine, here is updated patch for it.
Ok.
Thanks,
Richard.
> Index: implicit-zee.c
> ===
> --- implicit-zee.c (revision 182092)
> +++ implicit-zee.c (working copy)
> @@ -8
2011/12/9 Richard Guenther :
> On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote:
>> 2011/12/9 Richard Guenther :
>>> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
Hi,
this patch fixes for windows native target print-formatter used about
long-long type.
ChangeLog
>
Fine, here is updated patch for it.
Index: implicit-zee.c
===
--- implicit-zee.c (revision 182092)
+++ implicit-zee.c (working copy)
@@ -889,8 +889,8 @@
rtx curr_insn = NULL_RTX;
int i;
int ix;
- long long num_real
On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote:
> 2011/12/9 Richard Guenther :
>> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
>>> Hi,
>>>
>>> this patch fixes for windows native target print-formatter used about
>>> long-long type.
>>>
>>> ChangeLog
>>>
>>> 2011-12-09 Kai Tietz
>>>
>>>
2011/12/9 Richard Guenther :
> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
>> Hi,
>>
>> this patch fixes for windows native target print-formatter used about
>> long-long type.
>>
>> ChangeLog
>>
>> 2011-12-09 Kai Tietz
>>
>> * ira-color.c (print_hard_regs_subforest): Use
>>
On Fri, Dec 9, 2011 at 9:52 AM, Kai Tietz wrote:
> Hi,
>
> this patch fixes for windows native target print-formatter used about
> long-long type.
>
> ChangeLog
>
> 2011-12-09 Kai Tietz
>
> * implicit-zee.c (find_and_remove_ze): Use
> HOST_WIDEST_INT_PRINT_DEC instead of %lld.
>
>
On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
> Hi,
>
> this patch fixes for windows native target print-formatter used about
> long-long type.
>
> ChangeLog
>
> 2011-12-09 Kai Tietz
>
> * ira-color.c (print_hard_regs_subforest): Use
> HOST_WIDEST_INT_PRINT_DEC instead of %lld.
On Fri, Dec 9, 2011 at 9:38 AM, Tom de Vries wrote:
> Jakub,
>
> This patch fixes the problem reported in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973#c4 .
>
> The test-case listed there is:
> ...
> struct Block
> {
> public:
> Block();
> ~Block();
> };
>
> bool func( bool bar )
> {
On Fri, Dec 9, 2011 at 7:17 AM, H.J. Lu wrote:
> gcc/Makefile.in has
>
> gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \
> gengtype-state.o version.o errors.o $(LIBDEPS)
> +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
> $(filter-out ($LIBDEPS), $^
On Fri, Dec 9, 2011 at 1:24 AM, Richard Henderson wrote:
> On 12/08/2011 04:00 PM, Jakub Jelinek wrote:
>> On Thu, Dec 08, 2011 at 03:53:40PM -0800, Richard Henderson wrote:
>>> On 12/08/2011 11:57 AM, Jakub Jelinek wrote:
+ else if (gimple_code (last) == GIMPLE_RETURN
+ ||
On Thu, Dec 8, 2011 at 10:06 PM, Richard Henderson wrote:
> Slightly modified version of a patch Jakub posted earlier.
Ok (given the target specific patches are approved).
Thanks for this cleanup,
Richard.
>
> * tree.def (VEC_INTERLEAVE_HIGH_EXPR, VEC_INTERLEAVE_LOW_EXPR): Remove.
>
The following fixes PR51262, the new type alias code does
else if (CLASS_TYPE_P (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
which ICEs when t is a type with an anonymous name with -flto
because we clear such TYPE_NAMEs during cp_free_lang_data.
It turns out that doing so is no longer necessary be
Carrot Wei writes:
> Since it also affects 4.6 branch, can this and r176270 also be ported
> to gcc4.6?
Always worth asking, but in this case, I'm not sure it's appropriate.
The patch is pretty invasive, and I don't think the bug is a regression.
Also, 4.6 generates really lousy code for these i
Hi,
this patch fixes for windows native target print-formatter used about
long-long type.
ChangeLog
2011-12-09 Kai Tietz
* implicit-zee.c (find_and_remove_ze): Use
HOST_WIDEST_INT_PRINT_DEC instead of %lld.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-
Hi,
this patch fixes for windows native target print-formatter used about
long-long type.
ChangeLog
2011-12-09 Kai Tietz
* ira-color.c (print_hard_regs_subforest): Use
HOST_WIDEST_INT_PRINT_DEC instead of %lld.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unkn
Jakub,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973#c4 .
The test-case listed there is:
...
struct Block
{
public:
Block();
~Block();
};
bool func( bool bar )
{
Block block;
bool foo = false;
if( !foo || bar )
do { return true; }
98 matches
Mail list logo
