On Thu, Jan 19, 2012 at 12:16:01AM +0100, Jakub Jelinek wrote:
> As described in the PR, if two argument erase is removing the last
> element of one bucket (i.e. the one referenced in _M_buckets array
> for the next bucket) and then at least one element from the
> following bucket, but not all elem
2012/1/18 Jason Merrill :
> I still think the problem is that we're applying the attributes more than
> once, and we should only apply them once. If we fix that, we don't need to
> merge them.
>
> Jason
Well, I will try to search for it a bit more. Nevertheless is the
chaining at this place IMHO
On 01/19/2012 08:34 AM, Jakub Jelinek wrote:
> >Ok, thanks for working on this.
> Installed, do you want this for 4.6/4.5?
If yes, please give it at least a couple of weeks on the trunk.
It's fine by me but yes, let's give it time to bake.
Paolo
On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
if test "x${build}" = "x${target}"&& test "x${build}" = "x${host}"; then
This test is no longer necessary, is it? ia64 does its own cross-compile
detection via AC_RUN_IFELSE, and other hosts are cross-compile safe.
The patch is okay if you rem
On Tue, Jan 17, 2012 at 1:38 AM, Richard Guenther
wrote:
> On Tue, Jan 17, 2012 at 8:06 AM, Andrew Pinski
> wrote:
>> Hi,
>> This adds the folding of x & ((~x) | y)) into x & y on the tree
>> level via fold-const.c
>> There is already partly done on the RTL level but it would be a good
>> thing
On Thu, Jan 19, 2012 at 09:54:43AM +0100, Paolo Bonzini wrote:
> On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
> >if test "x${build}" = "x${target}"&& test "x${build}" = "x${host}"; then
>
> This test is no longer necessary, is it? ia64 does its own
> cross-compile detection via AC_RUN_IFELSE,
On Wed, 18 Jan 2012, Aldy Hernandez wrote:
> On 01/18/12 03:09, Richard Guenther wrote:
> > On Tue, 17 Jan 2012, Aldy Hernandez wrote:
> >
> > >
> > > > > What I have in mind is to abstract out the initialization of TM
> > > > > builtins
> > > > > from
> > > > > gtm-builtins.def (through its inc
Hi!
For FFI_TYPE_FLOAT and FFI_TYPE_DOUBLE, I think src/ia64/ffi.c violates
aliasing by accessing the same object through incompatible lvalues
(in an asm operand through float resp. double lvalue and on the next
line through UINT32 resp. UINT64 lvalue.
GCC apparently errors out on this while reloa
On 01/19/2012 10:06 AM, Jakub Jelinek wrote:
While the linker test is done using the target linker (it uses default
linker flags btw, so in case a linker would be buggy for one target and not
for a different target also supported by the same linker, it would be
a problem, but let's assume that th
... which is confused about a useful testcase not using uninitialized
variables.
Testcase committed.
Richard.
2012-01-19 Richard Guenther
PR tree-optimization/37997
* gcc.dg/tree-ssa/ssa-pre-28.c: New testcase.
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c
=
On Thu, 19 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> For FFI_TYPE_FLOAT and FFI_TYPE_DOUBLE, I think src/ia64/ffi.c violates
> aliasing by accessing the same object through incompatible lvalues
> (in an asm operand through float resp. double lvalue and on the next
> line through UINT32 resp. UINT6
On 01/19/2012 12:16 AM, Jakub Jelinek wrote:
Fixed thusly, if __is_bucket_begin is true, then we know __n is the first
item in its bucket and thus __prev_n should be in the _M_buckets array.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok, the testcase too of course.
Tha
On 19 January 2012 08:36, Jakub Jelinek wrote:
>
> If you want a testcase that fails on x86_64-linux without the patch and
> succeeds with it, here it is:
Thanks, Jakub, the analysis and patch look right, OK to checkin with
the testcase.
* PING *
On 01/09/2012 03:59 PM, Tobias Burnus wrote:
"make pdf" fails with:
libiberty/copying-lib.texi:481: This command can
appear only outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @baden
On Thu, Jan 19, 2012 at 10:00 AM, Andrew Pinski
wrote:
> On Tue, Jan 17, 2012 at 1:38 AM, Richard Guenther
> wrote:
>> On Tue, Jan 17, 2012 at 8:06 AM, Andrew Pinski
>> wrote:
>>> Hi,
>>> This adds the folding of x & ((~x) | y)) into x & y on the tree
>>> level via fold-const.c
>>> There is alr
On Wed, 2012-01-18 at 22:25 +0100, Uros Bizjak wrote:
> On Wed, Jan 18, 2012 at 10:16 PM, Patrick Marlier
> wrote:
>
> >> IMO, whatever the future decision would be, we shouldn't leave one
> >> part of the compiler out-of-sync from the other. Proposed patch fixes
> >> _current_ situation, where i
On Thu, 2012-01-19 at 13:24 +0100, Torvald Riegel wrote:
> Note that if we remove the regparm, we should also remove it on the
> other functions associated with txn begin (GTM_beginTransaction etc.).
And update libitm.texi ...
On Thu, Jan 19, 2012 at 1:24 PM, Torvald Riegel wrote:
>> The spec does say that all function should be regparm(2), but I agree
>> that the above is less confusing. The attribute is ignored, but
>> perhaps a comment would clear this confusion even more.
>
> Uros, thanks for spotting the vararg is
This patch fixes three issues with building libgfortran for MinGW/MinGW64:
a) mode_t is unsigned short while scanf's %o expects an unsigned int
variable.
b) umask is not available
c) Only read and write is available but not group/other
read/write/execute, SUID/SGID or the sticky bit.
Thanks
Hello,
As discussed with Jakub in the PR, the problem is that a jump asm goto insn
is removed without purging the dead edges. Bootstrapped and tested on
x86-64. I had to use dg-prune-output to remove the error message and to
make the test pass, as we only checking for an ICE.
OK for trunk/
On Thu, Jan 19, 2012 at 06:13:58PM +0400, Andrey Belevantsev wrote:
> 2012-01-19 Andrey Belevantsev
>
> PR target/51106
> * function.c (instantiate_virtual_regs_in_insn): Use
> delete_insn_and_edges when removing a wrong asm insn.
This is ok for trunk.
> 2012-01-19 Jakub Jelinek
On 19/01/12 06:46, Bin Cheng wrote:
> Hi,
> Currently gcc generates code violating ARM EABI when passing arguments to
> some floating point
> helper functions, which are __aeabi_d2iz/__aeabi_d2uiz. As reported in bug
> PR51835.
>
> This patch fixes the issue, with test cases.
>
> It is for trunk
When we have a class-scope using-declaration that nominates functions,
we want to insert those functions into the derived class'
CLASSTYPE_METHOD_VEC. In non-template code we do this in
handle_using_decl, which is called from check_bases_and_members. But we
don't call that function for a clas
Hi,
On Mon, 16 Jan 2012, Richard Guenther wrote:
> > Regstrapping in progress on x86_64-linux, okay for trunk?
>
> Ok.
I've committed (r183305) a slightly changed variant that merges the two
outer bitmap loops again, like so:
+ EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts,
On 01/17/2012 06:52 PM, Cary Coutant wrote:
Would you consider it OK with a comment?
Yes.
How about if I call copy_declaration_context directly from
remove_child_or_replace_with_skeleton, instead of calling them
sequentially in break_out_comdat_types?
OK.
Jason
This is basically documentation of AVR specific extensions and stuff like
* command line options like -maccumulate-args etc.
* AVR named address spaces
Section doc/extend.texi::Named Address Spaces is split into several subsections
now; each subsection taking care of one target in alphabetical or
Georg-Johann Lay wrote:
> This is basically documentation of AVR specific extensions and stuff like
>
> * command line options like -maccumulate-args etc.
> * AVR named address spaces
>
> Section doc/extend.texi::Named Address Spaces is split into several
> subsections
> now; each subsection tak
Richard Guenther wrote:
> This should fix PR51782 - we need to look at the base address operand
> of MEM_REF and TARGET_MEM_REF to get at the address-space information
> as both can have an embedded VIEW_CONVERT_EXPR. This is then
> consistent with the gimple type system which keeps address-space
Hi!
It isn't clear why mudflap doesn't instrument DECL_ARTIFICIAL functions,
if it couldn't avoid instrumenting just a subset of them.
But there is certainly no reason why it shouldn't instrument normal clones
of user functions (OpenMP, TM, ISRA, ...). Fixed thusly,
bootstrapped/regtested on x86_
Hi,
the attached patch fixes a problem which has been introduced with:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01527.html
Bootstrapped and regtested on x86_64, s390, and s390x.
Ok for mainline?
Bye,
-Andreas-
2012-01-19 Andreas Krebbel
PR rtl-optimization/51856
* rel
Tobias Burnus wrote:
Bootstrapped on x86-64-linux, but not (yet) tested on MinGW/MinGW64
OK for the trunk?
MinGW64 was successful - thanks to Brad for testing it and for updating
the version, which is linked from the wiki.
Tobias
On Thu, Jan 19, 2012 at 06:10:06PM +0100, Jakub Jelinek wrote:
> 2012-01-19 Jakub Jelinek
>
> PR libmudflap/40778
> * tree-mudflap.c (mf_artificial): New function.
> (execute_mudflap_function_ops, execute_mudflap_function_decls,
> mx_register_decls, mudflap_enqueue_decl)
Seemingly, resolve and friends are confused if there is no symtree -
thus set it.
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch? (It's a regression.)
Tobias
2012-01-19 Tobias Burnus
PR fortran/51904
*expr.c (gfc_build_intrinsic_call): Also set the symtree.
2012
I have no problems running "make pdf" in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
On Thu, Jan 19, 2012 at 08:23:58PM +0100, Tobias Burnus wrote:
> Seemingly, resolve and friends are confused if there is no symtree -
> thus set it.
>
> Build and regtested on x86-64-linux.
> OK for the trunk and the 4.6 branch? (It's a regression.)
>
Yes. Almost looks obvious (except I've rea
DJ Delorie wrote:
I have no problems running "make pdf" in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
That's odd. I have exactly the same version and I get the following TeX
error.
Tobias
texi2pdf /home/tob/projects/gcc-git/gcc/libiberty/libiberty.texi
This is pdfTeX, Version 3.1415926-2
On 01/19/2012 03:36 AM, Kai Tietz wrote:
Well, I will try to search for it a bit more. Nevertheless is the
chaining at this place IMHO a pretty bad idea. The merging of
attributes looks more sane. Also is this merging patch pretty less
invasive and would be fine for older branches, too.
That
The following patch solves PR40761 which is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761.
The patch was bootstrapped on x86/x86-64 with -O2 and -O0 with checking
enabled.
Committed as rev. 183312.
2012-01-19 Vladimir Makarov
PR rtl-optimization/40761
* ir
On 01/18/2012 02:30 PM, Zamyatin, Igor wrote:
Yes, we use Atom for EEMBC measurements.
We'll be glad to help you with your findings.
Thanks.
Unfortunately I tried several alternative patches but I did not find a
better solution (it is mostly code size degradation on CoreI7). Now I
am even
When we read a tree from the cache of an external PPH file and the
tree is mutated in the current file, we need to re-sign the tree to
reflect the changes.
The problem was, that the signing code was assuming that the tree had
come from the *current* file, so it was trying to sign a cache entry
fo
On Wed, Jan 18, 2012 at 3:17 PM, Ian Lance Taylor wrote:
>>> This patch to the Go testsuite driver recognizes a few more test lines
>>> in Go tests. I somehow failed to notice these the last time I updated
>>> the Go testsuite. This patch includes a couple of changes to make the
>>> newly recog
Uros Bizjak writes:
>>> Some of the go tests require explicit -mieee compile flag [1]. Is
>>> there a way to conditionally pass this flag to the compiler?
>>
>> What does Java do?
>
> Nothing... while the library is compiled with -mieee (the same as
> libgo), the user is still expected to pass -m
Hello!
Attached patch adds -mieee to tests that need full IEEE compliance to
pass. While working on patch, I have noticed that go-test.exp doesn't
pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
format (so, these simply get ignored). With this issue fixed, we can
add -mieee to DEF
commit de9e01e3b50f75bcd47da9d32ab0691c65094df5
Author: Sterling Augustine
Date: Thu Jan 19 14:31:14 2012 -0800
Add DW_AT_GNU_pubtypes and Add DW_AT_GNU_pubnames to comdat type dies.
M gcc/dwarf2out.c
Tested:
Via make check-c and make check-c++. No new issues found.
ChangeL
>> Would you consider it OK with a comment?
>
> Yes.
>
>> How about if I call copy_declaration_context directly from
>> remove_child_or_replace_with_skeleton, instead of calling them
>> sequentially in break_out_comdat_types?
>
> OK.
Updated patch attached. I fixed the regex so the test is indepen
Uros Bizjak writes:
> Attached patch adds -mieee to tests that need full IEEE compliance to
> pass. While working on patch, I have noticed that go-test.exp doesn't
> pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
> format (so, these simply get ignored). With this issue fixed, we
On 31 December 2011 17:33, Jonathan Wakely wrote:
> I want to commit the attached patch:
>
> PR libstdc++/49204
> * include/std/future (__future_base::_State_base::wait()): Call
> _M_complete_async instead of _M_run_deferred.
> (__future_base::_State_base::wait_for()): C
On Jan 19, 2012, at 3:39 PM, Ian Lance Taylor wrote:
> And I just have to repeat that this patch is an ugly ugly hack, since
> -mieee should be the default. Perhaps we should investigate having
> gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee for those
> targets which require it.
I agr
2012/1/19 Georg-Johann Lay :
> Georg-Johann Lay wrote:
>> This is basically documentation of AVR specific extensions and stuff like
>>
>> * command line options like -maccumulate-args etc.
>> * AVR named address spaces
>>
>> Section doc/extend.texi::Named Address Spaces is split into several
>> su
-Wall was warning about explicitly imported but not used __vtab,
__def_init etc. variables.
Build and regtested on x86-64-linux
OK for the trunk?
Tobias
2012-01-20 Tobias Burnus
Janus Weil
PR fortran/51056
* module.c (load_needed, read_module): Don't mark __vtab etc.
as use_only.
Dear Tobias,
This patch is OK for trunk.
I have made a lot of progress on PR51870; class scalars work correctly
but I need to extend the fix to class arrays. It requires a complete
rewrite of the parts of gfc_trans_allocate that are associated with
class allocation and initialization. The resul
51 matches
Mail list logo
