Hi all
I've added MIPS64DSPR2 support to gcc.
Please review.
Thanks.
gcc/
2012-02-03 Jia Liu
* config/mips/mips-dspr2.md : add MIPS64DSPR2 insns.
* config/mips/mips-ftypes.def : builtin type for MIPS64DSPR2 insns.
* config/mips/mips.c: builtins for MIPS64DSPR2 insns.
On Fri, Feb 3, 2012 at 12:40 PM, Fu, Chao-Ying wrote:
> Richard Sandiford [rdsandif...@googlemail.com] wrote:
>
>> This pattern maps directly to __builtin_mips_prepend, which is defined
>> to take and return an SI type, so :SI is the correct choice here.
>>
>> I agree it might be nice to have a fu
Right -- I examined how the arrays are used. The fix looks safe.
Ok for google branches.
David
On Thu, Feb 2, 2012 at 9:23 PM, Sriraman Tallam wrote:
> Hi David,
>
> A .gnu.callgraph.text section for function foo will only contain edges
> where foo is the caller. Also, in my code real nodes cor
Hi David,
A .gnu.callgraph.text section for function foo will only contain edges
where foo is the caller. Also, in my code real nodes correspond to
functions whose text section is available and hence reorderable.
Originally, when I was counting the number of real function nodes, I
was only treati
Richard Sandiford [rdsandif...@googlemail.com] wrote:
> This pattern maps directly to __builtin_mips_prepend, which is defined
> to take and return an SI type, so :SI is the correct choice here.
>
> I agree it might be nice to have a function that operates on 64-bit
> values for 64-bit targets tho
Committed.
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 183832)
+++ MAINTAINERS (working copy)
@@ -495,6 +495,7 @@
Franz Sirl franz.sir
This code before the change seems to over-estimate the number of real
nodes which should be safe -- can you explain why it causes problem?
David
On Thu, Feb 2, 2012 at 6:13 PM, Sriraman Tallam wrote:
> Fix a bug in the function reordering linker plugin where the number of nodes
> to be reordered
Here is another attempt to fix the bad interaction between
--with-demangler-in-ld and -frepo processing.
This version of the patch always disables demangling in ld when
repository files are present for the link. If demangling is requested
(either by an explicit -Wl,--demangle option, by using
Hi,
This fixes the documentation aboud __udivmoddi4 and __udivmodti4.
There was a copy and paste error for both of these functions.
__udivmoddi3 was used instead of __udivmoddi4 and __udivti3 instead of
__udivmodti4.
Committed as obvious after double checking that these are the name of
the funct
Fix a bug in the function reordering linker plugin where the number of nodes
to be reordered is incremented in the wrong place. This caused a heap buffer
to overflow under certain conditions.
The linker plugin itself is only available in the google 4_6 branch and I will
port it to other branches
PING
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01786.html
At 2011-12-29 14:12:44,"Xinyu Qi" wrote:
> At 2011-12-22 17:53:45,"Richard Earnshaw" wrote:
> > On 22/12/11 06:38, Xinyu Qi wrote:
> > > At 2011-12-15 01:32:13,"Richard Earnshaw" wrote:
> > >> On 24/11/11 01:33, Xinyu Qi wrote:
> > >
PING
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01789.html
At 2011-12-29 14:25:23,"Xinyu Qi" wrote:
> > At 2011-11-24 09:27:04,"Xinyu Qi" wrote:
> > > At 2011-11-19 07:08:22,"Ramana Radhakrishnan"
> > > wrote:
> > > > On 20 October 2011 08:39, Xinyu Qi wrote:
> > > > > Ping
> > > > >
> > >
PING
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01788.html
At 2011-12-29 14:22:50,"Xinyu Qi" wrote:
> * config/arm/mmintrin.h: Use __IWMMXT__ to enable iWMMXt
> intrinsics.
> Use __IWMMXT2__ to enable iWMMXt2 intrinsics.
> Use C name-mangling for intrinsics.
> (__v8qi):
PING
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01787.html
At 2011-12-29 14:20:20,"Xinyu Qi" wrote:
> > At 2011-12-15 00:47:48,"Richard Earnshaw" wrote:
> > > On 14/07/11 08:35, Xinyu Qi wrote:
> > > >>> Hi,
> > > >>>
> > > >>> It is the first part of iWMMXt maintenance.
> > > >>>
> > > >>> *
This patch to libgo fixes the type of the last field of Cmsghdr from
[]byte to [0]byte. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r abc9201b3ab0 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Thu Feb 02 14:58:22 2012 -0800
+++ b/libgo/mksysinfo
I've merged trunk revision 183852 to the gccgo branch.
Ian
I foolishly messed up writing the ENOSYS functions for systems which
don't have them. I had them return ENOSYS, rather than setting errno
and returning an error indicator. This patch corrects this oversight.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ia
ok for google branches.
David
On Thu, Feb 2, 2012 at 2:30 PM, Rong Xu wrote:
> Hi,
>
> This patch curbs the counter scaling factor that causing counter
> overflow in inline transformation. The negavie counter triggers
> a later pass assertion.
>
> Tested: inertnal performance benchmarks.
>
> -Ro
Hi,
This patch curbs the counter scaling factor that causing counter
overflow in inline transformation. The negavie counter triggers
a later pass assertion.
Tested: inertnal performance benchmarks.
-Rong
2012-02-02 Rong Xu
* tree-inline.c (copy_cfg_body): Curb the scaling factor
The Go spec says that in a slice expression, the start and end indexes
are compared with the capacity of the slice value being sliced, not its
length. Somehow gccgo was doing OK getting that wrong. This patch
fixes it. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to
Dear all,
I have committed the attached patch as obvious (Rev.183848) - after
building and regtesting on x86-64-linux.
I intent to backport it to 4.6 soon. (It's a regression.)
Tobias
2012-02-02 Tobias Burnus
PR fortran/52093
* simplify.c (gfc_simplify_size): Handle INTRINSIC_PARENTHESE
Hi,
the following patch - Dave it is a derived variant from on of your
patches for a similar issue - takes care that for dllexport'ed classes
the typeinfo base declaration gets the dllexport-attribute, too.
ChangeLog
2012-02-02 Kai Tietz
Dave Korn
* config/i386/win
Dear Paul,
Paul Richard Thomas wrote:
Following our exchanges with Dominique, I think that the attached
patch will have to do for now.
Bootstrapped and regtested on FC9/x86_64 - OK for trunk?
The patch looks fine. Thanks. Can you also back-port to 4.6?
Tobias
2012-02-02 Paul Thomas
On Thu, Feb 2, 2012 at 1:14 PM, Jakub Jelinek wrote:
> Hi!
>
> pp_flush already adds a newline, so we shouldn't add it in pp_verbatim
> as well, that results in printing a blank newline after this message.
>
> Bootstrapped/regtested onx x86_64-linux and i686-linux, ok for trunk?
Yes! Thanks for c
Remove install weirdness from 49829 fix.
tested x86/linux
-benjamin2012-02-02 Benjamin Kosnik
PR libstdc++/52068
* src/c++11/Makefile.am (toolexeclib_LTLIBRARIES,
libc__11_la_SOURCES): Remove.
* src/c++11/Makefile.in: Regenerate.
* src/c++98/Makefile.am (toolexeclib_
The following patch solves PR49800 which is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49800.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 183843.
2012-02-02 Vladimir Makarov
PR rtl-optimization/49800
* haifa-sched.c (sched_init): Ca
Hi!
pp_flush already adds a newline, so we shouldn't add it in pp_verbatim
as well, that results in printing a blank newline after this message.
Bootstrapped/regtested onx x86_64-linux and i686-linux, ok for trunk?
2012-02-02 Jakub Jelinek
PR middle-end/48071
* diagnostic.c (
Hi!
It seems loop-iv.c happily creates shared RTL in lots of places,
loop-unroll.c solves that by unsharing everything it adds, this is
an attempt to do the same in unswitching to unshare everything iv_analyze
came up with.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
201
On Tue, Jan 31, 2012 at 02:46, Gerald Pfeifer wrote:
> On Sun, 29 Jan 2012, Janne Blomqvist wrote:
>>> .../gcc-HEAD/gcc/fortran/decl.c:5820:23: error: invalid conversion from
>>> 'const char*' to 'char*' [-fpermissive]
>>> gmake[3]: *** [fortran/decl.o] Error 1
>> Have you tried r183679, which sh
Ping for:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01564.html
which fixes a MIPS va_arg regression (admittedly a long-standing one)
on zero-sized types. There are no functional changes to other targets
and I'm as confident as I can be that it's safe for MIPS.
(It hasn't been a full week
On 02/02/2012 04:22 AM, Richard Guenther wrote:
On Wed, Feb 1, 2012 at 10:19 PM, Patrick Marlier
wrote:
On 02/01/2012 03:59 AM, Richard Guenther wrote:
The patch looks ok, but I'm not sure why you do not get a cgraph node
here - cgraph doesn't really care for builtins as far as I can see.
I have once again merged trunk to gccgo branch, revision 183840 this
time.
Ian
Liu writes:
> diff --git a/gcc/config/mips/mips-dspr2.md b/gcc/config/mips/mips-dspr2.md
> index 5ae902f..6853b9d 100644
> --- a/gcc/config/mips/mips-dspr2.md
> +++ b/gcc/config/mips/mips-dspr2.md
> @@ -345,7 +345,7 @@
> (set_attr "mode" "SI")])
>
> (define_insn "mips_prepend"
> - [(set (
Hello,
ChangeLog
2012-02-02 Kai Tietz
PR libjava/48512
* configure.ac (THREADSTARTFILESPEC): Don't add crtmet.o file for
w64 windows targets.
* configure: Regenerated.
Tested for i686-w64-mingw32, and i686-pc-mingw32. Ok for apply?
Regards,
Kai
Index: gcc/l
In a slightly complex case (I am adding a test case to the master Go
testsuite) it is possible for the importer to see a method for a type
which is in the process of being imported and is therefore not fully
defined. This was causing the compiler to complain about an undefined
type during the impo
Dear Tobias,
Following our exchanges with Dominique, I think that the attached
patch will have to do for now.
Bootstrapped and regtested on FC9/x86_64 - OK for trunk?
Cheers
Paul
2012-02-02 Paul Thomas
PR fortran/52012
* trans-expr.c (fcncall_realloc_result): If variable sh
Richard Sandiford wrote:
> "Ulrich Weigand" writes:
> > Richard Sandiford wrote:
> >> Either way, the idea is that new_spill_reg_store[R] is only valid
> >> for reload registers R that reach the end of the reload sequence.
> >> We really should check that H1 reaches the end before u
On Wed, Feb 1, 2012 at 10:59 PM, Uros Bizjak wrote:
> On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor wrote:
>
>>> (BTW: Do you have any idea on what to do with excessive memory usage
>>> in chan/select2.go? )
>>
>> At this point I don't. It's sort of peculiar. Sending an int on a
>> channel
On Thu, Feb 2, 2012 at 06:01, wrote:
> Here I create a declaration for a var that is defined in our run-time
> library. If I use some real location, then the declaration will have
> different irrelevant locations in each TU (irrelevant, because it will
> be somewhere near begin of a first instru
On Wed, Feb 1, 2012 at 9:07 PM, Diego Novillo wrote:
>
> Thanks. I've incorporated your feedback in the attached patch. OK for
> wwwdocs?
yes; thanks!
-- Gaby
Dear Mikael,
This...
> I have chosen to make it a separate function instead of fixing
> gfc_add_component_ref, so that it can be reused later (maybe...) even if we
> don't want to add a "_data", or "_vptr" or ... component.
...is exactly what I had a mind to do, once clear of regression
fixing.
Hello,
this patch, extracted with some modifications from PR50981 comment #28
[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981#c28],
(which has accumulated a lot of things) fixes an ICE noticed in several
PRs with an error like:
internal compiler error: in gfc_conv_descriptor_data_get,
at fort
On 2012/02/01 18:05:15, Diego Novillo wrote:
On 2/1/12 3:16 AM, Dmitriy Vyukov wrote:
> This is for google/gcc-4_6 branch.
> Backport ThreadSanitizer (tsan) instrumentation pass from
google/main.
Have you used the validator script to test this patch? Your patch
should not affect regular build
Hi,
this patch adds logic to detect cycles and cgraph and varpool aliases.
Prevoiusly we just output them into asm file and let gas to complain, but now
we catch ourselves
in infinite loop. I assumed that this is already tested in varasm but it is
not.
Bootstrapped/regtested x86_64-linux, will
On Thu, 2 Feb 2012, Richard Guenther wrote:
> On Wed, 1 Feb 2012, Richard Guenther wrote:
>
> >
> > This fixes PR48124 where a bitfield store leaks into adjacent
> > decls if the decl we store to has bigger alignment than what
> > its type requires (thus there is another decl in that "padding").
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 183833)
+++ gcc/doc/invoke.texi (working copy)
@@ -306,6 +306,7 @@
-fdump-tree-ssa@r{[}-@var{n}@r{]} -fdump-tree-pre@r{[}-@var{n}@r{]} @gol
-fdump-tree-ccp@r{[}-@var{n}
Hello,
this patch fixes an issue about current used boehm-gc tree in gcc.
The issue is that _DLL macro is used for Windows-targets wrong. It is
assumed that it would mean to build a shared object (DLL), but it just
indicates that built DLL/Exectuable is using shared msvcrt.dll
runtime. (see here
On Wed, 1 Feb 2012, Richard Guenther wrote:
>
> This fixes PR48124 where a bitfield store leaks into adjacent
> decls if the decl we store to has bigger alignment than what
> its type requires (thus there is another decl in that "padding").
[...]
> Bootstraped on x86_64-unknown-linux-gnu, testi
Richard,
this patch fixes PR52801.
Consider test-case pr51879-12.c:
...
__attribute__((pure)) int bar (int);
__attribute__((pure)) int bar2 (int);
void baz (int);
int x, z;
void
foo (int y)
{
int a = 0;
if (y == 6)
{
a += bar (7);
a += bar2 (6);
}
else
{
a +=
on sparc-linux, the TIOCNOTTY and TIOCSCTTY constants are defined as
#define TIOCNOTTY _IO('t', 113)
which cannot be parsed by mksysinfo.sh. Just define these as TIOCGWINSZ is
defined. This lets the libgo build succeed, but I see the same failures as
reported in PR52084 for powerpc-linux-
On Wed, Feb 1, 2012 at 10:19 PM, Patrick Marlier
wrote:
> On 02/01/2012 03:59 AM, Richard Guenther wrote:
>>
>> The patch looks ok, but I'm not sure why you do not get a cgraph node
>> here - cgraph doesn't really care for builtins as far as I can see.
>> Honza?
>
> I cannot help on this...
>
>
>
On Thu, Feb 02, 2012 at 10:02:09AM +0100, Uros Bizjak wrote:
> OK,
Thanks.
> probably we also need to backport this fix to other release branches.
No, while I didn't remember it, svn blame revealed that these peepholes
were my fault, added for PR49095 just for 4.7+.
Jakub
On Thu, Feb 2, 2012 at 9:15 AM, Jakub Jelinek wrote:
> This peephole, as shown on the testcase, happily transforms a QImode
> memory load into a register, followed by SImode addition of that reg and
> %ebp, followed by QImode store of that back into the same memory and
> QImode comparison of that
On Wed, 1 Feb 2012, Jakub Jelinek wrote:
> Hi!
>
> vinfo_for_stmt can't be used on stmts outside of the current loop.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2012-02-01 Jakub Jelinek
>
> PR tree-optimization/52073
> * tree-v
Hi!
This peephole, as shown on the testcase, happily transforms a QImode
memory load into a register, followed by SImode addition of that reg and
%ebp, followed by QImode store of that back into the same memory and
QImode comparison of that with zero into a QImode addition of the register
to the m
55 matches
Mail list logo
