*ping*
Alexander
2013/4/18 Patrick Marlier :
> Hi Alexander,
>
> On Thu, Apr 18, 2013 at 12:49 PM, Alexander Ivchenko
> wrote:
>> I'm trying it on linux/x86_64 on trunk. Testing just by adding -fpic
>> to the dg-options:
>>
>> --- a/gcc/testsuite/g++.dg/tm/pr47746.C
>> +++ b/gcc/testsuite/g++.d
Oh, sorry. Missed the last msg from Mike in that thread.
2013/5/27 Alexander Ivchenko :
> *ping*
>
> Alexander
>
> 2013/4/18 Patrick Marlier :
>> Hi Alexander,
>>
>> On Thu, Apr 18, 2013 at 12:49 PM, Alexander Ivchenko
>> wrote:
>>> I'm trying it on linux/x86_64 on trunk. Testing just by adding
> Please find attached the updated patch.
Thanks. Still, although reg_mode[regno] is indeed tested above, in
+ for (i = hard_regno_nregs[regno][mode] - 1; i > 0; i--)
+if (reg_mode[i] != BLKmode)
+ return false;
this should be reg_mode[regno + i] instead of reg_mode[i].
And one the n
On Fri, 24 May 2013, Martin Jambor wrote:
> Hi,
>
> On Thu, May 23, 2013 at 11:38:10AM +0200, Richard Biener wrote:
> > On Thu, 23 May 2013, Eric Botcazou wrote:
> >
> > > > earlier this week I asked on IRC whether we could have non-top-level
> > > > BIT_FIELD_REFs and Richi said that we could.
On Sun, May 26, 2013 at 5:53 AM, Easwaran Raman wrote:
> On Sat, May 25, 2013 at 4:46 AM, Richard Biener
> wrote:
>> Easwaran Raman wrote:
>>
>>>In that case, if my insert_stmt immediately follows dep_stmt and both
>>>have the same UID, not_dominated_by would return true and I will end
>>>up upd
A nitpick: the dragon book was first published 36 years ago... (!)
-miles
--
“There are moments, Jeeves, when one asks oneself, ‘Do trousers matter?’”
“The mood will pass, sir.” [P.G. Wodehouse, "The Code Of The Woosters"]
Hi,
While discussing the issue with the command line option for sincos here:
http://gcc.1065356.n5.nabble.com/PATCH-bionic-Add-foptimize-sincos-tp940918.html
Richard wrote:
> I'd rather think about a way to specify, for all known builtins, whether GCC
> should generate calls to such function wher
The dummy arguments names in a Fortran interface block are part of the
interface as one can use "call proc(argname=value)" besides "call
proc(value)"; thus, the dummy argument names are significant.
The attached patch updates the names in the module file - and for
completeness also in the docu
On Mon, May 27, 2013 at 11:21:37AM +0200, Tobias Burnus wrote:
> The dummy arguments names in a Fortran interface block are part of
> the interface as one can use "call proc(argname=value)" besides
> "call proc(value)"; thus, the dummy argument names are significant.
>
> The attached patch updates
Hi,
Add workaround for LEON 3 FP errata (for the builtins.c bits):
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01950.html
Introduce #pragma GCC diagnostic off (for the diagnostic.c bits):
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01149.html
Thanks in advance.
--
Eric Botcazou
Sorry for taking so long to come back to this (I was traveling all of
last week) ...
>> Ok, so: How about the attached patch as a simple & backportable fix for
>> the regression? (Ok for trunk/4.8/4.7?)
>
> I think that part is okay - but as you mentioned TYPE(*) in your last email:
> That doesn'
The following fixes PR57343 - niter analysis uses multiple_of_p to
check whether a value is a multiple of another, but multiple_of_p
does not refrain from returning true for a * 10 and 10 even when
the multiplication may overflow (and changing that would pessimize
some callers at least while possi
Independent on the outcome of the discussion regarding to comparing
ADDR_EXPRs in operand_equal_p the following presents a more
backportable fix for the SCCVN endless loop. We know that we
compare is_gimple_min_invariant addresses which means we can
resort to a get_addr_base_and_unit_offset compa
On Mon, May 27, 2013 at 11:52 AM, Eric Botcazou wrote:
> Hi,
>
> Add workaround for LEON 3 FP errata (for the builtins.c bits):
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01950.html
Ok.
Thanks,
Richard.
> Introduce #pragma GCC diagnostic off (for the diagnostic.c bits):
> http://gcc.gnu
Janus Weil wrote:
Ok, so: How about the attached patch as a simple & backportable fix for
the regression? (Ok for trunk/4.8/4.7?)
I think that part is okay - but as you mentioned TYPE(*) in your last email:
That doesn't work; I think compare_type_rank should be made asymmetrical in
this regard (
Hi,
Below patch added target specific macros for RX100, RX200, and RX600
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00050.html
Please review the patch and let me know if there should be any
modifications in it?
Regards,
Sandeep Kumar Singh,
KPIT Cummins InfoSystems Ltd.
Pune, India
Testing showed that the finalization wrapper caused errors of the kind:
Error: The intrinsic '_F.rank' declared INTRINSIC at (1) is not
available in the current standard settings but new in TS 29113. Use an
appropriate -std=* option or enable -fall-intrinsics in order to use it.
That's fixed
Hi,
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
>
> PR tree-optimization/57343
> * tree-ssa-loop-niter.c (number_of_iterations_ne_max): Do not
> use multiple_of_p if not TYPE_OVERFLOW_UNDEFINED.
> (number_of_iterations_cond): Do not build the folde
Hi,
This is just a memo about why the testcase failed:
When it tries to compile, we get this:
gcc/testsuite/g++.dg/tm/pr47746.C:20:14: error: unsafe function call
‘void Building::load(InputStream*)’ within ‘transaction_safe’ function
load(stream);
Indeed, with PIC, the 'load' method can be ove
This fixes the latch block used for the new loop in
expand_omp_atomic_pipeline.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2013-05-27 Richard Biener
PR middle-end/57412
* omp-low.c (expand_omp_atomic_pipeline): Use the correct latch
block for t
On Sat, May 25, 2013 at 9:33 PM, Jan Hubicka wrote:
>> Here's an idea that could make it easier to remove the "cfun" global.
>>
>> "cfun" is a major piece of global state within gcc: it's the 5th most
>> accessed variable in the build (accessed in ~4600 places within one stage
>> of a build, based
>
> I think that was one reason crtl was introduced ... to avoid an indirection
> through cfun.
Main reason why I introduced crtl was to get struct function less bloated.
RTL data live for only one function body at a time. It is useless to store them
in a datastructure that is allocated at parsin
On Mon, May 27, 2013 at 3:41 PM, Jan Hubicka wrote:
>>
>> I think that was one reason crtl was introduced ... to avoid an indirection
>> through cfun.
>
> Main reason why I introduced crtl was to get struct function less bloated.
> RTL data live for only one function body at a time. It is useless
On Sat, May 25, 2013 at 3:02 PM, David Malcolm wrote:
> Eliminate all direct references to "cfun" from macros in
> basic-block.h and introduce access methods to control_flow_graph
>
> * basic-block.h (control_flow_graph::get_basic_block_by_idx): New
> accessor metho
Am 26.05.2013 05:58, schrieb Bud Davis:
The changes suggested by:
http://gcc.gnu.org/ml/fortran/2013-05/msg00057.html
have been made in the below diff and test file.
Could someone please commit this ?
I thought you have commit rights?
Note: You added a hyphen to the error message without chan
On 05/16/2013 12:27 AM, Cary Coutant wrote:
>>> How about using dbx_reg_number (XVECEXP (regs, 0, i)) instead? The
>>> bare use of DBX_REGISTER_NUMBER earlier in that function is protected
>>> by a gcc_assert, but this one isn't.
>>
For the respective targets maintainers that drop into the thread:
Small re-diff - but essentially unchanged.
(I made a thinko when adding a _final call to
gfc_trans_class_array_init_assign: Not in all contexts the _final should
be called, only for INTENT(OUT). Thus, I remove the _final call and
deferred it to the actual finalization call. [That also matches
Dear all,
the attached patch now enables the *parsing* of "FINAL ::" - however,
*no* finalization will be done. Adding FINALIZATION will be deferred to
several follow-up patches.
Build on x86-64-gnu-linux.
OK for the trunk?
* * *
Patches pending to be reviewed, which are also required for f
> I agree that it is possible to use define_subst (apart from the fact
> that it doesn't support define_insn_and_split yet). It's just that I
> think it looks hacky and makes the patterns look
> less readable if the reader has to remember that predication is implicit
> when a subst_attr is encounte
29 matches
Mail list logo
