> If this usage isn't legitimate, and the CALL_ARG_LOCATION is supposed
> to come directly after the call, then it would be great if someone more
> familiar with the var-tracking code could have a look at it.
"Be liberal in what you accept" says the common wisdom.
> gcc/
> * emit-rtl.c (try
> Here is an alternative, almost completely untested, patch, which
> uses DW_OP_fbreg for the arguments of dynamically realigned functions.
> draptest.c now works...
I've attached a slightly revamped, IMO easier to understand version. Stack
realignment with DRAP is quite seldom on the mainline
On Sun, May 29, 2011 at 12:29 AM, Jan Hubicka wrote:
> Hi,
> this patch makes us to use enum and variable length i/o at places it fits.
> Only non-standard thing is stremaing of built_in_class that does not allow
> adding
> LAST field or we get warning that the type no longer fits in the bitfield
On Sun, May 29, 2011 at 3:07 AM, Gerald Pfeifer wrote:
> On Mon, 23 May 2011, Nicola Pero wrote:
>> Yes ... on the other hand, this does not address the other issue, which
>> is the amount of disk space that you need to actually uncompress the
>> tarballs :-(
>>
>> Unpacking gcc-4.6.0.tar.xx requi
Hi,
Rainer Orth wrote:
> 2010-12-30 Uros Bizjak
> Rainer Orth
>
> * gcc.dg/torture/tls/run-gd.c: New test.
> * gcc.dg/torture/tls/run-ie.c: New test.
> * gcc.dg/torture/tls/run-ld.c: New test.
> * gcc.dg/torture/tls/run-le.c: New test.
> * lib/target-s
Hi,
FX reminded me that execvp() is not guaranteed to be
async-signal-safe, hence we must use execve(). So instead during
library initialization try to find addr2line.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
2011-05-29 Janne Blomqvist
PR libfortran/48931
* libgfo
Hi all,
here is a fix for a problem, where the module loading could not handle
components of extended types. Regtested on x86_64-unknown-linux-gnu.
Ok for trunk?
Cheers,
Janus
2011-05-29 Janus Weil
PR fortran/47601
* module.c (mio_component_ref): Handle components of extend
I committed the patch below as obvious. Together with my recent patch
for PR 48931 this should fix PR 49214.
Index: libgfortran/runtime/backtrace.c
===
--- libgfortran/runtime/backtrace.c (revision 174394)
+++ libgfortran/runtime/
In libcpp/files.c the value of S_ISREG() is assigned to a bool variable.
AFAIK a non-zero value of S_ISREG does not necessary fit into a bool
(unsigned char) so on some systems the file reading is a bit less efficient
wrt its buffer size determination.
Please commit after positive review (I don't
Hello world,
the attached patch fixes PR 45786, where using == instead of .eq. in a
PUBLIC statement caused us to miss exporting the symbol. I introduced a
function for equivalencing INTRINSIC_EQ with INTRINSIC_EQ_OS (and
others), which I also used in another place to tidy up the code a bit.
Re
Hi,
string straming is quite wasteful by creating a copy of every string it gets,
looking it up in hashtable, freeing if it is present and adding otherwise. The
copy is made just to add 0 value to terminate it since htab_hash_string is used
and it expects 0 terminated strings that is not always th
On Sun, May 29, 2011 at 4:31 PM, Jan Hubicka wrote:
> Hi,
> string straming is quite wasteful by creating a copy of every string it gets,
> looking it up in hashtable, freeing if it is present and adding otherwise.
> The
> copy is made just to add 0 value to terminate it since htab_hash_string i
Hi,
This patch uses MAP_ANON if MAP_ANONYMOUS is not defined fixing this
test's failure on x86_64-apple-darwin10.
Tested on x86_64-suse-linux and on x86_64-apple-darwin10 (by Dominique).
OK to apply?
Thanks,
Ira
testsuite/ChangeLog:
PR testsuite/49222
* gcc.dg/vect/pr49038.c: Use MAP
On Sun, May 29, 2011 at 6:36 PM, Ira Rosen wrote:
> Hi,
>
> This patch uses MAP_ANON if MAP_ANONYMOUS is not defined fixing this
> test's failure on x86_64-apple-darwin10.
>
> Tested on x86_64-suse-linux and on x86_64-apple-darwin10 (by Dominique).
> OK to apply?
Ok.
Thanks,
Richard.
> Thanks,
On Sun, May 29, 2011 at 04:08:54PM +0200, Thomas Koenig wrote:
>
> Regression-tested on trunk. OK for trunk and 4.6? What about 4.5?
>
> Thomas
>
> 2011-05-29 Thomas Koenig
>
> PR fortran/45786
> * interface.c (gfc_equivalent_op): New function.
> (gfc_check_i
On Sun, May 29, 2011 at 03:08:48PM +0200, Janus Weil wrote:
>
> here is a fix for a problem, where the module loading could not handle
> components of extended types. Regtested on x86_64-unknown-linux-gnu.
> Ok for trunk?
>
> 2011-05-29 Janus Weil
>
> PR fortran/47601
> * module.c
On Sun, May 29, 2011 at 01:17:05PM +0300, Janne Blomqvist wrote:
>
> FX reminded me that execvp() is not guaranteed to be
> async-signal-safe, hence we must use execve(). So instead during
> library initialization try to find addr2line.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
This fixes PR49217, we should use w, not node when visiting indirect
calls and refs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and branch.
Richard.
2011-05-29 Richard Guenther
PR tree-optimization/49217
* ipa-pure-const.c (propagate_pure_const): F
This patch adds support for fractional exponents C where 2C or 3C is
equivalent to an integer. There is one FIXME in place for the issue
previously noted with respect to tree_expr_nonnegative_p, which I plan
to look at later this week.
Regtested on powerpc64-linux and examined code generation for
On Sat, May 28, 2011 at 07:11:19PM +0200, Tobias Burnus wrote:
> Allocatable coarrays have to be (de)allocated collectively. Thus, it is
> doubtful if one passes a coarray as actual argument to an allocatable
> dummy argument, which is not a coarray (unless the dummy is INTENT(IN)).
> However, a
On Sat, May 28, 2011 at 08:24:48AM +0200, Tobias Burnus wrote:
> Thanks for Richard for debugging this!
>
> Setting TREE_TYPE in trans-decl.c is nonsense and leads to types of the
> form "_Complex _Complex int". The fix is rather obvious.
>
> Build and regtested on x86-64-linux.
> OK for the tru
mips_pic_call_symbol_from_set has code to follow register sets.
In PR target/43995, a dependency loop makes this code recurse
infinitely.
I considered rewriting the code to use a worklist, possibly with
results cached between call sites. However, we should only really
need to follow one register
Mikael Pettersson writes:
> Richard Sandiford writes:
> > PR 45074 showed up a rather embarrassing oversight in the MIPS backend:
> > global registers were still being treated as call-saved.
> >
> > Fixed with the attached patch. Tested on mips64-linux-gnu and applied.
> >
> > Richard
>
Hi,
revision 171520 changed ARM's CANNOT_CHANGE_MODE_CLASS to loosen up on
VFP registers. Richard Sandiford mentioned it being essential for
accessing individual lanes/subregs of vector types.
PR48808 and PR48792 basically triggered after the change due to insns like:
(insn 39 41 43 2 (set (subreg
On Fri, May 27, 2011 at 6:40 PM, Jakub Jelinek wrote:
> This patch adds a few peephole2s to help optimize if (!--*x) etc.
> This is something the combiner doesn't and can't easily handle, because in
> reg0 = mem1
> reg0 {+,-,&,|,^}= x
> mem1 = reg0
> cc = compare (reg0, 0)
> reg0 is used also by
Hi Steve,
On Sun, May 29, 2011 at 04:08:54PM +0200, Thomas Koenig wrote:
Regression-tested on trunk. OK for trunk and 4.6? What about 4.5?
OK for trunk and 4.6. If it applies cleanly to 4.5 and
passes regression testing, then you can also commit to
4.5 at your discretion.
Committed t
On Thu, May 26, 2011 at 7:36 PM, H.J. Lu wrote:
> Since we don't have movmisaligntf pattern, we need to handle misaligned
> load/store in *movtf_internal, similar to *movti_internal_*. OK for
> trunk?
>
> Thanks.
>
>
> H.J.
> ---
> gcc/
>
> 2011-05-26 H.J. Lu
>
> PR target/49168
>
* Jason Merrill:
> Sorry it's taken so long to review this.
Same here. *sigh* Thanks for your comments.
> On 02/21/2011 04:05 PM, Florian Weimer wrote:
>> build_operator_new_call (tree fnname, VEC(tree,gc) **args,
>> -tree *size, tree *cookie_size,
>> +
On Sun, May 29, 2011 at 9:02 PM, Florian Weimer wrote:
> * Jason Merrill:
>
>> Sorry it's taken so long to review this.
>
> Same here. *sigh* Thanks for your comments.
>
>> On 02/21/2011 04:05 PM, Florian Weimer wrote:
>>> build_operator_new_call (tree fnname, VEC(tree,gc) **args,
>>> -
The comment reads:
??? We allow invalid registers if (reg:XMODE XREGNO) is also invalid.
This is a kludge to work around how float/complex arguments are passed
on 32-bit SPARC and should be fixed. */
if (!HARD_REGNO_MODE_OK (yregno, ymode)
&& HARD_REGNO_MODE_OK (xregno
* Richard Guenther:
+ if (!flag_new_overflow_check)
+ return result;
>>>
>>> Let's check for constant results here. If we have a TREE_CONSTANT
>>> result that overflows, we can handle it even if we aren't emitting the
>>> checks for non-constant values.
>>
>> I assume I can report a
Chung-Lin Tang writes:
> An alternative fix direction would be to add similar mode/regclass
> validity checks to all places where CANNOT_CHANGE_MODE_CLASS is used in
> the RTL core, which may stratify things a bit more (the internals
> documentation does not mention anything on whether the backend
>> Ok for trunk?
>>
>> 2011-05-29 Janus Weil
>>
>> PR fortran/47601
>> * module.c (mio_component_ref): Handle components of extended types.
>> * symbol.c (gfc_find_component): Return is sym is NULL.
>>
>> 2011-05-29 Janus Weil
>>
>> PR fortran/47601
>> * gfortran
Richard Sandiford writes:
> + if (GET_MODE (focus) != SUBREG)
Should of course be GET_CODE.
Richard
> I don't think the backend should need to check it, although there are
> probably backends have done so as the path of least resistance.
My opinion as well. CANNOT_CHANGE_CLASS_MODE shoudn't have to duplicate the
information provided by HARD_REGNO_MODE_OK.
> - If we have a reload of a paradoxi
Hello!
Attached patch uses standard_sse_constant_opcode in some more places.
The patch also adds a couple of missing move patterns to
*movdi_internal pattern.
2011-05-29 Uros Bizjak
* config/i386/i386.md (*movoi_internal_avx): Use
standard_sse_constant_opcode for alternative 0
On Fri, 27 May 2011, Andrew Pinski wrote:
> I totally agree 100%. His bug reports have helped GCC a lot. I hope
> he continues to file them.
That's the plan! :-)
On Fri, 27 May 2011, Jakub Jelinek wrote:
> We should mention there John Regehr and his team too in that case.
Sure, Jakub. Mind pr
Eric Botcazou writes:
>> Something like the attached patch. Not tested yet, and I'm sure
>> it'll break things in lots of fun and interesting ways...
>
> Mind posting a (temporarily) definitive version? I'll give it a whirl on the
> SPARC and IA-64 to see how it would fare.
Thanks. With the s
Except or the fortran bits (committed), this patch hasn't been reviewed for
three weeks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
> The calculation of the number of instructions in a row is currently
> done by updating row_rest_count field in struct ps_insn on the fly
> while creating a new instruction. It is used to make sure we do not
> exceed
> the issue_rate.
> This calculation assumes the instruction is inserted in the
Revital Eres wrote on 19/05/2011 07:44:23 AM:
> From: Revital Eres
> To: Ayal Zaks/Haifa/IBM@IBMIL
> Cc: gcc-patches@gcc.gnu.org, Patch Tracking
> Date: 19/05/2011 07:44 AM
> Subject: [PATCH, SMS 2/4] Move the creation of anti-dep edge
>
> Hello,
>
> The attached patch moves the creation of ant
On 05/29/2011 06:14 PM, Richard Guenther wrote:
>
> -/* Returns a hash code for P. */
> +/* Returns a hash code for P.
> + Shamelessly*/
... stolen from libiberty.
?
Ok with that comment adjusted.
Why steal it :) if you can instead add the code to libiberty?
Paolo
42 matches
Mail list logo
