Re: [PATCH] [MIPS] Fix operands for microMIPS SW16, SH16 and SB16
Matthew Fortune matthew.fort...@imgtec.com writes:
Hi Catherine/Richard,
I think there may be some impact on register move costs by introducing
this class.
Yeah, I was worried about that too. I'm going to do some code comparison
tests for SE and MIPS16 to see what happens.
Is it worth having mips_canonicalize_move_class return M16_REGS for
M16_STORE_REGS to reduce the effect on costings? Given the extra
register is only $0 then this would seem mostly acceptable albeit
slightly strange.
This will happen automatically, since M16_STORE_REGS is just M16_REGS
without $16. (M16_STORE_REGS doesn't include $0, since that's handled
as a constant instead.)
However:
Index: config/mips/mips.c
===
--- config/mips/mips.c (revision 209307)
+++ config/mips/mips.c (working copy)
@@ -648,7 +648,7 @@ static mips_one_only_stub *mips16_set_fcsr_stub;
/* Index R is the smallest register class that contains register R. */
const enum reg_class mips_regno_to_class[FIRST_PSEUDO_REGISTER] = {
- LEA_REGS,LEA_REGS, M16_REGS, V1_REG,
+ M16_STORE_REGS, LEA_REGS,M16_REGS, V1_REG,
M16_REGS,M16_REGS, M16_REGS, M16_REGS,
LEA_REGS,LEA_REGS, LEA_REGS, LEA_REGS,
LEA_REGS,LEA_REGS, LEA_REGS, LEA_REGS,
this bit isn't right. We should leave entry 0 alone and change the
M16_REGS entries for every register except $16.
Thanks,
Richard
Re: [v3] complex functions with expression template reals
r209321 (for a patch accepted long ago, I guess it is better to leave a trace in gcc-patches near the commit date) Nope, see the doc, we have ChangeLog and gcc-cvs for this purpose. -- Eric Botcazou
Re: [v3] complex functions with expression template reals
On Sat, 12 Apr 2014, Eric Botcazou wrote: r209321 (for a patch accepted long ago, I guess it is better to leave a trace in gcc-patches near the commit date) Nope, see the doc, we have ChangeLog and gcc-cvs for this purpose. Those don't point to the conversation in gcc-patches where the patch was ok-ed by a maintainer (maybe we should start adding URLs pointing to the gcc-patches messages in commit logs?). I also meant it as a hello to whoever reviewed the patch, but it is true they likely already read new ChangeLog entries or follow (a filtered version of) gcc-cvs. Thanks, I won't do it again in the future :-) -- Marc Glisse
Re: [Patch, fortran] PR60717 - Wrong code with recursive procedure with unlimited polymorphic dummy argument
On Wed, Apr 02, 2014 at 10:29:23PM +0200, Paul Richard Thomas wrote: 2014-04-12 Paul Thomas pa...@gcc.gnu.org PR fortran/58771 * trans.h : Add 'use_offset' bitfield to gfc_se. * trans-array.c (gfc_conv_expr_descriptor) : Use 'use_offset' as a trigger to unconditionally recalculate the offset. trans-expr.c (gfc_conv_intrinsic_to_class) : Use it. (gfc_conv_procedure_call) : Ditto. 2014-04-02 Paul Thomas pa...@gcc.gnu.org PR fortran/58771 * gfortran.dg/unlimited_polymorphic_17.f90 : New test No spaces before : (everywhere), missing dot after New test. Jakub
Re: [patch, libgfortran] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
On Fri, Apr 11, 2014 at 04:57:42PM -0700, Jerry DeLisle wrote: On 04/11/2014 04:31 PM, Tobias Burnus wrote: Jerry DeLisle wrote: I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7. It is a partial revert of the patch to PR38199 which is an optimization of internal unit reads. The original patch was too aggressive. After this revert, I will investigate further to see if I can refine it further. This partial revert looks fine to me - too bad that we have only now learned about this problem. For 4.9 prior the 4.9.0 release, you need approval by Jakub, who probably would like to avoid to have another RC. In case that there is a second RC, I think it would make sense to include this patch as well. Tobias I am waiting for Jakub's approval for 4.9. Given that this is a regression from 4.8.2 and only went into the release branches after that, I think it is ok for 4.9.0 right now, but please make sure it is tested sufficiently (beyond make check, try some larger Fortran apps). Jakub
Re: [patch, libgfortran] PR60128 Wrong ouput using en edit descriptor
This test, after the update on 4.8 in r209070 when the test-case was modified substantially (not really covered by the ChangeLog entry) to be identical to that on trunk, apparently takes a different route in the fortran run-time library on 4.8 compared to trunk. For 4.8, it requires more run-time support on the target system, trigging the tell-tale error message found in gfortran.log: Fortran runtime error: required ftruncate or chsize support not present on some targets, then aborting and flagged as a regression as it passed before that commit. Committed to 4.8 as obvious. Again, this is not required on trunk. IMO this the change is far from obvious and defeats the purpose the changes in the test case which was to run the test on ALL targets. I need to know what are the affected targets, what part of the test triggers the failure, and if it exists a work-around. Cheers, Dominique PS I made a mistake in the SVN entry (it is correct in gcc/testsuite/ChangeLog). Is there a way to fix it?
Re: [PATCH] [MIPS] Fix operands for microMIPS SW16, SH16 and SB16
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com writes:
Hi Catherine/Richard,
I think there may be some impact on register move costs by introducing
this class.
Yeah, I was worried about that too. I'm going to do some code comparison
tests for SE and MIPS16 to see what happens.
OK, I compared the .s testsuite output for -O, -O2, -O3, -Os,
-O -mips16 -mabi=32 and -Os -mips16 -mabi=32 on mips64-linux-gnu.
I also tried CSiBE with -O2 and -Os -mips16 -mabi=32. The code was
identical in all cases so I think we should be OK.
I went ahead and applied the adjusted version of the patch to trunk
as below (because I wanted to add a testcase too).
Adding a new register class is definitely a bit invasive for this stage
of 4.9. OTOH microMIPS is a new feature and it would be good to have
it working in 4.9.0. Since the testing suggests that the patch really
doesn't affect non-microMIPS code, I'd like it to go in 4.9 now.
Richard, Jakub, would that be OK?
Thanks,
Richard
gcc/
2014-04-12 Catherine Moore c...@codesourcery.com
* config/mips/constraints.md: Add new register constraint kb.
* config/mips/mips.md (*movmode_internal): Use constraint kb.
(*movhi_internal): Likewise.
(*movqi_internal): Likewise.
* config/mips/mips.h (M16_STORE_REGS): New register class.
(REG_CLASS_NAMES): Add M16_STORE_REGS.
(REG_CLASS_CONTENTS): Likewise.
* config/mips/mips.c (mips_regno_to_class): Add M16_STORE_REGS.
gcc/testsuite/
* gcc.target/mips/umips-store16-1.c: New test.
Index: gcc/config/mips/constraints.md
===
--- gcc/config/mips/constraints.md 2014-04-12 10:36:09.105788710 +0100
+++ gcc/config/mips/constraints.md 2014-04-12 10:38:48.895224932 +0100
@@ -92,6 +92,9 @@ (define_register_constraint D COP3_RE
;; but the DSP version allows any accumulator target.
(define_register_constraint ka ISA_HAS_DSP_MULT ? ACC_REGS : MD_REGS)
+(define_register_constraint kb M16_STORE_REGS
+ @internal)
+
(define_constraint kf
@internal
(match_operand 0 force_to_mem_operand))
Index: gcc/config/mips/mips.md
===
--- gcc/config/mips/mips.md 2014-04-12 10:36:09.105788710 +0100
+++ gcc/config/mips/mips.md 2014-04-12 10:38:48.925225200 +0100
@@ -4437,7 +4437,7 @@ (define_expand movmode
(define_insn *movmode_internal
[(set (match_operand:IMOVE32 0 nonimmediate_operand
=d,!u,!u,d,e,!u,!ks,d,ZS,ZT,m,*f,*f,*d,*m,*d,*z,*a,*d,*B*C*D,*B*C*D,*d,*m)
- (match_operand:IMOVE32 1 move_operand
d,J,Udb7,Yd,Yf,ZT,ZS,m,!ks,!u,dJ,*d*J,*m,*f,*f,*z,*d,*J*d,*a,*d,*m,*B*C*D,*B*C*D))]
+ (match_operand:IMOVE32 1 move_operand
d,J,Udb7,Yd,Yf,ZT,ZS,m,!ks,!kb,dJ,*d*J,*m,*f,*f,*z,*d,*J*d,*a,*d,*m,*B*C*D,*B*C*D))]
!TARGET_MIPS16
(register_operand (operands[0], MODEmode)
|| reg_or_0_operand (operands[1], MODEmode))
@@ -4578,7 +4578,7 @@ (define_expand movhi
(define_insn *movhi_internal
[(set (match_operand:HI 0 nonimmediate_operand =d,!u,d,!u,d,ZU,m,*a,*d)
- (match_operand:HI 1 move_operand d,J,I,ZU,m,!u,dJ,*d*J,*a))]
+ (match_operand:HI 1 move_operand
d,J,I,ZU,m,!kb,dJ,*d*J,*a))]
!TARGET_MIPS16
(register_operand (operands[0], HImode)
|| reg_or_0_operand (operands[1], HImode))
@@ -4654,7 +4654,7 @@ (define_expand movqi
(define_insn *movqi_internal
[(set (match_operand:QI 0 nonimmediate_operand =d,!u,d,!u,d,ZV,m,*a,*d)
- (match_operand:QI 1 move_operand d,J,I,ZW,m,!u,dJ,*d*J,*a))]
+ (match_operand:QI 1 move_operand
d,J,I,ZW,m,!kb,dJ,*d*J,*a))]
!TARGET_MIPS16
(register_operand (operands[0], QImode)
|| reg_or_0_operand (operands[1], QImode))
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h 2014-04-12 10:36:09.105788710 +0100
+++ gcc/config/mips/mips.h 2014-04-12 10:38:48.924225191 +0100
@@ -1870,6 +1870,7 @@ #define PIC_OFFSET_TABLE_REGNUM \
enum reg_class
{
NO_REGS, /* no registers in set */
+ M16_STORE_REGS, /* microMIPS store registers */
M16_REGS,/* mips16 directly accessible registers */
T_REG, /* mips16 T register ($24) */
M16_T_REGS, /* mips16 registers plus T register */
@@ -1907,6 +1908,7 @@ #define GENERAL_REGS GR_REGS
#define REG_CLASS_NAMES
\
{ \
NO_REGS, \
+ M16_STORE_REGS,\
M16_REGS, \
T_REG, \
RFA: testsuite fix for 4.8 (was Re: [patch, libgfortran] PR60128 Wrong ouput using en edit descriptor)
On Sat, 12 Apr 2014, Dominique Dhumieres wrote:
This test, after the update on 4.8 in r209070 when the test-case was
modified substantially (not really covered by the ChangeLog entry) to be
identical to that on trunk, apparently takes a different route in the
fortran run-time library on 4.8 compared to trunk. For 4.8, it requires
more run-time support on the target system, trigging the tell-tale error
message found in gfortran.log: Fortran runtime error: required ftruncate
or chsize support not present on some targets, then aborting and flagged
as a regression as it passed before that commit. Committed to 4.8 as
obvious. Again, this is not required on trunk.
IMO this the change is far from obvious and defeats the purpose the changes
in the test case which was to run the test on ALL targets.
I need to know what are the affected targets,
...
That seemed to be aiming for a far more intrusive change than
the situation requires, i.e. not obvious. (But...)
In r209070 on 4.8, you did not just Skip unsupported rounding
tests. XFAIL for i?86-*-solaris2.9* and hppa*-*-hpux* from
trunk revision r208979, which by itself did not introduce any
change in the test-method, but also imported r208780 Update
test. XFAIL for i?86-*-solaris2.9*. The update test part of
that change was actually a rewrite, changing the test-method to
use other means of output. As mentioned, I presumed the fortran
run-time was different on trunk than on 4.8 such that test there
requires truncation of some sort.
Some background to why I thought this was obvious seems in
order. Years ago, the fd_truncate effective target was
introduced to be able to filter-out tests for those
runtime-limited systems (like many simulator targets and
bare-iron based on newlib) that don't support changing the size
of a file. For the background, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293. Since
then, I do as in
http://gcc.gnu.org/ml/fortran/2009-07/msg00095.html when this
happens. The difference here from that time was apparently that
the test-case was changed rather than the run-time, and I saw
no need for further analysis.
But, that wasn't the whole story this time. Sorry!
what part of the test
triggers the failure, and if it exists a work-around.
I started looking at what parts of the test was responsible for
the truncation, but noticed that it was only due to the
presence of the output file fmt_en.res containing the single
line All kinds rounded to nearest. This file is output when
the test is run for 4.8 *as well as on trunk* (fully intended as
obvious from the last lines of the test), and when present
apparently causes the fortran runtime to truncate it (empty it)
such that the first run (when it's absent) succeeds but
subsequent runs fail as mentioned. The key difference between
trunk and 4.8 is actually that the .res file is removed by the
test-harness on trunk through the cleanup-saved-temps call after
the test, but not for 4.8. So, a better change is IMHO to
import that for 4.8 instead, as follows.
I did import *all* changes to this function, as that seemed
better than just adding .res as seen in the first hunk. I
believe this follows best practice for regarding imports of
testsuite framework to branches, but perhaps that's a matter of
taste.
Since this (besides the revert) is less than obvious, ok for 4.8?
Tested by noticing the intended change happens for fmt_en.f90.
4.8 gcc/testsuite:
* gfortran.dg/fmt_en.f90: Revert previous change.
* lib/gcc-dg.exp (cleanup-saved-temps): Update from trunk.
Index: gfortran.dg/fmt_en.f90
===
--- gfortran.dg/fmt_en.f90 (revision 209333)
+++ gfortran.dg/fmt_en.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run { target fd_truncate } }
+! { dg-do run }
! PR60128 Invalid outputs with EN descriptors
! Test case provided by Walt Brainerd.
program pr60128
Index: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp (revision 209333)
+++ lib/gcc-dg.exp (working copy)
@@ -600,7 +600,7 @@ proc cleanup-saved-temps { args } {
set suffixes {}
# add the to-be-kept suffixes
-foreach suffix {.mii .ii .i .s .o .gkd} {
+foreach suffix {.mii .ii .i .s .o .gkd .res .ltrans.out} {
if {[lsearch $args $suffix] 0} {
lappend suffixes $suffix
}
@@ -611,6 +611,8 @@ proc cleanup-saved-temps { args } {
set testcase [lindex $testcase 0]
foreach suffix $suffixes {
remove-build-file [file rootname [file tail $testcase]]$suffix
+ remove-build-file [file rootname [file tail $testcase]].exe$suffix
+ remove-build-file [file rootname [file tail
$testcase]].exe.ltrans\[0-9\]*$suffix
# -fcompare-debug dumps
remove-build-file [file rootname [file tail $testcase]].gk$suffix
}
@@ -620,6 +622,9 @@ proc cleanup-saved-temps { args } {
foreach srcfile
Re: Fwd: [Patch, fortran] PR60717 - Wrong code with recursive procedure with unlimited polymorphic dummy argument
Dear All,
I have upgraded this patch slightly to fix PR58085 as well. I would
judge this to be completely safe because the fixes depend on the new
bit flag for both PRs.
Bootstrapped and regtested on FC17/x86_64 - OK for 4.9 immediately and trunk?
Paul
2014-04-12 Paul Thomas pa...@gcc.gnu.org
PR fortran/60717
PR fortran/58085
* trans.h: Add 'use_offset' bitfield to gfc_se.
* trans-array.c (gfc_conv_expr_descriptor): Use 'use_offset'
as a trigger to unconditionally recalculate the offset for
array slices and constant arrays.
trans-expr.c (gfc_conv_intrinsic_to_class): Use it.
trans-stmt.c (trans_associate_var): Ditto.
(gfc_conv_procedure_call): Ditto.
2014-04-12 Paul Thomas pa...@gcc.gnu.org
PR fortran/60717
* gfortran.dg/unlimited_polymorphic_17.f90: New test.
PR fortran/58085
* gfortran.dg/associate_15.f90: New test.
On 12 April 2014 10:30, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Apr 12, 2014 at 07:27:00AM +0200, Paul Richard Thomas wrote:
I know that you are probably snowed under with requests like this! I
was away on a business trip when Mikael's approval below came and had
intended to apply it to 4.9 aka trunk today. Is it OK with you if I
slip it into 4.9 or should I let it go until after the release?
I'd prefer to put it in after the release, especially for non-regressions
or regressions that aren't regressions from 4.8.2.
4.9.1 will be probably 2 months away from 4.9.0, and many people use release
branch snapshots anyway, but I'd prefer to avoid any risks of slipping the
release further.
Jakub
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 209322)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_conv_expr_descriptor (gfc_se *se, gf
*** 6807,6814
/* Set offset for assignments to pointer only to zero if it is not
the full array. */
! if (se-direct_byref
! info-ref info-ref-u.ar.type != AR_FULL)
base = gfc_index_zero_node;
else if (GFC_ARRAY_TYPE_P (TREE_TYPE (desc)))
base = gfc_evaluate_now (gfc_conv_array_offset (desc), loop.pre);
--- 6807,6815
/* Set offset for assignments to pointer only to zero if it is not
the full array. */
! if ((se-direct_byref || se-use_offset)
! ((info-ref info-ref-u.ar.type != AR_FULL)
! || (expr-expr_type == EXPR_ARRAY se-use_offset)))
base = gfc_index_zero_node;
else if (GFC_ARRAY_TYPE_P (TREE_TYPE (desc)))
base = gfc_evaluate_now (gfc_conv_array_offset (desc), loop.pre);
*** gfc_conv_expr_descriptor (gfc_se *se, gf
*** 6893,6905
stride, info-stride[n]);
if (se-direct_byref
! info-ref
! info-ref-u.ar.type != AR_FULL)
{
base = fold_build2_loc (input_location, MINUS_EXPR,
TREE_TYPE (base), base, stride);
}
! else if (GFC_ARRAY_TYPE_P (TREE_TYPE (desc)))
{
tmp = gfc_conv_array_lbound (desc, n);
tmp = fold_build2_loc (input_location, MINUS_EXPR,
--- 6894,6906
stride, info-stride[n]);
if (se-direct_byref
! ((info-ref info-ref-u.ar.type != AR_FULL)
! || (expr-expr_type == EXPR_ARRAY se-use_offset)))
{
base = fold_build2_loc (input_location, MINUS_EXPR,
TREE_TYPE (base), base, stride);
}
! else if (GFC_ARRAY_TYPE_P (TREE_TYPE (desc)) || se-use_offset)
{
tmp = gfc_conv_array_lbound (desc, n);
tmp = fold_build2_loc (input_location, MINUS_EXPR,
*** gfc_conv_expr_descriptor (gfc_se *se, gf
*** 6935,6942
gfc_get_dataptr_offset (loop.pre, parm, desc, offset,
subref_array_target, expr);
! if ((se-direct_byref || GFC_ARRAY_TYPE_P (TREE_TYPE (desc)))
!se-data_not_needed)
{
/* Set the offset. */
gfc_conv_descriptor_offset_set (loop.pre, parm, base);
--- 6936,6944
gfc_get_dataptr_offset (loop.pre, parm, desc, offset,
subref_array_target, expr);
! if (((se-direct_byref || GFC_ARRAY_TYPE_P (TREE_TYPE (desc)))
!se-data_not_needed)
+ || (se-use_offset base != NULL_TREE))
{
/* Set the offset. */
gfc_conv_descriptor_offset_set (loop.pre, parm, base);
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 209322)
Re: Hurd port for gcc go PATCH 0-3 (9)
On Fri, 2014-04-11 at 07:48 -0700, Ian Lance Taylor wrote: On Fri, Apr 11, 2014 at 5:47 AM, Svante Signell svante.sign...@gmail.com wrote: Attached are patches to enable gccgo to build properly on Debian GNU/Hurd on gcc-4.9 (4.9-20140406). Thanks. Will review after 4.9 has branched. Thanks! Modified patches will follow soon based on the comments made by Samuel and some other changes. Note: Creating the Makefile.in is hard (unnecessary) work since automake is no longer used in the build system. Both (cd src/libgo;automake-1.11) and (cd src/libgo;autoreconf2.64) fails. The diff for Makefile.in has to be patched by hand with the aid of the diff for Makefile.am :( This file should be possible to generate from Makefile.am when modifying manually. In my opinion the build system is broken wrt libgo. I don't understand this comment. The GCC libraries do still use automake. I regularly use automake to regenerate the libgo Makefile.in file. What fails when you try it? (cd src/libgo;automake-1.11) aclocal.m4:16: warning: this file was generated for autoconf 2.64. You have another version of autoconf. It may work, but is not guaranteed to. If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'. config/go.m4:10: error: m4_copy: won't overwrite defined macro: AC_LANG_CONFTEST(Go) config/go.m4:10: the top level autom4te: /usr/bin/m4 failed with exit status: 1 automake-1.11: autoconf failed with exit status: 1 (cd src/libgo;autoreconf2.64) configure.ac:22: error: Autoconf version 2.65 or higher is required /usr/share/aclocal-1.14/init.m4:29: AM_INIT_AUTOMAKE is expanded from... configure.ac:22: the top level autom4te2.64: /usr/bin/m4 failed with exit status: 63 aclocal: error: echo failed with exit status: 63 autoreconf2.64: aclocal failed with exit status: 63 Installing autoconf2.65 does not work either :( dpkg -i autoconf_2.65-4_all.deb' dpkg: warning: downgrading autoconf from 2.69-6 to 2.65-4 (Reading database ... 183400 files and directories currently installed.) Preparing to unpack .../autoconf_2.65-4_all.deb ... Unpacking autoconf (2.65-4) over (2.69-6) ... Setting up autoconf (2.65-4) ... (cd src/libgo;autoreconf) configure.ac:10: error: Please use exactly Autoconf 2.64 instead of 2.65. ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:10: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: error: echo failed with exit status: 1 autoreconf: aclocal failed with exit status: 1
Re: Hurd port for gcc go PATCH 0-3 (9)
On Sat, 2014-04-12 at 16:04 +0200, Svante Signell wrote: On Fri, 2014-04-11 at 07:48 -0700, Ian Lance Taylor wrote: On Fri, Apr 11, 2014 at 5:47 AM, Svante Signell svante.sign...@gmail.com wrote: I don't understand this comment. The GCC libraries do still use automake. I regularly use automake to regenerate the libgo Makefile.in file. What fails when you try it? It seems that it is a Debian problem, they don't use automake any more, they use */Makefile.in for building. (and creating Makefile.in from Makefile.am is broken). Sorry for the noise, I'll file a bug in Debian BTS about this.
Re: Hurd port for gcc go PATCH 0-3 (9)
On Sat, Apr 12, 2014 at 7:04 AM, Svante Signell svante.sign...@gmail.com wrote: (cd src/libgo;automake-1.11) aclocal.m4:16: warning: this file was generated for autoconf 2.64. You have another version of autoconf. It may work, but is not guaranteed to. To rebuild any of the GCC configuration generated files, you must build and install the appropriate versions of autoconf, automake, and libtool yourself, all using the same --prefix, and put the install bin directory first on your PATH. You can't use the system versions. The current versions are automake 1.11, autoconf 2.64, libtool 2.2.7a. Ian
Re: [Patch, avr] Propagate -mrelax gcc driver flag to assembler
Senthil Kumar Selvaraj schrieb:
This patch modifies AVR target's ASM spec to pass -mlink-relax to the
assembler if -mrelax is passed to the compiler driver. This was already
being passed on to the linker, this patch merely makes the assembler
also aware of it.
The corresponding patch in binutils to handle the -mlink-relax patch is
already committed in the binutils repo. I'm not sure how to manage a
running a newer gcc with an older version of binutils though - how is this
generally handled?
The right place is gcc/configure.ac and have a macro defined depending
on whether gas supports -mlink-relax.
Same should be done for -mrmw, IMO, for similar reasons, e.g. something like
case $target in
...
avr-*-*)
...
gcc_GAS_CHECK_FEATURE([-mrmw option], gcc_cv_as_avr_mrmw,,
[-mrmw], [.text],,
[AC_DEFINE(HAVE_AS_AVR_MRMW_OPTION, 1,
[Define if your assembler supports -mrmw option.])])
or
gcc_GAS_CHECK_FEATURE([-mrmw option], gcc_cv_as_avr_mrmw,,
[-mrmw], [.text],,,)
if test x$gcc_cv_as_avr_mrmw = xyes; then
AC_DEFINE(HAVE_AS_AVR_MRMW_OPTION, 1,
[Define if your assembler supports the -mrmw option.])
However, the gcc-4_9-branch has already been created...
Johann
If ok, could someone commit please? I don't have commit access.
Regards
Senthil
2014-04-11 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com
* config/avr/avr.h: Modify ASM_SPEC to pass -mlink-relax
to assembler.
diff --git gcc/config/avr/avr.h gcc/config/avr/avr.h
index 78434ec..c1b4dd9 100644
--- gcc/config/avr/avr.h
+++ gcc/config/avr/avr.h
@@ -512,7 +512,8 @@ extern const char *avr_device_to_sp8 (int argc, const char
**argv);
%{!fenforce-eh-specs:-fno-enforce-eh-specs} \
%{!fexceptions:-fno-exceptions}
-#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})
+#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})\
+%{mrelax:-mlink-relax}
#define LINK_SPEC \
%{mrelax:--relax\
[patch, fortran] Fix PR 59604
Hello world,
please find attached a patch for PR 59604.
The patch makes sure that, if -fno-range-check is specified,
using int on an overflowing boz constant yields the same
result for compile-time simplification and run-time
execution.
OK for trunk?
Thomas
2014-03-12 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/59604
* gfortran.h (gfc_convert_mpz_to_signed): Add prototype.
* arith.c (gfc_int2int): Convert number to signed if
arithmetic overflow is not checked.
* simplify.c (convert_mpz_to_unsigned): Only trigger assert for
size if range checking is in force.
(convert_mpz_to_signed): Make non-static, rename to
(gfc_convert_mpz_to_signed).
(simplify_dshift): Use gfc_convert_mpz_to_signed.
(gfc_simplify_ibclr): Likewise.
(gfc_simplify_ibits): Likewise.
(gfc_simplify_ibset): Likewise.
(simplify_shift): Likewise.
(gfc_simplify_ishiftc): Likewise.
(gfc_simplify_maskr): Likewise.
(gfc_simplify_maskl): Likewise.
2014-03-12 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/59604
* gfortran.dg/no_range_check_3.f90: New test.
Index: gfortran.h
===
--- gfortran.h (Revision 206202)
+++ gfortran.h (Arbeitskopie)
@@ -3018,4 +3018,8 @@ typedef int (*walk_expr_fn_t) (gfc_expr **, int *,
int gfc_expr_walker (gfc_expr **, walk_expr_fn_t, void *);
int gfc_code_walker (gfc_code **, walk_code_fn_t, walk_expr_fn_t, void *);
+/* simplify.c */
+
+void gfc_convert_mpz_to_signed (mpz_t, int);
+
#endif /* GCC_GFORTRAN_H */
Index: arith.c
===
--- arith.c (Revision 206202)
+++ arith.c (Arbeitskopie)
@@ -1976,6 +1976,17 @@ gfc_int2int (gfc_expr *src, int kind)
}
}
+ /* If we do not trap numeric overflow, we need to convert the number to
+ signed, throwing away high-order bits if necessary. */
+ if (gfc_option.flag_range_check == 0)
+{
+ int k;
+
+ k = gfc_validate_kind (BT_INTEGER, kind, false);
+ gfc_convert_mpz_to_signed (result-value.integer,
+ gfc_integer_kinds[k].bit_size);
+}
+
return result;
}
Index: simplify.c
===
--- simplify.c (Revision 206202)
+++ simplify.c (Arbeitskopie)
@@ -151,8 +151,10 @@ convert_mpz_to_unsigned (mpz_t x, int bitsize)
if (mpz_sgn (x) 0)
{
- /* Confirm that no bits above the signed range are unset. */
- gcc_assert (mpz_scan0 (x, bitsize-1) == ULONG_MAX);
+ /* Confirm that no bits above the signed range are unset if we
+ are doing range checking. */
+ if (gfc_option.flag_range_check != 0)
+ gcc_assert (mpz_scan0 (x, bitsize-1) == ULONG_MAX);
mpz_init_set_ui (mask, 1);
mpz_mul_2exp (mask, mask, bitsize);
@@ -175,13 +177,15 @@ convert_mpz_to_unsigned (mpz_t x, int bitsize)
If the bitsize-1 bit is set, this is taken as a sign bit and
the number is converted to the corresponding negative number. */
-static void
-convert_mpz_to_signed (mpz_t x, int bitsize)
+void
+gfc_convert_mpz_to_signed (mpz_t x, int bitsize)
{
mpz_t mask;
- /* Confirm that no bits above the unsigned range are set. */
- gcc_assert (mpz_scan1 (x, bitsize) == ULONG_MAX);
+ /* Confirm that no bits above the unsigned range are set if we are
+ doing range checking. */
+ if (gfc_option.flag_range_check != 0)
+gcc_assert (mpz_scan1 (x, bitsize) == ULONG_MAX);
if (mpz_tstbit (x, bitsize - 1) == 1)
{
@@ -1943,7 +1947,7 @@ simplify_dshift (gfc_expr *arg1, gfc_expr *arg2, g
mpz_setbit (result-value.integer, shift + i);
/* Convert to a signed value. */
- convert_mpz_to_signed (result-value.integer, size);
+ gfc_convert_mpz_to_signed (result-value.integer, size);
return result;
}
@@ -2561,7 +2565,7 @@ gfc_simplify_ibclr (gfc_expr *x, gfc_expr *y)
mpz_clrbit (result-value.integer, pos);
- convert_mpz_to_signed (result-value.integer,
+ gfc_convert_mpz_to_signed (result-value.integer,
gfc_integer_kinds[k].bit_size);
return result;
@@ -2619,7 +2623,7 @@ gfc_simplify_ibits (gfc_expr *x, gfc_expr *y, gfc_
free (bits);
- convert_mpz_to_signed (result-value.integer,
+ gfc_convert_mpz_to_signed (result-value.integer,
gfc_integer_kinds[k].bit_size);
return result;
@@ -2646,7 +2650,7 @@ gfc_simplify_ibset (gfc_expr *x, gfc_expr *y)
mpz_setbit (result-value.integer, pos);
- convert_mpz_to_signed (result-value.integer,
+ gfc_convert_mpz_to_signed (result-value.integer,
gfc_integer_kinds[k].bit_size);
return result;
@@ -3093,7 +3097,7 @@ simplify_shift (gfc_expr *e, gfc_expr *s, const ch
}
}
- convert_mpz_to_signed (result-value.integer, bitsize);
+ gfc_convert_mpz_to_signed (result-value.integer, bitsize);
free (bits);
return result;
@@ -3234,7 +3238,7 @@
Re: [DOC PATCH] Rewrite docs for inline asm
On Tue, 8 Apr 2014, dw wrote:
The general bits seems like a big improvement, but what worries
me is the deleted text. For example, the aspects of Explicit
Reg Vars when *directly feeding an asm* and how to write them
to avoid the named registers being call-clobbered between
assignment and the asm. (Don't confuse this with the
asm-clobber operands which I think you covered fine.) Those
details are maybe not thoughtfully described, but they can't be
just plainly removed as they also serve as gcc specification;
definitions as to what works and doesn't work! (I don't know if
that was the only occurrence.)
I don't believe that section you are talking about was actually deleted, but
has instead been moved (along with Asm Labels and Size of an asm).
No, it does seem deleted, I can't find it. I can only find its
deletion in the patch, not any re-insert or rewrite and I can't
find this information in the web-pages at limegreensocks. To
wit: where's the corresponding information; the replacement for
the section which started with Sometimes you need to make an
@code{asm} operand be a specific register, but there's no
matching constraint letter for that register and had the two
sysint examples? Maybe best placed in a separate subsection
cross-referenced from the top Extended-Asm Remarks section or
when first discussing constraints, in the Output Operands
subsection.
Looking at the new docs, instead of those sections being buried with the ~60
other items like in the old docs
(http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Extensions.html), (nearly) all
the asm-related subjects got moved here
(http://www.LimeGreenSocks.com/gcc/Using-Assembly-Language-with-C.html).
That's what the minor reorg of asm-related sections was about.
I did get this, I read the thread. But, speaking of that, I
can't find anyone mentioning the copyright issue. Maybe people
didn't want to scare you away... Someone has said that FSF were
moving towards it sometimes wouldn't be required anymore, but
that comment was made about a year ago and I don't know if
anything has actually changed, so: assuming this is still
required, are copyright assignment papers in place with the FSF
for these changes? I can't find any dw (or maybe too many) in
the canonical copyright.list just refreshed so I can't tell.
Also, do we really want to document the trick in
m ((@{ struct @{ char x[10]; @} *p = (void *) ptr ; *p; @}))
(note: reformatted GNU-style and confusing @{ @} dropped)
IIRC this is from Linux, but I don't think GCC ever promised the
described semantics, and I don't think we should document
something that works just by accident. Do we want to make that
promise now?
I got that trick (formatting and all) from the existing docs. Such being the
case, the question is do we want to @emph{stop} promising something that we
used to?
No, absolutely not. This is the joy of reorganising things
(code as well as docs): you get blamed for old warts and errors
as well! :-)
Bootstrapping and testing:
I have tested make html to produce html files, but my configuration
doesn't
allow for the make dvi test.
That requirement is somewhat arcane
I got it off the contrib page (http://gcc.gnu.org/contribute.html#docchanges)
when I was trying to figure out the proper way to submit this. If this is
no longer a requirement, perhaps this should be updated.
(I know you later got this, so just for the record here): I
wrote arcane here, not obsolete as I meant that perhaps dvi
should be replaced by pdf, but maybe not. The point is to check
that the layout works for the printable version which has
stricter formatting requirements than the html version. I know
it spews lots of warnings; changes are supposed to not make this
worse. If it errors out due to formatting changes before your
changes: no, you don't have to fix it.
brgds, H-P
