> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jiangning Liu
> Sent: Wednesday, December 21, 2011 2:48 PM
> To: 'Richard Henderson'
> Cc: gcc-patches@gcc.gnu.org; 'Richard Guenther'
> Subject: RE: [RFC] Use REG_EXPR in bac
On 01/11/2012 10:39 PM, Nick Clifton wrote:
> +(define_expand "return"
> + [(return)]
> + ""
> + "rx_expand_epilogue (false); DONE;"
> +)
Not an ideal solution, since the availability of this pattern implies
it's extremely cheap, and we'll replace jumps to the epilogue with
this pattern.
A hac
> validation fixups...
More of them
-benjamin2012-01-11 Benjamin Kosnik
* htdocs/gcc-4.7/porting_to.html: Fixup for validation.
Index: htdocs/gcc-4.7/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/por
A function type with the x86 fastcall attribute is different from one
without it, but standard_conversion was ignoring attributes. Changed to
use same_type_p on the static function type rather than trying to
duplicate the logic here.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9a052
I have committed a patch to update libgo to the weekly.2011-12-14
release. As usual I am only including the changes to files that are
specific to the gccgo frontend. In this case the math package has
changed somewhat and I've adapted gccgo to call the libc math functions
in several cases. Bootst
I noticed that the function decls for builtin functions were all being
marked as varargs. This perplexing problem turned out to be due to
void_list_node not being initialized when the builtin functions were
declared. Why the frontend needs to initialize void_list_node is beyond
me, but I'm not go
validation fixups...
-benjamin2012-01-11 Benjamin Kosnik
* htdocs/gcc-4.7/porting_to.html: Fixup for validation.
Index: htdocs/gcc-4.7/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/porting_to.html,v
retr
Submitted to google 4.6 branch.
On Wed, Jan 11, 2012 at 3:51 PM, Xinliang David Li wrote:
> Good for google branches.
>
> Please re-submit the combined runtime support patch to trunk for review.
Will do.
Thanks,
-Sri.
>
> thanks,
>
> David
>
> On Wed, Jan 11, 2012 at 12:06 PM, wrote:
>> New
As requested by Jakub.
I thought it better to get this in, warts and all, and have it be
corrected than to dally around again and have it not checked in.
-benjamin2012-01-11 Benjamin Kosnik
* htdocs/gcc-4.7/porting_to.html: Add.
Index: htdocs/gcc-4.7/porting_to.html
Good for google branches.
Please re-submit the combined runtime support patch to trunk for review.
thanks,
David
On Wed, Jan 11, 2012 at 12:06 PM, wrote:
> New patch uploaded with the changes.
>
>
> * i386.c (IX86_BUILTIN_CPU_IS_AMDFAM15H_BDVER1): New enum value.
> (IX86_BUILTIN
The Go language was tweaked to permit converting a string to a slice of
the byte or rune type even if the type is given a different name. This
patch implements this tweak in the gccgo frontend. Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 4a
Paolo Carlini writes:
> ... watch out trailing blank lines ;)
Hopefully fixed below. Thanks for watching.
gcc/cp/
* semantics.c (cp_parser_ctor_initializer_opt_and_function_body):
Set the pointer to the last block of the constructor to the
current statement.
(b
On Wed, 11 Jan 2012, Joseph S. Myers wrote:
> On Wed, 11 Jan 2012, Hans-Peter Nilsson wrote:
>
> > I don't see anything matching in copyright.list, which has to be
> > in place first. No blanket assignment for KPIT or KPIT Cummins.
> > Maybe I'm missing something.
>
> I'd generally understand
>
>
... watch out trailing blank lines ;)
Thanks!
Paolo
Hello,
Consider this short code snippet:
struct A
{
~A();
};
struct B
{
A a;
constexpr B() {}
};
As explained in the audit trail, this is valid code.
G++ ICEs on it because build_constexpr_constructor_member_initializers
chokes on a CLEANUP_STMT.
This patch fixes the ICE when building the histrogram for
value profile. It's casued by profile mismatch.
Tested with SPEC2000 INT.
This is for google branches.
2012-01-11 Rong Xu
* gcc/profile.c (compute_value_histograms): ignore the
histrogram when the counters not found i
On Wed, 11 Jan 2012, Hans-Peter Nilsson wrote:
> I don't see anything matching in copyright.list, which has to be
> in place first. No blanket assignment for KPIT or KPIT Cummins.
> Maybe I'm missing something.
I'd generally understand
GCC KPIT Cummins Infosystems Ltd2003-04-15
Transfer
If a Go struct or array has any padding, then we can't use memcmp to
compare the values, because if a value is allocated on the stack then
the padding bytes may not be zeroed out. This patch corrects the Go
compiler to check for this possibility, and to use a generated function
if it occurs. This
The assert is not valid for address spaces that support more than one
pointer size, such as the generic space of TPF, mips64, or m32c.
2012-01-11 DJ Delorie
* cfgexpand.c (convert_debug_memory_address): Allow any valid
pointer type, not just the default pointer type.
Index: c
On Thu, 12 Jan 2012, Richard Henderson wrote:
> On 01/11/2012 11:50 PM, Jayant R. Sonar wrote:
> > I don't have commit rights. Please let me know how to proceed.
>
> http://sourceware.org/cgi-bin/pdw/ps_form.cgi
>
> will take care of the commit rights part.
I don't see anything matching in copy
Sorry,
fixed patch is attached.
12.01.2012 00:43, Alexander Basov пишет:
> Hi,
>
> this patch fixes problem when gnat is not able
> to detect illegal program with self renaming of predefined operation,
> when renaming operation is defined with selected component of the same
> package as renaming
Hi,
this patch fixes problem when gnat is not able
to detect illegal program with self renaming of predefined operation,
when renaming operation is defined with selected component of the same
package as renaming declaration.
(please correct me if I wrong in my explanation)
And also this patch fix
Hello Everyone,
This patch is for the C++ Compiler in the Cilkplus branch. It will
implement array notation for N-D triplets for modify expressions.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.
diff --git a/gcc/cp/ChangeLog.cilk b/gcc/cp/ChangeLog.cilk
index 7ac7dde..3ba0406 100644
---
In this testcase we were omitting the mangling scope for a lambda
defined in an NSDMI because we weren't using decl_mangling_context where
needed. After fixing that, we also needed to fix find_substitution to
not treat A as a substitution for foo::bar.
Tested x86_64-pc-linux-gnu, applying to
On 01/11/2012 09:01 PM, Tobias Burnus wrote:
Before your patch: No initialization of automatic data objects
With your patch: Initialization for automatic arrays, but fails with
-fno-automatic.
With my patch: Initialization also for nonconst-length character
strings, no failures with -fno-automat
New patch uploaded with the changes.
* i386.c (IX86_BUILTIN_CPU_IS_AMDFAM15H_BDVER1): New enum value.
(IX86_BUILTIN_CPU_IS_AMDFAM15H_BDVER2): New enum value.
(IX86_BUILTIN_CPU_IS_AMDFAM10H): Rename IX86_BUILTIN_CPU_IS_AMDFAM10.
(IX86_BUILTIN_CPU_IS_AMDFAM10H_BARCE
On 01/11/2012 11:50 PM, Jayant R. Sonar wrote:
> I don't have commit rights. Please let me know how to proceed.
http://sourceware.org/cgi-bin/pdw/ps_form.cgi
will take care of the commit rights part.
r~
Toon Moene wrote:
The first part fixes a regression as "-finit-* -fno-automatic" could be
combined before (albeit without initializing the automatic arrays - but
there was no compile error).
Perhaps we can issue a warning.
Well, with your plus my patch it does initialize automatic arrays and
On 01/11/2012 06:03 PM, Tobias Burnus wrote:
-finit-* creates an initialization for local variables - either as
static initializer or by "initializing" at run time.
The latter also works with automatic variables, but was breaking with
-fno-automatic, which causes all nonautomatic local variable
> If you prefer to do it this way, fine, but I think we should have some
> ENABLE_RTL_CHECKING verification somewhere that the REG_NORETURN vs.
> REG_ARGS_SIZE ordering is always correct.
OK, this is clearly going ouf of proportion. :-) Your latest patch is fine.
--
Eric Botcazou
On 01/11/2012 05:55 PM, Ulrich Weigand wrote:
In either case, it is always odd to have RTX in the insn stream
that isn't "stable" under common simplication ... Do you have
any suggestions on how to fix this? If we add the fwprop patch,
should we then disable apply_distributive_law for SUBREGs?
The test case quad_2.f90 was failing for multiple reasons:
* Some systems support REAL(16) but do not have a sqrtl function
* Some systems have a REAL(16) data type, but with less precision (106
instread of 113 digits)
This patch fixes the issue by adding an effective target macro to check
for
I've committed this gcov patch, which does 2 things:
*) if a source file contains no code, erase any annotation file for it. Such a
file will be misleading as it will refer to a previous instrumented program.
*) dynamically allocate the source line buffer, rather than use a fixed length
buff
I've committed this patch so that libgcov ignores object with no functions.
Such objects can occur when it turns out that none of the instrumented functions
were emitted -- the translation unit ends up with just data objects.
nathan
2012-01-11 Nathan Sidwell
* libgcov.c (__gcov_init): Igno
On Wed, Jan 11, 2012 at 01:59:59PM +0100, Eric Botcazou wrote:
> > I'd find that very fragile. E.g. distribute_notes itself reverses the
> > order of all notes, and for no REG_NOTES I think we rely on any ordering.
>
> AFAIK distribute_notes is the only routine that redistributes the RTL notes
>
-finit-* creates an initialization for local variables - either as
static initializer or by "initializing" at run time.
The latter also works with automatic variables, but was breaking with
-fno-automatic, which causes all nonautomatic local variables to be
placed in static memory. However, co
Richard Sandiford wrote:
> At the moment, fwprop will propagate constants and registers
> even if no further rtl simplifications are possible:
>
> if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
> flags |= PR_CAN_APPEAR;
>
> What do you think about extending this to subregs?
I've been testin
Simple thinko; when copy/pasting this loop from elsewhere we needed to
change decls_match to same_type_p since here we're just dealing with types.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 32ca2088d87e3a3204cc28f4d7fa543d5616f8b6
Author: Jason Merrill
Date: Wed Jan 11 09:05:31 20
The mangled name of an unnamed type can include '.' characters, e.g.,
for an array of a named type. This can then appear in the name used for
a hash or equality function for the type. The code which creates the
externally visible identifier looks for '.' characters. In some cases
this could cau
On Wed, Jan 11, 2012 at 16:04, Tobias Burnus wrote:
> On 01/11/2012 02:08 PM, Janne Blomqvist wrote:
>>
>> Checking for an absolute path is already done a few lines up. So if
>> you prefer the kind of approach that you have in your patch, IMHO a
>> more correct patch would be
>
>
> I had a quick c
To eliminate any possible ambiguity, the patch is "approved"
On 01/10/12 23:49, andreast at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
Andreas Tobler changed:
What|Removed |Added
Same patch with a minor update: I changed "cwd" from "char *" to "const
char *" as I spotted a compile time warning for
cwd = ".";
which was along the lines that by the assignment the const qualifier is
lost.
Too bad that we cannot enable -Werror for libgfortran.
On 01/11/2012 03:04 PM, To
On 01/11/2012 02:08 PM, Janne Blomqvist wrote:
Checking for an absolute path is already done a few lines up. So if
you prefer the kind of approach that you have in your patch, IMHO a
more correct patch would be
I had a quick chat with Kai and decided to leave the lower part as is.
However, I r
gt; (not:SI (match_operator:SI 1 "arm_comparison_operator"
>[(match_operand 2 "cc_register" "") (const_int 0)])))]
>"TARGET_ARM"
> - "mov%D1\\t%0, #0\;mvn%d1\\t%0, #1"
> + "mvn%D1\\t%0, #0\;mvn%d1\\t%0, #1"
>
D1\\t%0, #0\;mvn%d1\\t%0, #1"
+ "mvn%D1\\t%0, #0\;mvn%d1\\t%0, #1"
[(set_attr "conds" "use")
(set_attr "insn" "mov")
(set_attr "length" "8")]
diff --git a/gcc/testsuite/gcc.c-torture/execute/20120111-1.c
b/gcc/te
Thanks for all the help! I'll get this tested and committed to trunk
today.
On Wed, 2012-01-11 at 13:11 +0100, Jakub Jelinek wrote:
> On Wed, Jan 11, 2012 at 10:57:28AM +0100, Richard Guenther wrote:
> > > + tree fndecl;
> > > +
> > > + if (!is_gimple_call (stmt))
> > > +return;
> > > +
> >
On Wed, Jan 11, 2012 at 14:55, Tobias Burnus wrote:
> Dear all,
>
> this is a follow up patch, which I think provides a better handling if
> either getcwd fails or is not availble - or if the pathname in argv[0]
> already is an absolute patch, in which case concatenating
> current-working-director
> I'd find that very fragile. E.g. distribute_notes itself reverses the
> order of all notes, and for no REG_NOTES I think we rely on any ordering.
AFAIK distribute_notes is the only routine that redistributes the RTL notes for
a fixed insn, so I'm a little skeptical about the purported fragilit
Dear all,
this is a follow up patch, which I think provides a better handling if
either getcwd fails or is not availble - or if the pathname in argv[0]
already is an absolute patch, in which case concatenating
current-working-directory + '/' + argv[0] does not really make sense.
Build on x86
Hello Richard and Joseph,
Thanks a lot for reviewing the patch.
I will work on the problems pointed out by Richard. As he has mentioned,
I can check in those changes post-commit. If so, I would prefer that option.
In that case, do we need to wait for someone else's approval or can this
be com
On Wed, Jan 11, 2012 at 10:57:28AM +0100, Richard Guenther wrote:
> > + tree fndecl;
> > +
> > + if (!is_gimple_call (stmt))
> > + return;
> > +
> > + fndecl = gimple_call_fndecl (stmt);
> > +
> > + if (fndecl
> > + && TREE_CODE (fndecl) == FUNCTION_DECL
>
> Not needed.
>
> > + &
> Well, just for record, the final version of patch seems to make sense for me
> ;)
> Thanks! It is an interesting side corner to say at least.
Of course one could craft an function with two builtin_constant_p calls and
the asm statement that is not dominated by either of them but still always
c
> I think it should be unconditionally restrict splitting (I suppose on the
> trunk the __builtin_constant_p is optimized away already).
>
> Btw, this will also disqualify any point below
>
> if (__builtin_constant_p (...))
>{
> ...
>}
>
> because after the if join all BBs are domi
Hi Guys,
I am checking in the patch below to fix a problem building the RX
port. Targets that define the "simple_return" pattern must also
define a "return" pattern. Otherwise gcc/function.c will fail to
build.
Cheers
Nick
gcc/ChangeLog
2012-01-11 Nick Clifton
* config/rx
This patch fixes two issues related to intrinsic operators:
a) No error for nonexisting operators:
USE m, operator(*)
b) An bogus error if one tried to use-associate the same operator
multiple times:
USE m, operator(+), operator(+)
Those are old issues. New issue (and thus the PR is mar
On Wed, Jan 11, 2012 at 10:28:55AM +0100, Eric Botcazou wrote:
> > IMHO reordering the notes in the chain would be even more work than this.
>
> Can't we just move down the lines
>
> if (ecf_flags & ECF_NORETURN)
> add_reg_note (call_insn, REG_NORETURN, const0_rtx);
>
> if (ecf_flags & E
On Wed, Jan 11, 2012 at 11:19 AM, Kai Tietz wrote:
> 2012/1/11 Richard Guenther :
>> On Wed, Jan 11, 2012 at 11:05 AM, Richard Guenther
>> wrote:
>>> On Tue, Jan 10, 2012 at 11:58 AM, Kai Tietz wrote:
2012/1/10 Richard Guenther :
> On Tue, Jan 10, 2012 at 10:58 AM, Kai Tietz
> wro
2012/1/11 Richard Guenther :
> On Wed, Jan 11, 2012 at 11:05 AM, Richard Guenther
> wrote:
>> On Tue, Jan 10, 2012 at 11:58 AM, Kai Tietz wrote:
>>> 2012/1/10 Richard Guenther :
On Tue, Jan 10, 2012 at 10:58 AM, Kai Tietz
wrote:
> Ping
>
> 2012/1/8 Kai Tietz :
>> Hi,
>
On Wed, Jan 11, 2012 at 11:05 AM, Richard Guenther
wrote:
> On Tue, Jan 10, 2012 at 11:58 AM, Kai Tietz wrote:
>> 2012/1/10 Richard Guenther :
>>> On Tue, Jan 10, 2012 at 10:58 AM, Kai Tietz wrote:
Ping
2012/1/8 Kai Tietz :
> Hi,
>
> this patch makes sure that for incr
On Tue, Jan 10, 2012 at 11:58 AM, Kai Tietz wrote:
> 2012/1/10 Richard Guenther :
>> On Tue, Jan 10, 2012 at 10:58 AM, Kai Tietz wrote:
>>> Ping
>>>
>>> 2012/1/8 Kai Tietz :
Hi,
this patch makes sure that for increment of
postfix-increment/decrement we use also orignal lvalue
On Tue, Jan 10, 2012 at 11:15 PM, William J. Schmidt
wrote:
> On Tue, 2012-01-10 at 09:42 -0600, William J. Schmidt wrote:
>>
>> On Tue, 2012-01-10 at 14:53 +0100, Richard Guenther wrote:
>> >
>> > Btw, this will also disqualify any point below
>> >
>> > if (__builtin_constant_p (...))
>> > {
On Tue, 10 Jan 2012, Xinliang David Li wrote:
> of course your new version.
I have installed it on the trunk.
Richard.
> thanks,
>
> David
>
> On Tue, Jan 10, 2012 at 1:31 AM, Richard Guenther wrote:
> > On Mon, 9 Jan 2012, Xinliang David Li wrote:
> >
> >> It looks non-ambiguous to me.
> >
> IMHO reordering the notes in the chain would be even more work than this.
Can't we just move down the lines
if (ecf_flags & ECF_NORETURN)
add_reg_note (call_insn, REG_NORETURN, const0_rtx);
if (ecf_flags & ECF_RETURNS_TWICE)
{
add_reg_note (call_insn, REG_SETJMP, const0_rtx);
On Wed, Jan 11, 2012 at 10:06:55AM +0100, Eric Botcazou wrote:
> > You're right. So how about this patch (untested so far) instead?
> > In the combiner it still needs to handle the case where REG_NORETURN note
> > hasn't been placed yet, because then fixup_args_size_notes doesn't consider
> > it b
> You're right. So how about this patch (untested so far) instead?
> In the combiner it still needs to handle the case where REG_NORETURN note
> hasn't been placed yet, because then fixup_args_size_notes doesn't consider
> it being a noret call.
Still too much work for the combiner in my opinion.
On Tue, Jan 10, 2012 at 8:50 PM, Tijl Coosemans wrote:
> On Tuesday 10 January 2012 15:40:15 Richard Guenther wrote:
>> On Tue, Jan 10, 2012 at 3:38 PM, Richard Guenther
>> wrote:
>>> On Tue, Jan 10, 2012 at 3:14 PM, Tijl Coosemans wrote:
On targets where libc implements stack protector fun
On Tue, Jan 10, 2012 at 8:27 PM, Eric Botcazou wrote:
> This is a couple of regressions present on the mainline. For the first
> testcase at O2 -gnatn:
>
> +===GNAT BUG DETECTED==+
> | 4.7.0 20120102 (experimental) [trunk revision 182780] (i586-
On Wed, Jan 11, 2012 at 09:16:04AM +0100, Eric Botcazou wrote:
> > And for noreturn calls, it doesn't do anything wrong, the problem is that it
> > returns the old size for them.
>
> According to the head comment, that's precisely the problem, since it should
> do
> something for them, in parti
> The new void *data pointer could use a comment on what it is and how it's
> used.
Yes; as a matter of fact, it needs to be documented for mostly_copy_tree_r
first, and probably just referred to for copy_if_shared_r and copy_if_shared.
--
Eric Botcazou
> And for noreturn calls, it doesn't do anything wrong, the problem is that it
> returns the old size for them.
According to the head comment, that's precisely the problem, since it should do
something for them, in particular put back the note.
--
Eric Botcazou
Hi Janne,
On 01/11/2012 08:37 AM, Janne Blomqvist wrote:
Index: runtime/main.c
===
--- runtime/main.c (revision 183089)
+++ runtime/main.c (working copy)
@@ -116,8 +116,10 @@ store_exe_path (const char * argv0)
memset
71 matches
Mail list logo
