Current crtstuff.c checks if JCR_SECTION_NAME is defined to decide whether
do work for JCR. However, defaults.h always defines JCR_SECTION_NAME:
#ifndef JCR_SECTION_NAME
#define JCR_SECTION_NAME ".jcr"
#endif
So it is impossible to disable JCR related code in crtbegin.o, which can
save some bytes
On 20 September 2012 09:55, Christophe Lyon wrote:
> On 20 September 2012 09:12, Eric Botcazou wrote:
>>> The attached patch catches C constructs:
>>> (A << 8) | (A >> 8)
>>> where A is unsigned 16 bits
>>> and maps them to builtin_bswap16(A) which can provide more efficient
>>> implementations o
On 20/09/12 17:32, Matthias Klose wrote:
> Starting with 4.4, GCC informs about that the `va_list' mangling has changed.
> This makes builds a bit "noisy", and maybe it's time to remove this
> informational message in the trunk.
>
> Matthias
>
>
> mangle.diff
>
>
> 2012-09-20 Matthias Klose
On 20 September 2012 23:06, Christophe Lyon wrote:
> Hi,
>
> GCC for ARM does not support compiling in Thumb1 mode and
> float-abi=hard. But it does not fail unless the program being
> compiled actually contains a function with parameters and/or a return
> value.
>
> This is a (minor) problem i
On 21/09/12 09:47, Matthew Gretton-Dann wrote:
> On 20 September 2012 23:06, Christophe Lyon
> wrote:
>> Hi,
>>
>> GCC for ARM does not support compiling in Thumb1 mode and
>> float-abi=hard. But it does not fail unless the program being
>> compiled actually contains a function with parameters
On Thu, Sep 20, 2012 at 10:01 PM, Marc Glisse wrote:
> On Sat, 1 Sep 2012, Marc Glisse wrote:
>
>> I have some issues with the vector-compare-2.c torture test. It passes a
>> vector by value (argument and return type), which is likely to warn
>> (although for some reason it doesn't for me, with to
On Fri, Sep 21, 2012 at 2:23 AM, Jia Liu wrote:
> Hi all,
>
> Currently the Chapter Plugins and LTO is all in one html page,
> the other chapters are separated into sections.
> So I separated them to make them easier reading.
>
> Is this patch OK?
+* LTO Overview::Overview of LTO.
+* ELF sect
Hi Richard,
Thank you very much for comment.
And, is this time OK?
On Fri, Sep 21, 2012 at 5:11 PM, Richard Guenther
wrote:
> On Fri, Sep 21, 2012 at 2:23 AM, Jia Liu wrote:
>> Hi all,
>>
>> Currently the Chapter Plugins and LTO is all in one html page,
>> the other chapters are separated into
On Fri, Sep 21, 2012 at 11:21 AM, Jia Liu wrote:
> Hi Richard,
>
> Thank you very much for comment.
>
> And, is this time OK?
Yes.
Thanks,
Richard.
> On Fri, Sep 21, 2012 at 5:11 PM, Richard Guenther
> wrote:
>> On Fri, Sep 21, 2012 at 2:23 AM, Jia Liu wrote:
>>> Hi all,
>>>
>>> Currently the
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Full text of previous message and context at URL above. No comments
or code changes since. Patch description left below for convenience.
>
> Add flags to disable system header canonicalizations.
>
> Libcpp may canonicalize system he
> You rely on being able to see all FRAME accesses as component refs,
> thus nothing transforms them into just MEM[&FRAME, offset]. That's of
> course something that can be easily "broken" by means of doing
> some pointer arithmetic like (untested, but you get the idea)
>
> foo()
> {
> int c[32
> Here is a new patch, modifying tree-ssa-math-opts.c as you suggested.
> It's indeed simpler :-)
>
> Validated with qemu-arm on target arm-none-linux-gnueabi.
I cannot formally approve, but this looks good to me.
However, could you check that this is also an improvement for PowerPC, which
is t
> Starting with 4.4, GCC informs about that the `va_list' mangling has
> changed. This makes builds a bit "noisy", and maybe it's time to remove
> this informational message in the trunk.
>
> 2012-09-20 Matthias Klose
>
> * gcc/config/arm/arm.c (arm_mangle_type): Don't warn anymore that
The introduction of vn_get_stmt_kind brought COND_EXPR and
VEC_COND_EXPR into the PRE machinery - both are not really suited
for SCCVN or PRE in NARY form as they contain an embedded
expression.
The following patch restores previous behavior. Eventually
we could experiment with moving them to RE
It's the regression of gcc.c-torture/execute/multi-ix.c at -O1 on Alpha
reported by Uros and comes from a thinko in my fix for PR rtl-opt/54290.
Tested on x86-64/Linux, applied on the mainline.
2012-09-21 Eric Botcazou
PR rtl-optimization/54290
PR rtl-optimization/54644
This patch from Jakub should fix issues with my previous patch.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-09-20 Jakub Jelinek
PR tree-optimization/54629
* tree-loop-distribution.c (classify_partition): Free loop nest only
after free
On Fri, Sep 21, 2012 at 12:48 PM, Eric Botcazou wrote:
>> You rely on being able to see all FRAME accesses as component refs,
>> thus nothing transforms them into just MEM[&FRAME, offset]. That's of
>> course something that can be easily "broken" by means of doing
>> some pointer arithmetic like
Hi Dehao,
You wrote:
> 4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650
> Failed one regression test in libgomp (I didn't know that there are
> regression tests for libraries before...)
> This error should be a bug exposed by this patch. I'll try to provide
> a patch as soon as possible.
See
Hi,
On Fri, Sep 21, 2012 at 12:48:16PM +0200, Eric Botcazou wrote:
>
...
> > As of doing it in SRA what I'd do there is special-case FRAME for both
> > candidate consideration (so you get around the addressable issue)
> > and replacement generation.
>
> OK, but you need to be able to split the
On Fri, Sep 21, 2012 at 01:32:25PM +0200, Richard Guenther wrote:
...
> Yes, most of the SRA heuristic games make it complicated and ugly,
> especially as it is isn't clearly separate analysis / decision / transform
> phases. TLC welcome ;)
>
While I agree that the heuristics of SRA is surpris
On 09/21/2012 05:33 AM, Paolo Carlini wrote:
On 09/21/2012 11:02 AM, Ulrich Drepper wrote:
On Thu, Sep 20, 2012 at 6:17 AM, Paolo Carlini
wrote:
Patch looks generally Ok to me. If Ulrich and the other interested
parties
don't have anything to add over the next 24 hrs or so, let's go
ahead and
Hello,
In the example of the patch, g++ fails to warn that the variable N::i
(introduced via a using declaration) is unused.
This is because as we want to emit the warning in poplevel, when we
walk the local bindings returned by getdecls, we forget that a
VAR_DECL introduced by a using declaratio
Hi,
On Thu, 20 Sep 2012, Dehao Chen wrote:
> 4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Failed one
> regression test in libgomp (I didn't know that there are regression
> tests for libraries before...) This error should be a bug exposed by
> this patch. I'll try to provide a patch as
On 21 September 2012 10:47, Matthew Gretton-Dann
wrote:
> On 20 September 2012 23:06, Christophe Lyon
> wrote:
>> Hi,
>>
>> GCC for ARM does not support compiling in Thumb1 mode and
>> float-abi=hard. But it does not fail unless the program being
>> compiled actually contains a function with
>From my part, I'm willing to push the patch, but I need confirmation
from Paolo and Nathan
because some of it affects code outside of my authority.
On Thu, Sep 20, 2012 at 7:02 PM, rbmj wrote:
> Ping? Just did a full pull and rebuild today and everything still works :)
>
> Robert Mason
On 2012.09.20 at 19:51 -0700, Dehao Chen wrote:
> As expected, since this patch was checked in yesterday, there are 4
> bugs exposed (1 fixed, 1 patch ready, 2 TBD):
It also causes: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54655
--
Markus
On 09/21/12 14:30, Bruce Korb wrote:
From my part, I'm willing to push the patch, but I need confirmation
from Paolo and Nathan
because some of it affects code outside of my authority.
I have no objections to the patch.
nathan
This removes the no longer required dominating stmt argument from
the insertion routines (since the eliminate () reorg) and also
reflects that insertion now never can fail (again).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-09-21 Richard Guenther
*
This bug happens because GIMPLE_TRANSACTION is a statement
without real but with virtual operands. The short-cut in gimple_copy
thus is overly optimistic. Fixed as follows.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2012-09-21 Richard Guenther
PR middle-en
On Fri, Sep 21, 2012 at 7:58 AM, Dodji Seketeli wrote:
> +for (tree d = getdecls (); d; d = TREE_CHAIN (d))
> + {
> + /* There are cases where D itself is a TREE_LIST. See in
> + push_local_binding where the list of decls returned by
> + getdecls is built. */
>
> Prepare_cmp_insn in optabs.c expands BLKmode compares using either
> cmp{mem,str,strn}_optab, or through emit_library_call_value to integer
> result register, and follows with the expansion of the compare of the
> result with zero. However, the code blindly assumes that the target is
> able to co
Hi Richard,
On Fri, Sep 21, 2012 at 6:14 PM, Richard Guenther
wrote:
> On Fri, Sep 21, 2012 at 11:21 AM, Jia Liu wrote:
>> Hi Richard,
>>
>> Thank you very much for comment.
>>
>> And, is this time OK?
>
> Yes.
May you check in it for me please?
Thank you.
>
> Thanks,
> Richard.
>
>> On Fri,
On Fri, Sep 21, 2012 at 4:57 PM, Eric Botcazou wrote:
>> Prepare_cmp_insn in optabs.c expands BLKmode compares using either
>> cmp{mem,str,strn}_optab, or through emit_library_call_value to integer
>> result register, and follows with the expansion of the compare of the
>> result with zero. Howeve
> Although the testcase doesn't trip on this part, the result_mode is
> taken from the operand mode of cmp{mem,str,strn}_optab. As in the
> second case, there is no guarantee that compare that compares the
> result of cmp{mem,str,stn}_optab can handle output mode of this optab.
It's up to you to w
On Fri, Sep 21, 2012 at 5:26 PM, Eric Botcazou wrote:
>> Although the testcase doesn't trip on this part, the result_mode is
>> taken from the operand mode of cmp{mem,str,strn}_optab. As in the
>> second case, there is no guarantee that compare that compares the
>> result of cmp{mem,str,stn}_optab
This patch was checked in as
http://gcc.gnu.org/viewcvs?view=revision&revision=191614
I have another patch to add the new test. The new trunk can pass this
test. If no objection, I'll check in this patch in an hour.
Thanks,
Dehao
gcc/testsuite/ChangeLog:
2012-09-21 Dehao Chen
PR go/5
The Go compiler was erroneously treating len(<-c) as a constant if c was
a chan of an array. That was causing it to not actually run the channel
receive operation. This patch fixes the problem, and also does a minor
cleanup by moving the relevant code from do_lower to do_is_constant.
Bootstrapped
On 09/21/12 08:52, Richard Guenther wrote:
This bug happens because GIMPLE_TRANSACTION is a statement
without real but with virtual operands. The short-cut in gimple_copy
thus is overly optimistic. Fixed as follows.
Thank you so much for fixing this.
When you apply the patch, do you mind in
Hello,
this patch adds mixed scalar-vector operations to the C++ front-end. It
also adds a few operators to the C front-end (comparisons in particular).
This patch is mostly an import from the C front-end (with the maybe_const
stuff removed).
2012-09-22 Marc Glisse
PR c++/54427
Hi,
This patch adds i386/knetbsd-gnu64.h for x86_64-knetbsd-gnu. OK to
install?
Thanks.
H.J.
---
2012-09-21 H.J. Lu
PR target/48904
* config.gcc (tm_file): Add i386/knetbsd-gnu64.h for
x86_64-*-knetbsd*-gnu.
* config/i386/knetbsd-gnu64.h: New file.
diff --g
The attached patch solves the bootstrap failures in PR54642 where the
file lto-symtab.o is rebuilt during 'make install' by the system compiler
due to the dangling dependency left on gt-lto-symtab.h for lto-symtab.o.
Tested on x86_64-apple-darwin12 against clang/clang++ of Xcode 4.5.
Okay for gcc t
On Fri, Sep 21, 2012 at 12:33 PM, Jack Howarth wrote:
> The attached patch solves the bootstrap failures in PR54642 where the
> file lto-symtab.o is rebuilt during 'make install' by the system compiler
> due to the dangling dependency left on gt-lto-symtab.h for lto-symtab.o.
> Tested on x86_64-ap
This patch adds some typedef printers to libstdc++.
This relies on a gdb patch that hasn't yet gone in (pending on the list).
If the gdb patch changes, I'll change these printers as well.
The basic idea is that you can now have gdb substitute a name of your
choice when printing a type's name. Th
The problem here is that a simple loop gets transformed into a
__builtin_memset by the loop distribution pass:
+ __transaction_atomic
+ {
+for (i = 0; i < 100; ++i)
+ pp[i] = 0x33;
+ }
Since this pass occurs after IPA-tm, the new call to __builtin_memset
hasn't been analyzed so it
Hi,
This patch moves location_adhoc_data into GC, and also rebuild the
hash table when reading in the PCH. After the patch, PCH can work as
expected.
Bootstrapped and passed gcc regression tests on x8664_linux.
OK for trunk?
Thanks,
Dehao
libcpp/ChangeLog:
2012-09-21 Dehao Chen
PR
This patch to the Go compiler gives a better error message if a method
that requires a pointer receiver is invoked with a non-pointer value.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r cb56a10e8798 go/types.cc
--- a/go/types.cc
On 09/19/2012 10:19 AM, Kai Tietz wrote:
> Hi,
>
> this patch fixes testsuite-failures for llp64 targets in
> gcc.dg/tree-ssa testsuite.
>
> ChangeLog
>
> 2012-09-19 Kai Tietz
>
> * gcc.dg/tree-ssa/scev-3.c: Add llp64 to xfail.
> * gcc.dg/tree-ssa/scev-4.c: Likewise.
>
> Ok fo
This patch to the Go frontend adds some missing dashes to error
messages. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r fb59d6712068 go/gogo.cc
--- a/go/gogo.cc Fri Sep 21 14:06:10 2012 -0700
+++ b/go/gogo.cc Fri Sep 21 15:05:27
On 20 Sep 2012, at 08:51, "Zhenqiang Chen" wrote:
> Hi,
>
> PR 50970 is a general c++ front-end issue for targets which define
> TARGET_PTRMEMFUNC_VBIT_LOCATION ptrmemfunc_vbit_in_delta, although the
> reporter had issues only on ARM.
>
> Root cause: It misses a check for side effects when gene
On 09/18/2012 01:24 AM, Richard Earnshaw wrote:
> Quite possibly. In order to determine what is right, we first need to
> understand the specification. My reading of that is that the semantics
> should be endian independent, but I was hoping that someone would know
> for certain and be able to ch
The branch was successfully merged with trunk @191440.
The merged lra branch was successfully bootstrapped on x86/x86-64,
PPC64, ARM, IA64, SPARC64, and MIPS64.
Bootstrapping SPARC64 and MIPS64 required the following changes:
2012-09-21 Vladimir Makarov
* config/mips/mips.c: Inclu
This patch to the Go frontend fixes the handling of an unnamed struct
type with methods (inherited from embedded fields) converted to an
interface type. Previously the interface method table was being stored
as NULL, causing a runtime crash. Bootstrapped and ran Go testsuite on
x86_64-unknown-lin
On 09/21/2012 02:00 PM, Aldy Hernandez wrote:
> + /* ?? For TM_* builtin replacements, can we set this to FALSE??
> + Otherwise, do we need to propagate the may_irr bit? */
> + node->local.tm_may_enter_irr = true;
Yes we can. Indeed, I think we should have to insist on it.
This patch adds a -mno-crt0 option, similar to what is found on the
mn10300 port. I have checked it in.
Thanks,
AG
2012-09-21 Anthony Green
* config/moxie/moxie.opt: Add -mno-crt0 option.
* config/moxie/moxie.h (STARTFILE_SPEC): Handle -mno-crt0 option.
* doc/invoke
Hi,
The problem is due to a bug when move_block_to_fn. edge->goto_block
should be updated even when its locus is unknown. This patch also
fixes the way to reset block for expr.
Bootstrapped and pass all gcc regression tests.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
tree-cfg.c
Currently, the register predicates allow a subreg of anything,
including memory or the wrong kind of register. Most other ports
do not allow this. As far as I can see, this doesn't help the
compiler generate better code, potentially the opposite.
This also causes a problem for my (upcoming) add-
Add functions symtab_node_def::try_function and symtab_node_def::try_variable.
These function return a pointer to the more specific type (e.g. cgraph_node*)
if and only if the general type (symtab_node aka symtab_node_def*) is an
instance of the specific type. These functions are essentially check
On 09/20/2012 06:33 PM, Jakub Jelinek wrote:
Status
==
The GCC 4.7.2 release tarballs have been created and were uploaded
to ftp.gnu.org. The GCC 4.7 branch is thus open again for
regression and documentation fixes.
Shouldn't be change
http://gcc.gnu.org/viewcvs/trunk/gcc/gcc.c?r1=18810
This patch to the Go frontend fixes a dumb error that was preventing the
correct determination of argument types to the builtin complex function.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 293c1db1ef35 go/expressions.cc
--- a/g
It is valid to store a NaN in a Go hash table. However, the result can
not be looked up, because NaN never equals NaN. The only way to see the
result is to range over the map. This means that the hash code used for
a NaN is irrelevant. In general it's better to not hash all NaN values
to the sa
In Go if the type of the left operand a shift operand must be determined
from context, it gets the type of the overall expression, ignoring the
type of the right operand. It is then an error if it does not get a
integral type. However, it is also OK if it gets an interface type.
The compiler was
This patch to the Go frontend and libgo rejects surrogate pairs when
converting an int to a string. They are not valid UTF-8. The patch
also rejects a negative int--negative ints were already rejected by the
compiler, but not by the runtime. Bootstrapped and ran Go testsuite on
x86_64-unknown-li
62 matches
Mail list logo
