> Frankly at this stage, I do not think it makes sense to maintain an
> Ada port for DJGPP and in particular maintain all these extra
> special cases and #ifdefs.
I don't think this is a reasonable attitude to take with people who
are willing to do the work to do it. Frankly, I'd like to take Ad
The attached patch has been built and tested on x86_64-*-freebsd.
There are no regression in the testing. OK to commit?
2016-07-30 Steven G. Kargl
PR fortran/41922
* target-memory.c (expr_to_char): Pass in locus and use it in error
messages.
(gfc_merge_initializ
I've committed the following patch.
2016-07-30 Steven G. Kargl
PR fortran/68566
* check.c (gfc_check_reshape): Check for constant expression.
2016-07-30 Steven G. Kargl
PR fortran/68566
* gfortran.dg/pr68566.f90: new test.
Index: gcc/fortran/check.c
==
On Sat, Jul 30, 2016 at 11:37:46AM -0400, Michael Meissner wrote:
> I noticed I forgot to include one of the changes in the ChangeLog file
> (rtx_is_swappable_p). This change was originally meant to be in the previous
> patch, and it got left out. The corrected ChangeLog is:
But put it on the co
On Sat, Jul 30, 2016 at 11:29:25AM -0400, Michael Meissner wrote:
> This patch adds better support for optimizing vec_extract of vector double or
> vector long on 64-bit machines with direct move when the vector is in memory.
> I have tested this on a big endian power7 system (both 32-bit and 64-b
I noticed I forgot to include one of the changes in the ChangeLog file
(rtx_is_swappable_p). This change was originally meant to be in the previous
patch, and it got left out. The corrected ChangeLog is:
[gcc]
2016-07-30 Michael Meissner
* config/rs6000/rs6000-protos.h (rs6000_adjust
This patch adds better support for optimizing vec_extract of vector double or
vector long on 64-bit machines with direct move when the vector is in memory.
It converts the memory address from a vector address to the address of the
element, paying attention to the address mode allowed by the registe
On Sat, Jul 30, 2016 at 08:17:59AM +, Bernd Edlinger wrote:
> Ok, I the incorrect REG_POINTER is done here:
>
> cse_main -> reg_scan -> reg_scan_mark_refs -> set_reg_attrs_from_value
>
> and here I see a bug, because if POINTERS_EXTEND_UNSIGNED
> can_be_reg_pointer is only set to false if x i
On Fri, Jul 29, 2016 at 8:34 PM, H.J. Lu wrote:
> TImode register referenced in debug insn can be converted to V1TImode by
> scalar to vector optimization. When converting a TImode store to V1TImode,
> we need to check all debug insns on its use chain to convert the V1TImode
> register to SUBREG
On 07/29/16 15:03, Bernd Edlinger wrote:
> On 07/29/16 09:02, Segher Boessenkool wrote:
>> On Thu, Jul 28, 2016 at 08:59:44PM +, Bernd Edlinger wrote:
>>> (insn 1047 1044 1048 101 (set (reg/f:DI 481)
>>> (subreg:DI (reg/f:SI 545) 0)) isl_input.c:2496 50
>>> {*movdi_aarch64}
>>>
Frankly at this stage, I do not think it makes sense to maintain an Ada port
for DJGPP and in particular maintain all these extra special cases and #ifdefs.
How many users are we talking about here?
Arno
> This is first of 4 patches for DJGPP support of Ada compiler
>
> Patch adds support of ha
11 matches
Mail list logo