Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check
On 10/22/23 22:48, Neal Frager wrote: There is a microblaze cpu version 10.0 included in versal. If the minor version is only a single digit, then the version comparison will fail as version 10.0 will appear as 100 compared to version 6.00 or 8.30 which will calculate to values 600 and 830. The issue can be seen when using the '-mcpu=10.0' option. With this fix, versions with a single digit minor number such as 10.0 will be calculated as greater than versions with a smaller major version number, but with two minor version digits. By applying this fix, several incorrect warning messages will no longer be printed when building the versal plm application, such as the warning message below: warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a' or greater Signed-off-by: Neal Frager --- gcc/config/microblaze/microblaze.cc | 164 +--- 1 file changed, 76 insertions(+), 88 deletions(-) Please add a test case. -- Michael Eager
Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check
On 10/23/23 11:37, Frager, Neal wrote:
Le 23 oct. 2023 à 18:40, Michael Eager a écrit :
On 10/22/23 22:48, Neal Frager wrote:
There is a microblaze cpu version 10.0 included in versal. If the
minor version is only a single digit, then the version comparison
will fail as version 10.0 will appear as 100 compared to version
6.00 or 8.30 which will calculate to values 600 and 830.
The issue can be seen when using the '-mcpu=10.0' option.
With this fix, versions with a single digit minor number such as
10.0 will be calculated as greater than versions with a smaller
major version number, but with two minor version digits.
By applying this fix, several incorrect warning messages will no
longer be printed when building the versal plm application, such
as the warning message below:
warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a' or greater
Signed-off-by: Neal Frager
---
gcc/config/microblaze/microblaze.cc | 164 +---
1 file changed, 76 insertions(+), 88 deletions(-)
Please add a test case.
--
Michael Eager
Hi Michael,
Would you mind helping me understand how to make a gcc test case for this patch?
This patch does not change the resulting binaries of a microblaze gcc build.
The output will be the same with our without the patch, so I do not having
anything in the binary itself to verify.
All that happens is false warning messages will not be printed when building
with ‘-mcpu=10.0’. Is there a way to test for warning messages?
In any case, please do not commit v1 of this patch. I am going to work on
making a v2 based on Mark’s feedback.
You can create a test case which passes the -mcpu=10.0 and other options
to GCC and verify that the message is not generated after the patch is
applied.
You can make all GCC warnings into errors with the "-Werror" option.
This means that the compile will fail if the warning is issued.
Take a look at gcc/testsuite/gcc.target/aarch64/bti-1.c for an example
of using { dg-options "" } to specify command line options.
There is a test suite option (dg-warning) which checks that a particular
source line generates a warning message, but it isn't clear whether is
is possible to check that a warning is not issued.
--
Michael Eager
Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check
On 10/24/23 00:01, Frager, Neal wrote:
There is a microblaze cpu version 10.0 included in versal. If the
minor version is only a single digit, then the version comparison
will fail as version 10.0 will appear as 100 compared to version
6.00 or 8.30 which will calculate to values 600 and 830.
The issue can be seen when using the '-mcpu=10.0' option.
With this fix, versions with a single digit minor number such as
10.0 will be calculated as greater than versions with a smaller
major version number, but with two minor version digits.
By applying this fix, several incorrect warning messages will no
longer be printed when building the versal plm application, such as
the warning message below:
warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a'
or greater
Signed-off-by: Neal Frager
---
gcc/config/microblaze/microblaze.cc | 164 +---
1 file changed, 76 insertions(+), 88 deletions(-)
Please add a test case.
--
Michael Eager
Hi Michael,
Would you mind helping me understand how to make a gcc test case for this patch?
This patch does not change the resulting binaries of a microblaze gcc build.
The output will be the same with our without the patch, so I do not having
anything in the binary itself to verify.
All that happens is false warning messages will not be printed when building
with ‘-mcpu=10.0’. Is there a way to test for warning messages?
In any case, please do not commit v1 of this patch. I am going to work on
making a v2 based on Mark’s feedback.
You can create a test case which passes the -mcpu=10.0 and other options to GCC
and verify that the message is not generated after the patch is applied.
You can make all GCC warnings into errors with the "-Werror" option.
This means that the compile will fail if the warning is issued.
Take a look at gcc/testsuite/gcc.target/aarch64/bti-1.c for an example of using { dg-options
"" } to specify command line options.
There is a test suite option (dg-warning) which checks that a particular source
line generates a warning message, but it isn't clear whether is is possible to
check that a warning is not issued.
Hi Michael,
Thanks to Mark Hatle's feedback, we have a much simpler solution to the problem.
The following change is actually all that is necessary. Since we are just
moving from
strcasecmp to strverscmp, does v2 of the patch need to have a test case to go
with it?
-#define MICROBLAZE_VERSION_COMPARE(VA,VB) strcasecmp (VA, VB)
+#define MICROBLAZE_VERSION_COMPARE(VA,VB) strverscmp (VA, VB)
I assume there are already test cases that verify that strverscmp works
correctly?
Still need a test case to verify this fix.
--
Michael Eager
Re: [PATCH v3 1/1] gcc: config: microblaze: fix cpu version check
On 10/25/23 01:02, Neal Frager wrote: The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp instead of strverscmp to check the mcpu version against feature options. By simply changing the define to use strverscmp, the new version 10.0 is treated correctly as a higher version than previous versions. Signed-off-by: Neal Frager --- V1->V2: - No need to create a new microblaze specific version check routine as strverscmp is the correct solution. V2->V3: - Changed mcpu define for microblaze isa testsuite examples. --- gcc/config/microblaze/microblaze.cc| 2 +- gcc/testsuite/gcc.target/microblaze/isa/bshift.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/div.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/fcmp1.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/fcmp2.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/fcmp3.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/fcmp4.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/fcvt.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/float.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/fsqrt.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/mul-bshift-pcmp.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/mul-bshift.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/mul.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/mulh-bshift-pcmp.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/mulh.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/nofcmp.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/nofloat.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/pcmp.c | 2 +- gcc/testsuite/gcc.target/microblaze/isa/vanilla.c | 2 +- gcc/testsuite/gcc.target/microblaze/microblaze.exp | 2 +- 20 files changed, 20 insertions(+), 20 deletions(-) Only two test cases actually test this fix. Please add a ChangeLog update for these changes. -- Michael Eager
Re: [PATCH v4 1/1] gcc: config: microblaze: fix cpu version check
On 10/26/23 13:37, Neal Frager wrote:
The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp
instead of strverscmp to check the mcpu version against feature
options. By simply changing the define to use strverscmp,
the new version 10.0 is treated correctly as a higher version
than previous versions.
Signed-off-by: Neal Frager
---
V1->V2:
- No need to create a new microblaze specific version check
routine as strverscmp is the correct solution.
V2->V3:
- Changed mcpu define for microblaze isa testsuite examples.
V3->V4:
- Added ChangeLog
---
gcc/ChangeLog | 4
gcc/config/microblaze/microblaze.cc| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/bshift.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/div.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/fcmp1.c| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/fcmp2.c| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/fcmp3.c| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/fcmp4.c| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/fcvt.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/float.c| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/fsqrt.c| 2 +-
gcc/testsuite/gcc.target/microblaze/isa/mul-bshift-pcmp.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/mul-bshift.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/mul.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/mulh-bshift-pcmp.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/mulh.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/nofcmp.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/nofloat.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/pcmp.c | 2 +-
gcc/testsuite/gcc.target/microblaze/isa/vanilla.c | 2 +-
gcc/testsuite/gcc.target/microblaze/microblaze.exp | 2 +-
21 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d50cd42a7d4..d5fee35bda4 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2023-10-26 Neal Frager
+
+ * config/microblaze/microblaze.cc: Fix mcpu version check.
gcc/testsuite/ChangeLog?
+
2023-10-25 Iain Sandoe
* config/darwin.cc (darwin_override_options): Handle fPIE.
diff --git a/gcc/config/microblaze/microblaze.cc
b/gcc/config/microblaze/microblaze.cc
index c9f6c4198cf..60ad55120d2 100644
--- a/gcc/config/microblaze/microblaze.cc
+++ b/gcc/config/microblaze/microblaze.cc
@@ -56,7 +56,7 @@
/* This file should be included last. */
#include "target-def.h"
-#define MICROBLAZE_VERSION_COMPARE(VA,VB) strcasecmp (VA, VB)
+#define MICROBLAZE_VERSION_COMPARE(VA,VB) strverscmp (VA, VB)
/* Classifies an address.
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/bshift.c b/gcc/testsuite/gcc.target/microblaze/isa/bshift.c
index 64cf1e2e59e..664586bff9f 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/bshift.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/bshift.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mxl-barrel-shift" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mxl-barrel-shift" } */
volatile int m1, m2, m3;
volatile unsigned int u1, u2, u3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/div.c
b/gcc/testsuite/gcc.target/microblaze/isa/div.c
index 25ee42ce5c8..783e7c0f684 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/div.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/div.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mno-xl-soft-div" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mno-xl-soft-div" } */
volatile int m1, m2, m3;
volatile long l1, l2;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/fcmp1.c
b/gcc/testsuite/gcc.target/microblaze/isa/fcmp1.c
index 4041a241391..b6202e168d6 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/fcmp1.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/fcmp1.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mhard-float" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mhard-float" } */
volatile float f1, f2, f3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/fcmp2.c b/gcc/testsuite/gcc.target/microblaze/isa/fcmp2.c
index 3902b839db9..4386c6e6cc3 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/fcmp2.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/fcmp2.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mhard-float" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mhard-float" } */
volatile float f1, f2, f3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/fcmp3.c b/gcc/testsuite/gcc.target/microblaze/isa/fcmp3.c
index 8555974dda5..b414e48fe1b 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/fcmp3.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/fcmp3.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mhard-float" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mhard-float" } */
vo
Re: [PATCH v5 1/1] gcc: config: microblaze: fix cpu version check
t-mul
-mxl-pattern-compare -mxl-multiply-high" } */
volatile int m1, m2, m3;
volatile unsigned int u1, u2, u3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/mulh.c
b/gcc/testsuite/gcc.target/microblaze/isa/mulh.c
index 6e0cc3ac470..da28e8c4d1e 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/mulh.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/mulh.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mno-xl-soft-mul -mxl-multiply-high" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mno-xl-soft-mul -mxl-multiply-high" } */
volatile int m1, m2, m3;
volatile unsigned int u1, u2, u3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/nofcmp.c
b/gcc/testsuite/gcc.target/microblaze/isa/nofcmp.c
index ebfb170ecee..86910fc347a 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/nofcmp.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/nofcmp.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a " } */
+/* { dg-options "-O3 -mcpu=v10.0" } */
volatile float f1, f2, f3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/nofloat.c b/gcc/testsuite/gcc.target/microblaze/isa/nofloat.c
index 647da3cfe24..b1f0268715d 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/nofloat.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/nofloat.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -msoft-float" } */
+/* { dg-options "-O3 -mcpu=v10.0 -msoft-float" } */
volatile float f1, f2, f3;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/pcmp.c b/gcc/testsuite/gcc.target/microblaze/isa/pcmp.c
index aea79572103..d9e5793f6f5 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/pcmp.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/pcmp.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mxl-pattern-compare" } */
+/* { dg-options "-O3 -mcpu=v10.0 -mxl-pattern-compare" } */
volatile int m1, m2, m3;
volatile long l1, l2;
diff --git a/gcc/testsuite/gcc.target/microblaze/isa/vanilla.c
b/gcc/testsuite/gcc.target/microblaze/isa/vanilla.c
index 1d6ba807b12..35824b6d077 100644
--- a/gcc/testsuite/gcc.target/microblaze/isa/vanilla.c
+++ b/gcc/testsuite/gcc.target/microblaze/isa/vanilla.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O3 -mcpu=v6.00.a -mcpu=v6.00.a" } */
+/* { dg-options "-O3 -mcpu=v10.0" } */
volatile int m1, m2, m3;
volatile long l1, l2;
diff --git a/gcc/testsuite/gcc.target/microblaze/microblaze.exp
b/gcc/testsuite/gcc.target/microblaze/microblaze.exp
index 1c7b0e23353..33979ae5e42 100644
--- a/gcc/testsuite/gcc.target/microblaze/microblaze.exp
+++ b/gcc/testsuite/gcc.target/microblaze/microblaze.exp
@@ -49,7 +49,7 @@ dg-runtest [lsort [glob -nocomplain
$srcdir/$subdir/isa/*.\[cSi\]]] \
${default_c_flags} ""
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/others/*.\[cSi\]]] \
-"" "-mcpu=v6.00.a"
+"" "-mcpu=v10.0"
# All done.
--
Michael Eager
Re: [PATCH v6 1/1] gcc: config: microblaze: fix cpu version check
On 10/30/23 10:02, Neal Frager wrote: The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp instead of strverscmp to check the mcpu version against feature options. By simply changing the define to use strverscmp, the new version 10.0 is treated correctly as a higher version than previous versions. Signed-off-by: Neal Frager Added to commit message; Fix incorrect warning with -mcpu=10.0: warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a' or greater --- V1->V2: - No need to create a new microblaze specific version check routine as strverscmp is the correct solution. V2->V3: - Changed mcpu define for microblaze isa testsuite examples. V3->V4: - Added ChangeLog V4->V5: - Added testsuite ChangeLog V5->V6: - Updated testsuite ChangeLog to include all files --- gcc/ChangeLog | 4 gcc/config/microblaze/microblaze.cc | 2 +- gcc/testsuite/ChangeLog | 22 +++ .../gcc.target/microblaze/isa/bshift.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/div.c | 2 +- .../gcc.target/microblaze/isa/fcmp1.c | 2 +- .../gcc.target/microblaze/isa/fcmp2.c | 2 +- .../gcc.target/microblaze/isa/fcmp3.c | 2 +- .../gcc.target/microblaze/isa/fcmp4.c | 2 +- .../gcc.target/microblaze/isa/fcvt.c | 2 +- .../gcc.target/microblaze/isa/float.c | 2 +- .../gcc.target/microblaze/isa/fsqrt.c | 2 +- .../microblaze/isa/mul-bshift-pcmp.c | 2 +- .../gcc.target/microblaze/isa/mul-bshift.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/mul.c | 2 +- .../microblaze/isa/mulh-bshift-pcmp.c | 2 +- .../gcc.target/microblaze/isa/mulh.c | 2 +- .../gcc.target/microblaze/isa/nofcmp.c| 2 +- .../gcc.target/microblaze/isa/nofloat.c | 2 +- .../gcc.target/microblaze/isa/pcmp.c | 2 +- .../gcc.target/microblaze/isa/vanilla.c | 2 +- .../gcc.target/microblaze/microblaze.exp | 2 +- 22 files changed, 46 insertions(+), 20 deletions(-) Committed. -- Michael Eager
Re: [PATCH v6 1/1] gcc: config: microblaze: fix cpu version check
On 10/31/23 09:41, Frager, Neal wrote: Hi Michael, The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp instead of strverscmp to check the mcpu version against feature options. By simply changing the define to use strverscmp, the new version 10.0 is treated correctly as a higher version than previous versions. Signed-off-by: Neal Frager Added to commit message; Fix incorrect warning with -mcpu=10.0: warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a' or greater --- V1->V2: - No need to create a new microblaze specific version check routine as strverscmp is the correct solution. V2->V3: - Changed mcpu define for microblaze isa testsuite examples. V3->V4: - Added ChangeLog V4->V5: - Added testsuite ChangeLog V5->V6: - Updated testsuite ChangeLog to include all files --- gcc/ChangeLog | 4 gcc/config/microblaze/microblaze.cc | 2 +- gcc/testsuite/ChangeLog | 22 +++ .../gcc.target/microblaze/isa/bshift.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/div.c | 2 +- .../gcc.target/microblaze/isa/fcmp1.c | 2 +- .../gcc.target/microblaze/isa/fcmp2.c | 2 +- .../gcc.target/microblaze/isa/fcmp3.c | 2 +- .../gcc.target/microblaze/isa/fcmp4.c | 2 +- .../gcc.target/microblaze/isa/fcvt.c | 2 +- .../gcc.target/microblaze/isa/float.c | 2 +- .../gcc.target/microblaze/isa/fsqrt.c | 2 +- .../microblaze/isa/mul-bshift-pcmp.c | 2 +- .../gcc.target/microblaze/isa/mul-bshift.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/mul.c | 2 +- .../microblaze/isa/mulh-bshift-pcmp.c | 2 +- .../gcc.target/microblaze/isa/mulh.c | 2 +- .../gcc.target/microblaze/isa/nofcmp.c| 2 +- .../gcc.target/microblaze/isa/nofloat.c | 2 +- .../gcc.target/microblaze/isa/pcmp.c | 2 +- .../gcc.target/microblaze/isa/vanilla.c | 2 +- .../gcc.target/microblaze/microblaze.exp | 2 +- 22 files changed, 46 insertions(+), 20 deletions(-) Committed. Did you commit this patch? I only see the ChangeLog files have been updated by your commit. Am I missing something? Somehow only the ChangeLogs, which required manual editing, were marked to be added. I'll add the other files. -- Michael Eager
Re: [PATCH v6 1/1] gcc: config: microblaze: fix cpu version check
On 10/31/23 09:41, Frager, Neal wrote: Hi Michael, The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp instead of strverscmp to check the mcpu version against feature options. By simply changing the define to use strverscmp, the new version 10.0 is treated correctly as a higher version than previous versions. Signed-off-by: Neal Frager Added to commit message; Fix incorrect warning with -mcpu=10.0: warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a' or greater --- V1->V2: - No need to create a new microblaze specific version check routine as strverscmp is the correct solution. V2->V3: - Changed mcpu define for microblaze isa testsuite examples. V3->V4: - Added ChangeLog V4->V5: - Added testsuite ChangeLog V5->V6: - Updated testsuite ChangeLog to include all files --- gcc/ChangeLog | 4 gcc/config/microblaze/microblaze.cc | 2 +- gcc/testsuite/ChangeLog | 22 +++ .../gcc.target/microblaze/isa/bshift.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/div.c | 2 +- .../gcc.target/microblaze/isa/fcmp1.c | 2 +- .../gcc.target/microblaze/isa/fcmp2.c | 2 +- .../gcc.target/microblaze/isa/fcmp3.c | 2 +- .../gcc.target/microblaze/isa/fcmp4.c | 2 +- .../gcc.target/microblaze/isa/fcvt.c | 2 +- .../gcc.target/microblaze/isa/float.c | 2 +- .../gcc.target/microblaze/isa/fsqrt.c | 2 +- .../microblaze/isa/mul-bshift-pcmp.c | 2 +- .../gcc.target/microblaze/isa/mul-bshift.c| 2 +- gcc/testsuite/gcc.target/microblaze/isa/mul.c | 2 +- .../microblaze/isa/mulh-bshift-pcmp.c | 2 +- .../gcc.target/microblaze/isa/mulh.c | 2 +- .../gcc.target/microblaze/isa/nofcmp.c| 2 +- .../gcc.target/microblaze/isa/nofloat.c | 2 +- .../gcc.target/microblaze/isa/pcmp.c | 2 +- .../gcc.target/microblaze/isa/vanilla.c | 2 +- .../gcc.target/microblaze/microblaze.exp | 2 +- 22 files changed, 46 insertions(+), 20 deletions(-) Committed. Did you commit this patch? I only see the ChangeLog files have been updated by your commit. Am I missing something? Updated. -- Michael Eager
[PATCH] Fix uninitialized variable warnings
The attached patch corrects a couple uninitialized variable warnings.
The variables are initialized to NULL and tests for this, calling
gcc_unreachable(). Replace other calls to abort() for with
gcc_unreachable().
Thanks to Jan-Benedict Glaw for bringing this to my attention.
** I'm receiving a "service not enabled" error when I push.
** Can someone apply this patch while I resolve this issue?
--
Michael EagerFrom a0fd2e9baa51e85f61cebd6e78bef8b5c55199b5 Mon Sep 17 00:00:00 2001
From: Michael Eager
Date: Thu, 20 Oct 2022 09:33:13 -0700
Subject: [PATCH] Fix uninitialized variable warnings
gcc/ChangeLog:
* gcc/config/microblaze/microblaze.cc
(microblaze_legitimize_address): Initialize 'reg' to NULL, check for NULL.
(microblaze_address_insns): Replace abort() with gcc_unreachable().
(print_operand_address): Same.
(microblaze_expand_move): Initialize 'p1' to NULL, check for NULL.
(get_branch_target): Replace abort() with gcc_unreachable().
---
gcc/ChangeLog | 9 +
gcc/config/microblaze/microblaze.cc | 19 ++-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7a50293c780..8271fafe033 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2022-10-20 Michael Eager
+
+ * gcc/config/microblaze/microblaze.cc
+ (microblaze_legitimize_address): Initialize 'reg' to NULL, check for NULL.
+ (microblaze_address_insns): Replace abort() with gcc_unreachable().
+ (print_operand_address): Same.
+ (microblaze_expand_move): Initialize 'p1' to NULL, check for NULL.
+ (get_branch_target): Replace abort() with gcc_unreachable().
+
2022-10-19 Aldy Hernandez
* range-op-float.cc (build_le): Document result.
diff --git a/gcc/config/microblaze/microblaze.cc b/gcc/config/microblaze/microblaze.cc
index 8fcca1829f6..9290a1f3958 100644
--- a/gcc/config/microblaze/microblaze.cc
+++ b/gcc/config/microblaze/microblaze.cc
@@ -1103,7 +1103,7 @@ microblaze_legitimize_address (rtx x, rtx oldx ATTRIBUTE_UNUSED,
if (GET_CODE (xinsn) == SYMBOL_REF)
{
- rtx reg;
+ rtx reg = NULL;
if (microblaze_tls_symbol_p(xinsn))
{
reg = microblaze_legitimize_tls_address (xinsn, NULL_RTX);
@@ -1133,6 +1133,11 @@ microblaze_legitimize_address (rtx x, rtx oldx ATTRIBUTE_UNUSED,
reg = pic_ref;
}
}
+ else
+ {
+ /* This should never happen. */
+ gcc_unreachable ();
+ }
return reg;
}
@@ -1474,7 +1479,7 @@ microblaze_address_insns (rtx x, machine_mode mode)
case TLS_DTPREL:
return 1;
default :
- abort();
+ gcc_unreachable ();
}
default:
break;
@@ -2624,7 +2629,7 @@ print_operand_address (FILE * file, rtx addr)
fputs ("@TLSDTPREL", file);
break;
default :
- abort();
+ gcc_unreachable ();
break;
}
}
@@ -3413,7 +3418,7 @@ microblaze_expand_move (machine_mode mode, rtx operands[])
}
if (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1,1)) == CONST)
{
- rtx p0, p1, result, temp;
+ rtx p0, p1 = NULL, result, temp;
p0 = XEXP (XEXP (op1,1), 0);
@@ -3423,6 +3428,10 @@ microblaze_expand_move (machine_mode mode, rtx operands[])
p0 = XEXP (p0, 0);
}
+ /* This should never happen. */
+ if (p1 == NULL)
+ gcc_unreachable ();
+
if (GET_CODE (p0) == UNSPEC && GET_CODE (p1) == CONST_INT
&& flag_pic && TARGET_PIC_DATA_TEXT_REL)
{
@@ -3799,7 +3808,7 @@ get_branch_target (rtx branch)
if (GET_CODE (call) == SET)
call = SET_SRC (call);
if (GET_CODE (call) != CALL)
-abort ();
+ gcc_unreachable ();
return XEXP (XEXP (call, 0), 0);
}
--
2.31.1
[PATCH] Microblaze: Fix uninitialized variable warnings
The attached patch corrects a couple uninitialized variable warnings.
The variables are initialized to NULL and tested for this, calling
gcc_unreachable(). Replace other calls to abort() for with
gcc_unreachable().
Thanks to Jan-Benedict Glaw for bringing this to my attention.
** I'm receiving a "service not enabled" error when I push.
** Can someone apply this patch while I resolve this issue?
--
Michael EagerFrom a0fd2e9baa51e85f61cebd6e78bef8b5c55199b5 Mon Sep 17 00:00:00 2001
From: Michael Eager
Date: Thu, 20 Oct 2022 09:33:13 -0700
Subject: [PATCH] Fix uninitialized variable warnings
gcc/ChangeLog:
* gcc/config/microblaze/microblaze.cc
(microblaze_legitimize_address): Initialize 'reg' to NULL, check for NULL.
(microblaze_address_insns): Replace abort() with gcc_unreachable().
(print_operand_address): Same.
(microblaze_expand_move): Initialize 'p1' to NULL, check for NULL.
(get_branch_target): Replace abort() with gcc_unreachable().
---
gcc/ChangeLog | 9 +
gcc/config/microblaze/microblaze.cc | 19 ++-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7a50293c780..8271fafe033 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2022-10-20 Michael Eager
+
+ * gcc/config/microblaze/microblaze.cc
+ (microblaze_legitimize_address): Initialize 'reg' to NULL, check for NULL.
+ (microblaze_address_insns): Replace abort() with gcc_unreachable().
+ (print_operand_address): Same.
+ (microblaze_expand_move): Initialize 'p1' to NULL, check for NULL.
+ (get_branch_target): Replace abort() with gcc_unreachable().
+
2022-10-19 Aldy Hernandez
* range-op-float.cc (build_le): Document result.
diff --git a/gcc/config/microblaze/microblaze.cc b/gcc/config/microblaze/microblaze.cc
index 8fcca1829f6..9290a1f3958 100644
--- a/gcc/config/microblaze/microblaze.cc
+++ b/gcc/config/microblaze/microblaze.cc
@@ -1103,7 +1103,7 @@ microblaze_legitimize_address (rtx x, rtx oldx ATTRIBUTE_UNUSED,
if (GET_CODE (xinsn) == SYMBOL_REF)
{
- rtx reg;
+ rtx reg = NULL;
if (microblaze_tls_symbol_p(xinsn))
{
reg = microblaze_legitimize_tls_address (xinsn, NULL_RTX);
@@ -1133,6 +1133,11 @@ microblaze_legitimize_address (rtx x, rtx oldx ATTRIBUTE_UNUSED,
reg = pic_ref;
}
}
+ else
+ {
+ /* This should never happen. */
+ gcc_unreachable ();
+ }
return reg;
}
@@ -1474,7 +1479,7 @@ microblaze_address_insns (rtx x, machine_mode mode)
case TLS_DTPREL:
return 1;
default :
- abort();
+ gcc_unreachable ();
}
default:
break;
@@ -2624,7 +2629,7 @@ print_operand_address (FILE * file, rtx addr)
fputs ("@TLSDTPREL", file);
break;
default :
- abort();
+ gcc_unreachable ();
break;
}
}
@@ -3413,7 +3418,7 @@ microblaze_expand_move (machine_mode mode, rtx operands[])
}
if (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1,1)) == CONST)
{
- rtx p0, p1, result, temp;
+ rtx p0, p1 = NULL, result, temp;
p0 = XEXP (XEXP (op1,1), 0);
@@ -3423,6 +3428,10 @@ microblaze_expand_move (machine_mode mode, rtx operands[])
p0 = XEXP (p0, 0);
}
+ /* This should never happen. */
+ if (p1 == NULL)
+ gcc_unreachable ();
+
if (GET_CODE (p0) == UNSPEC && GET_CODE (p1) == CONST_INT
&& flag_pic && TARGET_PIC_DATA_TEXT_REL)
{
@@ -3799,7 +3808,7 @@ get_branch_target (rtx branch)
if (GET_CODE (call) == SET)
call = SET_SRC (call);
if (GET_CODE (call) != CALL)
-abort ();
+ gcc_unreachable ();
return XEXP (XEXP (call, 0), 0);
}
--
2.31.1
Re: [Patch, microblaze]: Correct the const high double immediate value
On 11/8/20 9:43 PM, Nagaraju Mekala wrote:
diff --git a/gcc/config/microblaze/microblaze.c
b/gcc/config/microblaze/microblaze.c
index a0f81b7..d9341ec 100644
--- a/gcc/config/microblaze/microblaze.c
+++ b/gcc/config/microblaze/microblaze.c
@@ -2440,15 +2440,18 @@ print_operand (FILE * file, rtx op, int letter)
else if (letter == 'h' || letter == 'j')
{
- long val[2];
+ long val[2], l[2];
if (code == CONST_DOUBLE)
{
if (GET_MODE (op) == DFmode)
REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (op),
val);
else
{
- val[0] = CONST_DOUBLE_HIGH (op);
- val[1] = CONST_DOUBLE_LOW (op);
+ REAL_VALUE_TYPE rv;
+ REAL_VALUE_FROM_CONST_DOUBLE (rv, op);
REAL_VALUE_FROM_CONST_DOUBLE was removed from real.h in 2015.
Use CONST_DOUBLE_REAL_VALUE.
+ REAL_VALUE_TO_TARGET_DOUBLE (rv, l);
+ val[1] = l[WORDS_BIG_ENDIAN == 0];
+ val[0] = l[WORDS_BIG_ENDIAN != 0];
}
}
else if (code == CONST_INT)
diff --git a/gcc/testsuite/gcc.target/microblaze/long.c
b/gcc/testsuite/gcc.target/microblaze/long.c
new file mode 100644
index 000..4d45186
--- /dev/null
+++ b/gcc/testsuite/gcc.target/microblaze/long.c
@@ -0,0 +1,10 @@
+/* { dg-options "-O0" } */
+#define BASEADDR 0xF000ULL
+int main ()
+{
+ unsigned long long start;
+ start = (unsigned long long) BASEADDR;
+ return 0;
+}
+/* { dg-final { scan-assembler
"addik\tr(\[0-9]\|\[1-2]\[0-9]\|3\[0-1]),r0,0x" } } */
+/* { dg-final { scan-assembler
"addik\tr(\[0-9]\|\[1-2]\[0-9]\|3\[0-1]),r0,0xf000" } } */
It looks like this test case will pass without the patch. The code
generated before applying the patch is
addik r4,r0,0x
addik r5,r0,0xf000 #li => la
Can you provide a test case which fails without the patch but passes
with the patch?
--
Michael Eager
Re: PING^1 [PATCH 22/52] microblaze: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE
OK with me.
On 6/13/24 00:16, Kewen.Lin wrote:
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653355.html
BR,
Kewen
on 2024/6/3 11:01, Kewen Lin wrote:
This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
defines in microblaze port.
gcc/ChangeLog:
* config/microblaze/microblaze.h (FLOAT_TYPE_SIZE): Remove.
(DOUBLE_TYPE_SIZE): Likewise.
(LONG_DOUBLE_TYPE_SIZE): Likewise.
---
gcc/config/microblaze/microblaze.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/microblaze/microblaze.h
b/gcc/config/microblaze/microblaze.h
index c88a87c12e2..5d28abf9741 100644
--- a/gcc/config/microblaze/microblaze.h
+++ b/gcc/config/microblaze/microblaze.h
@@ -216,9 +216,6 @@ extern enum pipeline_type microblaze_pipe;
#define SHORT_TYPE_SIZE 16
#define LONG_TYPE_SIZE 32
#define LONG_LONG_TYPE_SIZE 64
-#define FLOAT_TYPE_SIZE 32
-#define DOUBLE_TYPE_SIZE64
-#define LONG_DOUBLE_TYPE_SIZE 64
#define POINTER_SIZE32
#define PARM_BOUNDARY 32
#define FUNCTION_BOUNDARY 32
--
Michael Eager
Re: [patch,gcc] Add microblaze*-rtems*
On 10/25/2012 06:49 AM, Ralf Corsepius wrote: Hi, And another RTEMS-patch, I'd like to apply to GCC trunk and GCC-4_7-branch: Adding microblaze*-rtems* target. This patch has been in use as part of the RTEMS gcc-4.7 patches for ca. 1/2 a year. OK to apply. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized register reorganization for Microblaze.
On 01/12/2016 09:42 AM, Ajit Kumar Agarwal wrote:
The patch contains the changes in the macros fixed_registers and
call_used_registers.
Earlier the register r21 is marked as fixed and also marked as 1 for call_used
registers.
On top of that r21 is not assigned to any of the temporaries in rtl insns.
This makes the usage of registers r21 in the callee functions not possible and
wasting
one registers to allocate in the callee function. The changes makes the
register r21 as
allocatable to the callee function and optimized usage of the registers r21 in
the callee
function reduces spill and fetch. The reduction in the spill and fetch is due
to availability
of register r21 in the callee function. The availability of register r21 is
made by
marking the register r21 as not fixed and the call_used registers is marked as
0.
Also r20 is marked as fixed. The changes are done not to mark as fixed thus
allowing
the registers to be used reducing the spill and fetch.
Regtested for Microblaze.
Performance runs made on Mibench/EEMBC benchmarks for microblaze. Following
benchmarks
shows the gains
Benchmarks Gains
automotive_qsort1 =3.96%
automotive_susan_c = 7.68%
consumer_mad =9.6%
security_rijndael_d =19.57%
telecom_CRC32 = 7.66%
bitmnp01_lite = 10.61%
a2time01_lite =6.97%
ChangeLog:
2016-01-12 Ajit Agarwal
* config/microblaze/microblaze.h
(FIXED_REGISTERS): Update in macro.
(CALL_USED_REGISTERS): Update in macro.
Signed-off-by:Ajit Agarwal ajit...@xilinx.com.
---
gcc/config/microblaze/microblaze.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/microblaze/microblaze.h
b/gcc/config/microblaze/microblaze.h
index e115c42..dbfb652 100644
--- a/gcc/config/microblaze/microblaze.h
+++ b/gcc/config/microblaze/microblaze.h
@@ -253,14 +253,14 @@ extern enum pipeline_type microblaze_pipe;
#define FIXED_REGISTERS
\
{ \
1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, \
- 1, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
+ 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
1, 1, 1, 1 \
}
#define CALL_USED_REGISTERS \
{ \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
- 1, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
+ 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
1, 1, 1, 1 \
}
#define GP_REG_FIRST0
Committed revision 232682.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Instruction prefetch optimization for microblaze.
On 12/07/2015 09:39 AM, Ajit Kumar Agarwal wrote: -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Thursday, December 03, 2015 7:27 PM To: Ajit Kumar Agarwal; GCC Patches Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,microblaze]: Instruction prefetch optimization for microblaze. On 12/01/2015 12:49 AM, Ajit Kumar Agarwal wrote: The changes are made in this patch for the instruction prefetch optimizations for Microblaze. Reg tested for Microblaze target. The changes are made for instruction prefetch optimizations for Microblaze. The "wic" microblaze instruction is the instruction prefetch instruction. The instruction prefetch optimization is done to generate the iprefetch instruction at the call site fall through path. This optimization is enabled with microblaze target flag mxl-prefetch. The purpose of adding the flags is that selection of "wic" instruction should be enabled in the reconfigurable design and the selection is not enabled by default. ChangeLog: 2015-12-01 Ajit Agarwal * config/microblaze/microblaze.c (get_branch_target): New. (insert_wic_for_ilb_runout): New. (insert_wic): New. (microblaze_machine_dependent_reorg): New. (TARGET_MACHINE_DEPENDENT_REORG): Define macro. * config/microblaze/microblaze.md (UNSPEC_IPREFETCH): Define. (iprefetch): New pattern * config/microblaze/microblaze.opt (mxl-prefetch): New flag. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit + rtx_insn *insn, *before_4 = 0, *before_16 = 0; int addr = 0, length, + first_addr = -1; int wic_addr0 = 128 * 4, wic_addr1 = 128 * 4; Especially when there are initializers, I prefer to see each variable declared on a separate line. If the meaning of a variable is not clear (and most of these are not), include a comment >>before the declaration. +if (first_addr == -1) + first_addr = INSN_ADDRESSES (INSN_UID (insn)); Can be moved to initialize first_addr. +addr = INSN_ADDRESSES (INSN_UID (insn)) - first_addr; Is "addr" and address or offset? If the latter, use a more descriptive name. +if (before_4 == 0 && addr + length >= 4 * 4) + before_4 = insn; ... Please add comments to describe what you are doing here. What are before_4 and before_16? What are all these conditions testing? + loop_optimizer_finalize(); Space before parens. All the above comments are incorporated. Updated patch is attached. Regtested for Microblaze target. Mibench/EEMBC benchmarks are run on the hardware enabling the mxl-prefetch and the run goes through fine With the generation of "wic" instruction. [Patch,microblaze]: Instruction prefetch optimization for microblaze. The changes are made for instruction prefetch optimizations for Microblaze. The "wic" microblaze instruction is the instruction prefetch instruction. The instruction prefetch optimization is done to generate the iprefetch instruction at the call site fall through path. This optimization is enabled with microblaze target flag mxl-prefetch. The purpose of adding the flags is that selection of "wic" instruction should be enabled in the reconfigurable design and the selection is not enabled by default. ChangeLog: 2015-12-07 Ajit Agarwal * config/microblaze/microblaze.c (get_branch_target): New. (insert_wic_for_ilb_runout): New. (insert_wic): New. (microblaze_machine_dependent_reorg): New. (TARGET_MACHINE_DEPENDENT_REORG): Define macro. * config/microblaze/microblaze.md (UNSPEC_IPREFETCH): Define. (iprefetch): New pattern * config/microblaze/microblaze.opt (mxl-prefetch): New flag. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit Committed revision 232683. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Better register allocation to minimize the spill and fetch.
On 01/29/2016 02:31 AM, Ajit Kumar Agarwal wrote: This patch improves the allocation of registers in the given function. The allocation is optimized for the conditional branches. The temporary register used in the conditional branches to store the comparison results and use of temporary in the conditional branch is optimized. Such temporary registers are allocated with a fixed register r18. Currently such temporaries are allocated with a free registers in the given function. Due to this one of the free register is reserved for the temporaries and given function is left with a few registers. This is unoptimized with respect to microblaze. In Microblaze r18 is marked as fixed and cannot be allocated to pseudos' in the given function. Instead r18 can be used as a temporary for the conditional branches with compare and branch. Use of r18 as a temporary for conditional branches will save one of the free registers to be allocated. The free registers can be used for other pseudos' and hence the better register allocation. The usage of r18 as above reduces the spill and fetch because of the availability of one of the free registers to other pseudos instead of being used for conditional temporaries. The advantage of the above is that the scope of the temporaries is limited to the conditional branches and hence the usage of r18 as temporary for such conditional branches is optimized and preserve the functionality of the function. Regtested for Microblaze target. Performance runs are done with Mibench/EEMBC benchmarks. Following gains are achieved. Benchmarks Gains automotive_qsort1 1.630730524% network_dijkstra 1.527506256% office_stringsearch 1 1.81356288% security_rijndael_d 3.26129357% basefp01_lite 4.465120185% a2time01_lite 1.893862857% cjpeg_lite 3.286496675% djpeg_lite 3.120150612% qos_lite 2.63964381% office_ispell 1.531340405% Code Size improvements: Reduction in number of instructions for Mibench : 12927. Reduction in number of instructions for EEMBC : 212. ChangeLog: 2016-01-29 Ajit Agarwal * config/microblaze/microblaze.c (microblaze_expand_conditional_branch): Use of MB_ABI_ASM_TEMP_REGNUM for temporary conditional branch. (microblaze_expand_conditional_branch_reg): Use of MB_ABI_ASM_TEMP_REGNUM for temporary conditional branch. (microblaze_expand_conditional_branch_sf): Use of MB_ABI_ASM_TEMP_REGNUM for temporary conditional branch. You can combine these ChangeLog entries: * config/microblaze/microblaze.c (microblaze_expand_conditional_branch, microblaze_expand_conditional_branch_reg, microblaze_expand_conditional_branch_sf): Use MB_ABI_ASM_TEMP_REGNUM for temp reg. Otherwise, OK. Signed-off-by:Ajit Agarwal ajit...@xilinx.com. --- gcc/config/microblaze/microblaze.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/config/microblaze/microblaze.c b/gcc/config/microblaze/microblaze.c index baff67a..b4277ad 100644 --- a/gcc/config/microblaze/microblaze.c +++ b/gcc/config/microblaze/microblaze.c @@ -3402,7 +3402,7 @@ microblaze_expand_conditional_branch (machine_mode mode, rtx operands[]) rtx cmp_op0 = operands[1]; rtx cmp_op1 = operands[2]; rtx label1 = operands[3]; - rtx comp_reg = gen_reg_rtx (SImode); + rtx comp_reg = gen_rtx_REG (SImode, MB_ABI_ASM_TEMP_REGNUM); rtx condition; gcc_assert ((GET_CODE (cmp_op0) == REG) || (GET_CODE (cmp_op0) == SUBREG)); @@ -3439,7 +3439,7 @@ microblaze_expand_conditional_branch_reg (enum machine_mode mode, rtx cmp_op0 = operands[1]; rtx cmp_op1 = operands[2]; rtx label1 = operands[3]; - rtx comp_reg = gen_reg_rtx (SImode); + rtx comp_reg = gen_rtx_REG (SImode, MB_ABI_ASM_TEMP_REGNUM); rtx condition; gcc_assert ((GET_CODE (cmp_op0) == REG) @@ -3483,7 +3483,7 @@ microblaze_expand_conditional_branch_sf (rtx operands[]) rtx condition; rtx cmp_op0 = XEXP (operands[0], 0); rtx cmp_op1 = XEXP (operands[0], 1); - rtx comp_reg = gen_reg_rtx (SImode); + rtx comp_reg = gen_rtx_REG (SImode, MB_ABI_ASM_TEMP_REGNUM); emit_insn (gen_cstoresf4 (comp_reg, operands[0], cmp_op0, cmp_op1)); condition = gen_rtx_NE (SImode, comp_reg, const0_rtx); -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [ping] [patch] contrib/config-list.mk: Allow to build all targets individually
On 11/26/13 17:43, Jan-Benedict Glaw wrote: On Sun, 2013-11-24 20:02:43 +0100, Jan-Benedict Glaw wrote: 2013-11-24 Jan-Benedict Glaw * config-list.mk (host_options): Allow to override it. (LIST): Change "=" to "EQUAL". (list): New target listing all configurations. ($(LIST)): Substitute "EQUAL" back to "=". Ping: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03121.html Additional to that, I'd suggest to also add microblazeel-elf and microblaze-rtems (cf. http://gcc.gnu.org/ml/gcc/2013-11/msg00547.html and http://gcc.gnu.org/ml/gcc/2013-11/msg00545.html), though Joern isn't fond of the idea (cf. http://gcc.gnu.org/ml/gcc/2013-11/msg00528.html). So I'd quite like to see a discussion about this. I have no objections to adding the two targets. I think that microblaze-rtems will duplicate microblaze-elf. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [patch,libgcc] Add microblaze-*-rtems*
On 12/06/13 09:00, Ralf Corsepius wrote: Hi, I am going to apply the patch below to trunk and 4.8-branch. It adds a copy of the microblaze-*-elf section for microblaze-rtems* to libgcc/config.host. This is the missing patch I mentioned in http://gcc.gnu.org/ml/gcc/2013-11/msg00548.html Ralf OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [patch] microblaze-rtems Add TARGET_BIG_ENDIAN_DEFAULT
On 12/06/13 19:13, Ralf Corsepius wrote: Hi, I intend to the patch below to gcc-trunk and 4.8-branch: It's a partial sync of the microblaze-rtems* section in gcc/config.gcc with microblaze*-*-elf's: Add TARGET_BIG_ENDIAN_DEFAULT-switch for microblaze*-*-rtems*. Ralf OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
On 12/11/13 17:35, Kenneth Zadeck wrote: This patch is for the trunk, but it solves a problem that comes up for wide-int. For wide-int we need to have the BITS_PER_UNIT available earlier.So this patch sets the default value (8) in genmodes.c so that it is available by anyone who includes insn-modes.h. The generator for tm.h was modified to include insn-modes.h.The value for BITS_PER_UNIT can be overridden by any port by placing a define for it in their target modes file. This patch removes the definition of BITS_PER_UNIT from 7 platform .h files. All of those platforms initialized it to the default value so there was no need for additions to their target modes file. In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is calculated.The value is heavily used on the wide-int branch to allocate buffers that are used to hold large integer values. The change in the way it is computed was motivated by the i386 port, but there may be other ports that have the same problem. The i386 port defines two very large integer modes that are only used as containers for large vectors. They are never used for large integers. The new way of computing this allows a port to say (very early) that some of these integer modes are never used to hold numbers and so smaller buffers can be used for integer calculations. Other ports that play the same game should follow suit. This patch has been bootstrapped and regression tested on x86-64. Ok to commit? OK for MicroBlaze. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] Fix building microblaze targets with trunk
On 09/29/2015 10:01 AM, Jeff Law wrote: The microblaze port as a "*p++" statement which computes a result that is never used (the memory result). This removes the spurious memory dereference and the unused value warning. Tested by building the microblaze targets in config-all.mk. Installed on the trunk. OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PING][PATCH 5/13] microblaze musl support
On 10/15/2015 12:00 PM, Szabolcs Nagy wrote: On 06/05/15 12:25, Szabolcs Nagy wrote: On 29/04/15 14:51, Szabolcs Nagy wrote: On 29/04/15 14:17, Michael Eager wrote: On 04/27/2015 07:35 AM, Szabolcs Nagy wrote: On 20/04/15 19:54, Szabolcs Nagy wrote: Set up dynamic linker name for microblaze. Patch v2. (undef MUSL_DYNAMIC_LINKER that comes from config/linux.h) Are you building with both glibc and musl to verify these patches? ... note that microblaze does not use the GNU_USER_DYNAMIC_LINKER macro so the -mglibc etc options don't work. (that should be changed probably, assuming -muclibc and -mbionic have no side effects when they are not supported) Patch v3. I changed the patch to use GNU_USER_DYNAMIC_LINKER like other platforms do. I built gcc with musl and glibc default libc as well and verified that -mmusl and -mglibc sets the dynamic linker as expected. Ping, patch still works. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00437.html gcc/Changelog: 2015-05-06 Gregor Richards Szabolcs Nagy * config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define. (DYNAMIC_LINKER): Renamed to ... (GLIBC_DYNAMIC_LINKER): This. (SUBTARGET_EXTRA_SPECS): Use GNU_USER_DYNAMIC_LINKER. OK. Do you have commit privileges? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Instruction prefetch optimization for microblaze.
On 12/01/2015 12:49 AM, Ajit Kumar Agarwal wrote: The changes are made in this patch for the instruction prefetch optimizations for Microblaze. Reg tested for Microblaze target. The changes are made for instruction prefetch optimizations for Microblaze. The "wic" microblaze instruction is the instruction prefetch instruction. The instruction prefetch optimization is done to generate the iprefetch instruction at the call site fall through path. This optimization is enabled with microblaze target flag mxl-prefetch. The purpose of adding the flags is that selection of "wic" instruction should be enabled in the reconfigurable design and the selection is not enabled by default. ChangeLog: 2015-12-01 Ajit Agarwal * config/microblaze/microblaze.c (get_branch_target): New. (insert_wic_for_ilb_runout): New. (insert_wic): New. (microblaze_machine_dependent_reorg): New. (TARGET_MACHINE_DEPENDENT_REORG): Define macro. * config/microblaze/microblaze.md (UNSPEC_IPREFETCH): Define. (iprefetch): New pattern * config/microblaze/microblaze.opt (mxl-prefetch): New flag. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit + rtx_insn *insn, *before_4 = 0, *before_16 = 0; + int addr = 0, length, first_addr = -1; + int wic_addr0 = 128 * 4, wic_addr1 = 128 * 4; Especially when there are initializers, I prefer to see each variable declared on a separate line. If the meaning of a variable is not clear (and most of these are not), include a comment before the declaration. +if (first_addr == -1) + first_addr = INSN_ADDRESSES (INSN_UID (insn)); Can be moved to initialize first_addr. +addr = INSN_ADDRESSES (INSN_UID (insn)) - first_addr; Is "addr" and address or offset? If the latter, use a more descriptive name. +if (before_4 == 0 && addr + length >= 4 * 4) + before_4 = insn; ... Please add comments to describe what you are doing here. What are before_4 and before_16? What are all these conditions testing? + loop_optimizer_finalize(); Space before parens. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH]Microblaze: Fixed missing save of r18 in fast_interrupt.
OK to apply.
On 4/4/20 2:18 AM, Nagaraju Mekala wrote:
Hello All,
Fixed missing save of r18 in fast_interrupt.
Register 18 is used as a clobber register, and must be stored when entering a
fast_interrupt. Before this fix, register 18 was only saved if it was used
directly in the interrupt function.
However, if the fast_interrupt function called a function that used r18, the register would not be saved, and thus be mangled upon returning from the interrupt.
Changelog
2020-04-04 Klaus Petersen
* gcc/config/microblaze/microblaze.c: Check for fast_interrupt in
microblaze_must_save_register.
Signed-off-by: Klaus Petersen
Signed-off-by :Nagaraju Mekala
diff --git a/gcc/config/microblaze/microblaze.c
b/gcc/config/microblaze/microblaze.c
index b4754b1..67e393d 100644
--- a/gcc/config/microblaze/microblaze.c
+++ b/gcc/config/microblaze/microblaze.c
@@ -2035,7 +2035,7 @@ microblaze_must_save_register (int regno)
{
if (df_regs_ever_live_p (regno)
|| regno == MB_ABI_MSR_SAVE_REG
- || (interrupt_handler
+ || ((interrupt_handler || fast_interrupt)
&& (regno == MB_ABI_ASM_TEMP_REGNUM
|| regno == MB_ABI_EXCEPTION_RETURN_ADDR_REGNUM)))
return 1;
Attached is the patch.
Thanks
Nagaraju
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH]Microblaze: Modified trap instruction
OK to apply.
On 4/4/20 1:59 AM, Nagaraju Mekala wrote:
Hello All,
There is a bug in trap instruction generation.
Instead of "bri 0" instruction "brki r0, -1" was used, corrected it now.
ChangeLog:
2020-04-04 Nagaraju Mekala
* gcc/config/microblaze/microblaze.md
(trap): update in the pattern
* gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c
(dg-final): update in the scan-assembler instruction
Signed-off-by :Nagaraju Mekala
diff --git a/gcc/config/microblaze/microblaze.md
b/gcc/config/microblaze/microblaze.md
index 1970cc6..7049acd 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2303,7 +2303,7 @@
(define_insn "trap"
[(trap_if (const_int 1) (const_int 0))]
""
- "brki\tr0,-1"
+ "bri\t0"
[(set_attr "type" "trap")]
)
diff --git a/gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c b/gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c
index fdcde1f..580b4db 100644
--- a/gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c
+++ b/gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c
@@ -5,4 +5,4 @@ void trap ()
__builtin_trap ();
}
-/* { dg-final { scan-assembler "brki\tr0,-1" } } */
\ No newline at end of file
+/* { dg-final { scan-assembler "bri\t0" } } */
Attached is the patch.
Thanks
Nagaraju
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] microblaze: fix PR65649
On 11/15/19 2:07 AM, Szabolcs Nagy wrote: microblaze-linux-musl build fails without this. (This is a rebase of an earlier patch posted on bugzilla.) gcc/ChangeLog: 2019-11-15 Nick Clifton Szabolcs Nagy * config/microblaze/microblaze.c (print_operand): Print value as long. OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] MicroBlaze use default ident output generation
On 11/15/2017 10:58 PM, Nathan Rossi wrote: Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and use the default. This resolves issues associated with the use of the .sdata2 operation in cases where emitted assembly after the ident output is incorrectly in the .sdata2 section instead of .text or any other expected section. Which results in assembly failures including operations with symbols across different segments. Can you give me an example where this causes a problem? -- Michael Eagerea...@eagerm.com 1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
On 02/25/2018 11:44 PM, Andrew Guirguis wrote: Dears, Kindly find attached the patch bundle for Microblaze '-mpic-data-text-relative' feature. Description of the feature in the following link: https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md <https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md> Bundle includes: 1) Change logs for GCC, binutils 2) GCC Test results and comparison with the original. 3) New Test case (picdtr.c) 4) The Patches (against current heads) Hi Andrew -- Thanks for the submission. I have the following recommendations: Submit each patch to the appropriate project mailing list. Only submit the patch for the specific project, without patches for other projects. Include a description of the changes with each patch as well as the changelog. Include the patch in your email or as an attachment. It isn't clear why you sent your submission to the gdb-patches mailing list, since there don't appear to be any GDB changes. Conversely, it is not clear why you did not include the binutils mailing list, since you include a patch to that project. Be sure to follow GNU coding conventions, Check brace placement, indent, maximum line length, if statements, etc. I noticed a number of places where these conventions are not followed in your patches. GCC regression tests should include all tests (e.g., gcc.dg), not just the limited number of MicroBlaze-specific tests. -- Michael Eagerea...@eagerm.com 1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
On 03/02/2018 08:12 AM, Andrew Sadek wrote:
Hello Michael,
I tried running the whole GCC test suite on the current head (without my
patch) along with 'microblaze-qemu' but I have the following problems:
1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the gcc is
making a 100% CPU usage and the machine stucks.
I tried compiling the file alone, it generated a couple of warnings than
it hangs.
warning: '__builtin_memchr' specified size 4294967295 exceeds maximum
object size 2147483647 [-Wstringop-overflow=]
vp1 = __builtin_memchr (a, b, SIZE1);
Is it a bug? Is there something wrong with my configuration ?
GCC configured with options : --with-newlib --enable-threads=no
--disable-shared --with-pkgversion='crosstool-NG
crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support --enable-lto
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm' --enable-target-optspace --disable-nls --enable-multiarch
--enable-languages=c,c++
Your configuration is more complex than my hard-metal target version,
but it looks reasonable.
The problem with string-large-1.c does appear to be a bug. You can
add a line to the test case which will mark it as known failure for MB:
/* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
(I have not tested this, but it should work. Compare with other
xfail's.)
2) For running QEMU, I have no problem with elf execution. But I do not
know how to auto terminate the QEMU itself as it remains up even after
program execution.
Is there some command to be passed to QEMU in order make system shut
down after program termination with its exit code ?
Yes, this is a problem. For other targets using QEMU I have added dummy
HLT instructions to terminate QEMU, or used a wrapper around QEMU which
sets breakpoints at exit (or _exit) and stops the simulator when hit.
If you are running Linux on QEMU, instead of using QEMU's built-in gdb
interface you might use the Linux system as the target for the test
suite, running gdbserver on the target.
On Tue, Feb 27, 2018 at 10:13 AM, Andrew Sadek
mailto:andrew.sadek...@gmail.com>> wrote:
Thanks Micheal for your response.
I shall re-submit patches separately after re-running the whole GCC
Test suite and re-checking code conventions.
For sending to gdb-patches, it was a conflict from my side as
actually I thought it is also for binutils.
On Tue, Feb 27, 2018 at 2:07 AM, Michael Eager mailto:ea...@eagerm.com>> wrote:
On 02/25/2018 11:44 PM, Andrew Guirguis wrote:
Dears,
Kindly find attached the patch bundle for Microblaze
'-mpic-data-text-relative' feature.
Description of the feature in the following link:
https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md
<https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md>
<https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md
<https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md>>
Bundle includes:
1) Change logs for GCC, binutils
2) GCC Test results and comparison with the original.
3) New Test case (picdtr.c)
4) The Patches (against current heads)
Hi Andrew --
Thanks for the submission. I have the following recommendations:
Submit each patch to the appropriate project mailing list. Only
submit
the patch for the specific project, without patches for other
projects.
Include a description of the changes with each patch as well as the
changelog. Include the patch in your email or as an attachment.
It isn't clear why you sent your submission to the gdb-patches
mailing
list, since there don't appear to be any GDB changes.
Conversely, it is
not clear why you did not include the binutils mailing list,
since you
include a patch to that project.
Be sure to follow GNU coding conventions, Check brace placement,
indent, maximum line length, if statements, etc. I noticed a number
of places where these conventions are not followed in your patches.
GCC regression tests should include all tests (e.g., gcc.dg),
not just the limited number of MicroBlaze-specific tests.
--
Michael Eager ea...@eagerm.com <mailto:ea...@eagerm.com>
1960 Park Blvd., Palo Alto, CA 94306
--
Andrew
--
Andrew
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
On 03/12/18 06:19, Andrew Sadek wrote:
On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager <mailto:ea...@eagerm.com>> wrote:
On 03/02/2018 08:12 AM, Andrew Sadek wrote:
Hello Michael,
I tried running the whole GCC test suite on the current head
(without my patch) along with 'microblaze-qemu' but I have the
following problems:
1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the
gcc is making a 100% CPU usage and the machine stucks.
I tried compiling the file alone, it generated a couple of
warnings than it hangs.
warning: '__builtin_memchr' specified size 4294967295 exceeds
maximum object size 2147483647 [-Wstringop-overflow=]
vp1 = __builtin_memchr (a, b, SIZE1);
Is it a bug? Is there something wrong with my configuration ?
GCC configured with options : --with-newlib --enable-threads=no
--disable-shared --with-pkgversion='crosstool-NG
crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx
--disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-lto
--with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-target-optspace
--disable-nls --enable-multiarch --enable-languages=c,c++
Your configuration is more complex than my hard-metal target version,
but it looks reasonable.
The problem with string-large-1.c does appear to be a bug. You can
add a line to the test case which will mark it as known failure for MB:
/* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
(I have not tested this, but it should work. Compare with other
xfail's.)
Problem that the whole compile package is invoked with '-w' which
inhibits all warnings and overrides ' -Werror' as well as '
-Wfatal-errors' .
As a result, the warning message does not appear when running
compile.exp. Any suggestions ? Do I remove the '-w' ?
2) For running QEMU, I have no problem with elf execution. But I
do not know how to auto terminate the QEMU itself as it remains
up even after program execution.
Is there some command to be passed to QEMU in order make system
shut down after program termination with its exit code ?
Yes, this is a problem. For other targets using QEMU I have added dummy
HLT instructions to terminate QEMU, or used a wrapper around QEMU which
sets breakpoints at exit (or _exit) and stops the simulator when hit.
If you are running Linux on QEMU, instead of using QEMU's built-in gdb
interface you might use the Linux system as the target for the test
suite, running gdbserver on the target.
I have finally managed to fully run QEMU with test suite but had to make
a local modification in the QEMU code itself.
In the translate function, I make a check if "bri 0" is reached which is
the '_exit'. Then, abort the QEMU app with the exit code stored in 'r5'.
I've done essentially the same for other targets.
Here are the results below:
_Without Patch:_
=== gcc Summary ===
# of expected passes90776
# of unexpected failures 1317
# of unexpected successes3
# of expected failures207
# of unresolved testcases115
# of unsupported tests2828
_With Patch and after adding my test case:_
=== gcc Summary ===
# of expected passes90790
# of unexpected failures1317
# of unexpected successes3
# of expected failures207
# of unresolved testcases115
# of unsupported tests2828
This appears to be reasonable results. It appears that there are no
regressions.
Please send me the mb-gcc command line options for both of these test runs.
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
On 03/12/18 23:10, Andrew Sadek wrote:
_Command for running testsuite:_
/make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu
CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h
-L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
-mlittle-endian' "/
_Quick Details:_
1) common.h: Here I define 'STACK_SIZE' with (0x4000) as it's used in
some test cases.
2) -L . /lib: it contains libm, libc in little endian since we use
'qemu-system-microblazeel', and libxil which is the libgloss + some
additional features (read, write, inbyte, outbyte) built with Xilinx SDK.
_mb-gcc command example from gcc.log:_
Testing execute/va-arg-15.c, -O1
doing compile
Executing on
host://home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/xgcc
-B/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/
/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/src/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c
-include /home/andrew/qemu/common.h -L/home/andrew/qemu/lib
-Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -w
-T/home/andrew/qemu/qemu/microblazeel-softmmu/xilinx.ld -lm -o
./va-arg-15.exe (timeout = 300)/
OK. This shows that the patch does not cause regressions when the new
options are not used. That is good.
Please run the same regression test with the new PIC options. Ideally
you should have the same results.
On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager <mailto:ea...@eagerm.com>> wrote:
On 03/12/18 06:19, Andrew Sadek wrote:
On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager mailto:ea...@eagerm.com> <mailto:ea...@eagerm.com
<mailto:ea...@eagerm.com>>> wrote:
On 03/02/2018 08:12 AM, Andrew Sadek wrote:
Hello Michael,
I tried running the whole GCC test suite on the current
head
(without my patch) along with 'microblaze-qemu' but I
have the
following problems:
1) The test is hanging at
'gcc.c-torture/string-large-1.c' , the
gcc is making a 100% CPU usage and the machine stucks.
I tried compiling the file alone, it generated a couple of
warnings than it hangs.
warning: '__builtin_memchr' specified size
4294967295 exceeds
maximum object size 2147483647 [-Wstringop-overflow=]
vp1 = __builtin_memchr (a, b, SIZE1);
Is it a bug? Is there something wrong with my
configuration ?
GCC configured with options : --with-newlib
--enable-threads=no
--disable-shared --with-pkgversion='crosstool-NG
crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx
--disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-lto
--with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-target-optspace
--disable-nls --enable-multiarch --enable-languages=c,c++
Your configuration is more complex than my hard-metal
target version,
but it looks reasonable.
The problem with string-large-1.c does appear to be a bug.
You can
add a line to the test case which will mark it as known
failure for MB:
/* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
(I have not tested this, but it should work. Compare with
other
xfail's.)
Problem that the whole compile package is invoked with '-w'
which inhibits all warnings and overrides ' -Werror' as well as
' -Wfatal-errors' .
As a result, the warning message does not appear when running
compile.exp. Any suggestions ? Do I remove the '-w' ?
2) For running QEMU, I have no problem with elf
execution. But I
do not know how to auto terminate the QEMU itself as
it remains
up even after program execution.
Is there some command to be passed to QEMU in order
make system
shut down after program termination with its exit code ?
Yes, this is a problem. For other targets using QEMU I
have added dummy
HLT instructions to terminate QEMU, or used a wrapper
around QEMU which
sets breakpoints at exit (or _exit) and stops the simulator
Re: [PATCH] [Microblaze]: PIC Data Text Relative
On 03/13/18 00:56, Andrew Sadek wrote: Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test case ? If all is Ok, execution and compilation shall ideally pass for the test cases. Correct. I want to make sure of two things: -- Your patch doesn't break anything (i.e., cause a regression) when you don't use the options. This seems complete. -- Your patch works as intended when you do use the options. But I have noticed that there are some output pattern checks done in some test cases and this may fail since the output assembly is different, anyway I shall give it a try and send you the results with the new options. There should be no target dependencies in the generic GCC tests. Different instruction patterns which generate the correct results should not be a problem. -- Michael Eagerea...@eagerm.com 1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
: gcc.target/microblaze/others/sdata_var4.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var4.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var5.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -O2
-flto -fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -O3
-g scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst1_gpopt.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -O2
-flto -fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -O3
-g scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/string_cst2_gpopt.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
the 'gcc.dg/uninit-19.c ' already fails with -fPIE, and for the
others in microblaze,
expectation is r0 or r13 as a base register which is not the case
here 'r20', and these tests also fails with -fPIE.
Moreover, the test cases that failed due 'unresolved
GLOBAL_OFFSET_TABLE' now pass as we do not have GOT in data text
relative.
Attached the compare output of the scripit with verbosity 2.
Please tell me if any adjustments needed or If I need to re-run nything.
Thanks
On Tue, Mar 13, 2018 at 10:44 PM, Michael Eager mailto:ea...@eagerm.com>> wrote:
On 03/13/18 00:56, Andrew Sadek wrote:
Ok, so you mean with '-fPIC -mpic-data-text-relative' as I
do in my test case ?
If all is Ok, execution and compilation shall ideally pass
for the test cases.
Correct.
I want to make sure of two things:
-- Your patch doesn't break anything (i.e., cause a
regression) when
you don't use the options. This seems complete.
-- Your patch works as intended when you do use the options.
But I have noticed that there are some output pattern checks
done in some test cases and this may fail since the output
assembly is different,
anyway I shall give it a try and send you the results with
the new options.
There should be no target dependencies in the generic GCC tests.
Different instruction patterns which generate the correct
results should
not be a problem.
--
Michael Eager ea...@eagerm.com <mailto:ea...@eagerm.com>
1960 Park Blvd., Palo Alto, CA 94306
--
Andrew
--
Andrew
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
Hi Andrew --
Please take a look at the test case description:
https://gcc.gnu.org/wiki/HowToPrepareATestcase
and see if you can do one of the following:
- Modify the regex expression in the scan-assembler to accept
either format of generated output
or
- Add { dg-option } directives to turn off your new options
if specified. (You should be able to specify -mno-pic)
or
- Duplicate the test cases and add { dg-option } directives
to specify the correct options, with and without your
new options.
or
- Add test cases with a { dg-option } directive with your
new options.
This is not required -- your patch appears to work OK. Normally,
the new PIC Data options would not be used when running the test
suite, so the tests would not fail. It's just nice to have the
test suite updated when new options are added.
On 03/19/2018 01:07 PM, Michael Eager wrote:
Hi Andrew --
Good work.
Please submit your updated patch. Check that you follow
GNU coding standards. Also make sure that the new options
are documented in gcc/doc/invoke.texi.
On 03/18/18 03:27, Andrew Sadek wrote:
Hello Michael,
I have run the test using the new PIC options.
Actually, I have discovered 2 unhandled cases in
'microblaze_expand_move' + missing conditions in linker relax
leading some test cases execution to fail.
After fixing them, I made a re-run for the whole regression, and the
results analogy below:
Original, without my patch:
=== gcc Summary ===
# of expected passes 90776
# of unexpected failures 1317
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2828
With my patch, calling '-fPIE - mpic-data-text-rel'
=== gcc Summary ===
# of expected passes 90843
# of unexpected failures 1256
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2853
After running the 'dg-cmp-results.sh' in contrib folder, the
PASS->FAIL are below:
PASS->FAIL: gcc.dg/uninit-19.c (test for excess errors)
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var2.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL:
Re: [PATCH] [Microblaze]: PIC Data Text Relative
Also check the { dg-skip-if } directive.
https://gcc.gnu.org/onlinedocs/gccint/Directives.html
On 03/19/2018 06:14 PM, Michael Eager wrote:
Hi Andrew --
Please take a look at the test case description:
https://gcc.gnu.org/wiki/HowToPrepareATestcase
and see if you can do one of the following:
- Modify the regex expression in the scan-assembler to accept
either format of generated output
or
- Add { dg-option } directives to turn off your new options
if specified. (You should be able to specify -mno-pic)
or
- Duplicate the test cases and add { dg-option } directives
to specify the correct options, with and without your
new options.
or
- Add test cases with a { dg-option } directive with your
new options.
This is not required -- your patch appears to work OK. Normally,
the new PIC Data options would not be used when running the test
suite, so the tests would not fail. It's just nice to have the
test suite updated when new options are added.
On 03/19/2018 01:07 PM, Michael Eager wrote:
Hi Andrew --
Good work.
Please submit your updated patch. Check that you follow
GNU coding standards. Also make sure that the new options
are documented in gcc/doc/invoke.texi.
On 03/18/18 03:27, Andrew Sadek wrote:
Hello Michael,
I have run the test using the new PIC options.
Actually, I have discovered 2 unhandled cases in
'microblaze_expand_move' + missing conditions in linker relax
leading some test cases execution to fail.
After fixing them, I made a re-run for the whole regression, and the
results analogy below:
Original, without my patch:
=== gcc Summary ===
# of expected passes 90776
# of unexpected failures 1317
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2828
With my patch, calling '-fPIE - mpic-data-text-rel'
=== gcc Summary ===
# of expected passes 90843
# of unexpected failures 1256
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2853
After running the 'dg-cmp-results.sh' in contrib folder, the
PASS->FAIL are below:
PASS->FAIL: gcc.dg/uninit-19.c (test for excess errors)
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -Os
scan-assembler lwi\tr([0-9]|[1-2][
Re: [PATCH] [Microblaze]: PIC Data Text Relative
Hi Andrew --
I just do a visual check. The script can help.
On 03/20/2018 07:13 AM, Andrew Sadek wrote:
Many Thanks Michael for the updates .. I was actually looking for something
similar for my test case .. I m currently revising the Gnu code conventions
on the patches then will send them again.
I m actually running the 'check_GNU_Style' in contrib folder,, is this the
correct way ? Is it enough ?
Andrew
On Tue, Mar 20, 2018, 03:30 Michael Eager wrote:
Also check the { dg-skip-if } directive.
https://gcc.gnu.org/onlinedocs/gccint/Directives.html
On 03/19/2018 06:14 PM, Michael Eager wrote:
Hi Andrew --
Please take a look at the test case description:
https://gcc.gnu.org/wiki/HowToPrepareATestcase
and see if you can do one of the following:
- Modify the regex expression in the scan-assembler to accept
either format of generated output
or
- Add { dg-option } directives to turn off your new options
if specified. (You should be able to specify -mno-pic)
or
- Duplicate the test cases and add { dg-option } directives
to specify the correct options, with and without your
new options.
or
- Add test cases with a { dg-option } directive with your
new options.
This is not required -- your patch appears to work OK. Normally,
the new PIC Data options would not be used when running the test
suite, so the tests would not fail. It's just nice to have the
test suite updated when new options are added.
On 03/19/2018 01:07 PM, Michael Eager wrote:
Hi Andrew --
Good work.
Please submit your updated patch. Check that you follow
GNU coding standards. Also make sure that the new options
are documented in gcc/doc/invoke.texi.
On 03/18/18 03:27, Andrew Sadek wrote:
Hello Michael,
I have run the test using the new PIC options.
Actually, I have discovered 2 unhandled cases in
'microblaze_expand_move' + missing conditions in linker relax
leading some test cases execution to fail.
After fixing them, I made a re-run for the whole regression, and the
results analogy below:
Original, without my patch:
=== gcc Summary ===
# of expected passes90776
# of unexpected failures1317
# of unexpected successes3
# of expected failures207
# of unresolved testcases115
# of unsupported tests2828
With my patch, calling '-fPIE - mpic-data-text-rel'
=== gcc Summary ===
# of expected passes90843
# of unexpected failures1256
# of unexpected successes3
# of expected failures207
# of unresolved testcases115
# of unsupported tests2853
After running the 'dg-cmp-results.sh' in contrib folder, the
PASS->FAIL are below:
PASS->FAIL: gcc.dg/uninit-19.c (test for excess errors)
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var1.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O2
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -O3 -g
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/data_var2.c -Os
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r0
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O0
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O1
scan-assembler lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/others/sdata_var1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler
lwi\tr([0-9]|[1-2][0-9]|3[0-1]),r13
PASS->FAIL: gcc.target/microblaze/
Re: [PATCH] [Microblaze]: PIC Data Text Relative
.
}
else if (flag_pic == 2 && TARGET_PIC_DATA_TEXT_REL)
{
...
}
It's better to factor this into
else if (flag_pic == 2)
{
if (TARGET_PIC_DATA_TEXT_REL)
{
...
}
else
{
...
}
}
microblaze.md:
@@ -1848,7 +1850,7 @@
+if (!flag_pic || (flag_pic && TARGET_PIC_DATA_TEXT_REL))
Test for flag_pic is redundant. This can be
+if (!flag_pic || TARGET_PIC_DATA_TEXT_REL)
doc/invoke.texi:
-mpic-data-text-rel -- include description
Is this different from -mpic-data-is-text-relative?
(Yes, that's a bit of a wordy option.)
doc/tm.texi:
+Return a flag for either generating ADDR_DIF_VEC table
+or ADDR_VEC table for jumps in case of -fPIC.
Explicitly state what true or false means.
target.def:
+(generate_pic_addr_diff_vec,
Explicitly state what true or false means.
targhooks.c:
+bool
+default_generate_pic_addr_diff_vec (void)
+{
+ return true;
+}
This doesn't appear to match the description in target.def.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
On 04/19/2018 03:43 AM, Andrew Sadek wrote:
On Wed, Apr 18, 2018 at 6:57 PM, Michael Eager wrote:
Hi Andrew --
Check indents in the following files:
(Make sure that your tabs are set at 8 chars.)
--- gcc/config/microblaze/microblaze.c
--- gcc/config/microblaze/microblaze.md
I have re-run check_GNU_Style.sh and no are issues are found now.
I corrected a large number of indent problems in microblaze.c.
Just a couple coding notes:
microblaze.c:
@@ -858,6 +879,16 @@ microblaze_classify_address (struct microblaze_add
+ && strict == 2)
Include comment in function header describing meaning of strict == 2.
Done
@@ -1022,7 +1065,7 @@ microblaze_legitimize_address (rtx x, rtx oldx ATT
else if (flag_pic == 2 && !TARGET_PIC_DATA_TEXT_REL)
{
...
}
else if (flag_pic == 2 && TARGET_PIC_DATA_TEXT_REL)
{
...
}
It's better to factor this into
else if (flag_pic == 2)
{
if (TARGET_PIC_DATA_TEXT_REL)
{
...
}
else
{
...
}
}
Done
This code pattern appears twice in microblaze_legitimize_address.
I corrected the second one.
The code in the second occurrence can be refactored to move
if (reload_in_progress)
df_set_regs_ever_live (PIC_OFFSET_TABLE_REGNUM, true);
out of the if(TARGET_PIC_DATA_TEXT_REL) brackets. (Done.)
Please send me an updated ChangeLog, including testsuite.
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] [Microblaze]: PIC Data Text Relative
Committed.
On 05/05/2018 04:14 AM, Andrew Sadek wrote:
Hello Michael,
I made a re-run for the GCC test suite.
I have just noticed that picdtr.c was not uploaded, also I forgot to
adapt the new pic option text in it.
thus we need to apply the attached patch.
Otherwise, it's all fine.
Results (Normal Run):
=== gcc Summary ===
# of expected passes 91211
# of unexpected failures 1325
# of unexpected successes 3
# of expected failures 212
# of unresolved testcases 374
# of unsupported tests 2863
Results (with -fPIE -mpic-data-is-text-relative):
=== gcc Summary ===
# of expected passes 91243
# of unexpected failures 1208
# of unexpected successes 3
# of expected failures 212
# of unresolved testcases 374
# of unsupported tests 2888
Comparison for PASS-> FAIL is only this one now:
PASS->FAIL: gcc.dg/uninit-19.c (test for excess errors) => already fails
with -fPIE/-fPIC as mentioned before.
On Thu, May 3, 2018 at 7:13 PM, Andrew Sadek <mailto:andrew.sadek...@gmail.com>> wrote:
--resend Michael's reply
On Mon, Apr 30, 2018 at 1:19 PM, Michael Eager mailto:ea...@eagerm.com>> wrote:
Applied -- Committed revision 259758.
Andrew -- Please re-run GCC regression test to verify that nothing
was lost in the editing.
--
Michael Eager ea...@eagerm.com <mailto:ea...@eagerm.com>
1960 Park Blvd., Palo Alto, CA 94306
--
Andrew
--
Andrew
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 07/06/14 03:26, Chen Gang wrote:
* microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
'VOID' for operand 1, just like 'call_internal1' has done.
The related warning:
../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1
missing mode?
Signed-off-by: Chen Gang
---
gcc/config/microblaze/microblaze.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/microblaze/microblaze.md
b/gcc/config/microblaze/microblaze.md
index 2bd5d72..9580221 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2171,7 +2171,7 @@
(define_insn "call_value_intern"
[(set (match_operand:VOID 0 "register_operand" "=d")
-(call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
+(call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
(match_operand:SI 2 "" "i")))
(clobber (match_operand:SI 3 "register_operand" "=d"))]
""
This patch causes a test suite regression:
Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -w -c
-mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o
testsuite/gcc.c-torture/compile/calls.c(timeout = 60)
pid is 24832 -24832
testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
(call_insn 5 2 8 2 (parallel [
(set (reg:SI 3 r3)
(call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*)
(void))0B] S4 A32])
(const_int 24 [0x18])))
(clobber (reg:SI 15 r15))
]) testsuite/gcc.c-torture/compile/calls.c:5 -1
(nil)
(nil))
testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in
extract_insn, at recog.c:2204
0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
0x9539cd extract_insn(rtx_def*)
/store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
0x7a5b59 instantiate_virtual_regs_in_insn
/store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
0x7aaa78 instantiate_virtual_regs
/store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] gcc/config/microblaze/microblaze.md: Remove redundant '@' to avoid compiling warning
On 07/05/14 20:59, Chen Gang wrote:
* microblaze/microblaze.md: Remove redundant '@' to avoid compiling
warning.
The related warning:
../../gcc/gcc/config/microblaze/microblaze.md:516: '@' is redundant for
output template with single alternative
Signed-off-by: Chen Gang
---
gcc/config/microblaze/microblaze.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/config/microblaze/microblaze.md
b/gcc/config/microblaze/microblaze.md
index 7945d96..2bd5d72 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -518,8 +518,7 @@
(minus:DI (match_operand:DI 1 "register_operand" "d")
(match_operand:DI 2 "arith_operand32" "d")))]
""
- "@
- rsub\t%L0,%L2,%L1\;rsubc\t%M0,%M2,%M1"
+ "rsub\t%L0,%L2,%L1\;rsubc\t%M0,%M2,%M1"
[(set_attr "type" "darith")
(set_attr "mode" "DI")
(set_attr "length""8")])
Committed revision 213913.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH 140/236] config/microblaze/microblaze.c: Use rtx_insn and rtx_code_label
On 08/06/14 10:21, David Malcolm wrote: gcc/ * config/microblaze/microblaze.c (microblaze_call_tls_get_addr): Strengthen return type and local "insns" from rtx to rtx_insn *. (microblaze_legitimize_tls_address): Likewise for local "insns". (microblaze_block_move_loop): Strengthen local "label" from rtx to rtx_code_label *. (microblaze_expand_prologue): Strengthen two locals named "insn" from rtx to rtx_insn *. (microblaze_asm_output_mi_thunk): Likewise for local "insn". (microblaze_expand_divide): Likewise for locals "jump", "cjump", "insn". Strengthen locals "div_label", "div_end_label" from rtx to rtx_code_label *. OK -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 08/13/14 18:35, Chen Gang wrote: Firstly, thank you very much for spending your time resource on the related 2 patches. You're welcome. On 8/13/14 23:10, Michael Eager wrote: On 07/06/14 03:26, Chen Gang wrote: * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of 'VOID' for operand 1, just like 'call_internal1' has done. The related warning: ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode? Signed-off-by: Chen Gang --- gcc/config/microblaze/microblaze.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md index 2bd5d72..9580221 100644 --- a/gcc/config/microblaze/microblaze.md +++ b/gcc/config/microblaze/microblaze.md @@ -2171,7 +2171,7 @@ (define_insn "call_value_intern" [(set (match_operand:VOID 0 "register_operand" "=d") -(call (mem (match_operand:VOID 1 "call_insn_operand" "ri")) +(call (mem (match_operand:SI 1 "call_insn_operand" "ri")) (match_operand:SI 2 "" "i"))) (clobber (match_operand:SI 3 "register_operand" "=d"))] "" This patch causes a test suite regression: Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o testsuite/gcc.c-torture/compile/calls.c(timeout = 60) pid is 24832 -24832 testsuite/gcc.c-torture/compile/calls.c: In function 'f1': testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn: (call_insn 5 2 8 2 (parallel [ (set (reg:SI 3 r3) (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*) (void))0B] S4 A32]) (const_int 24 [0x18]))) (clobber (reg:SI 15 r15)) ]) testsuite/gcc.c-torture/compile/calls.c:5 -1 (nil) (nil)) testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117 0x9539cd extract_insn(rtx_def*) /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204 0x7a5b59 instantiate_virtual_regs_in_insn /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561 0x7aaa78 instantiate_virtual_regs /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932 OK, thanks, and I shall analyze it, but excuse me, I have to do other things this week, so hope I can finish it within next week (2014-08-24). If this time point is too long to bare, please let me know. Take your time and let me know when you have this resolved. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add Init_priority support.
On 07/28/14 08:42, Ajit Kumar Agarwal wrote: Please find the following patch for init_priority support for microblaze. Testing Done : No regressions seen in gcc and g++ regressions testsuite. [Patch, microblaze]: Add Init_priority support. Added TARGET_ASM_CONSTRUCTOR and TARGET_ASM_DESTRUCTOR macros. These macros allows users to control the order of initialization of objects defined at namespace scope with the init_priority attribute by specifying a relative priority. ChangeLog: 2014-07-28 Ajit Agarwal * config/microblaze/microblaze.c (microblaze_elf_asm_cdtor): New. (microblaze_elf_asm_constructor,microblaze_elf_asm_destructor): New. * config/microblaze/microblaze.h (TARGET_ASM_CONSTRUCTOR,TARGET_ASM_DESTRUCTOR): New Macros. Signed-off-by:Ajit Agarwal ajit...@xilinx.com. Committed revision 214110. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [committed] Remove duplicate contents in gcc/config/rs6000/t-xilinx
On 11/09/13 03:29, Tom de Vries wrote: Michael, This patch removes duplicate contents in gcc/config/rs6000/t-xilinx. Looks like a patch was applied twice. Committed as trivial. Thanks, - Tom 2013-11-08 Tom de Vries * config/rs6000/t-xilinx: Remove duplicate contents. Thanks. That's been there since 2009, but never noticed. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [microblaze] RFA: Use new rtl iterators in microblaze_tls_referenced_p
On 10/25/14 03:05, Richard Sandiford wrote:
This is part of a series to remove uses of for_each_rtx from the ports.
Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for microblaze-elf. OK to install?
Yes, this is OK. Please check for trailing whitespace.
Thanks,
Richard
gcc/
* config/microblaze/microblaze.c: Include rtl-iter.h.
(microblaze_tls_referenced_p_1): Delete.
(microblaze_tls_referenced_p): Use FOR_EACH_SUBRTX.
Index: gcc/config/microblaze/microblaze.c
===
--- gcc/config/microblaze/microblaze.c 2014-10-25 09:40:37.967516501 +0100
+++ gcc/config/microblaze/microblaze.c 2014-10-25 09:51:27.863905096 +0100
@@ -56,6 +56,7 @@
#include "diagnostic-core.h"
#include "cgraph.h"
#include "builtins.h"
+#include "rtl-iter.h"
#define MICROBLAZE_VERSION_COMPARE(VA,VB) strcasecmp (VA, VB)
@@ -444,20 +445,6 @@ microblaze_tls_symbol_p (rtx x)
return SYMBOL_REF_TLS_MODEL (x) != 0;
}
-static int
-microblaze_tls_operand_p_1 (rtx *x, void *data ATTRIBUTE_UNUSED)
-{
- if (GET_CODE (*x) == SYMBOL_REF)
-return SYMBOL_REF_TLS_MODEL (*x) != 0;
-
- /* Don't recurse into UNSPEC_TLS looking for TLS symbols; these are
- TLS offsets, not real symbol references. */
- if (GET_CODE (*x) == UNSPEC && XINT (*x, 1) == UNSPEC_TLS)
-return -1;
-
- return 0;
-}
-
/* Return TRUE if X contains any TLS symbol references. */
bool
@@ -465,8 +452,18 @@ microblaze_tls_referenced_p (rtx x)
{
if (!TARGET_HAVE_TLS)
return false;
-
- return for_each_rtx (&x, microblaze_tls_operand_p_1, NULL);
+ subrtx_iterator::array_type array;
+ FOR_EACH_SUBRTX (iter, array, x, ALL)
+{
+ const_rtx x = *iter;
+ if (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_TLS_MODEL (x) != 0)
+ return true;
+ /* Don't recurse into UNSPEC_TLS looking for TLS symbols; these are
+TLS offsets, not real symbol references. */
+ if (GET_CODE (x) == UNSPEC && XINT (x, 1) == UNSPEC_TLS)
+ iter.skip_subrtxes ();
+}
+ return false;
}
bool
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/26/14 03:36, Chen Gang wrote: On 10/22/2014 09:34 AM, Chen Gang wrote: Yes, if you want to test on a target, you will need a target. You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form. After tried 'sim', I found the root cause is microblaze sim does not support '--sysroot', which is the environments for shared libraries and system calls (need load microblaze kernel). - microblaze can successfully execute simple programs which has no glibc and no system call. - In upstream master branch of binutils, for microblaze sim, it has no related testsuite for sim in binutils, neither support '--sysroot', neither support function stack, startup parameters, and environments. - After hard code the default stack in sim, it can start the '-static' program with glibc, but stop at uname() which will use system call. So I want to consult: at present, can we let microblaze sim run 'normal' programs (have glibc, and use system call)? Microblaze-sim provides basic instruction set architecture and memory simulation. There is no operating system support. (It's also quite old. I'm not sure which version of the MB architecture it models, but it is not recent.) Microblaze-sim is not a full system simulator, like QEMU. To be able to run a program which requires glibc, you need to be able to boot a full Linux image on the simulator, which microblaze-sim cannot do. QEMU models an entire processor and can boot a Linux image. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Added load and store reverse patterns
On 02/10/14 17:55, Michael Eager wrote: On 11/25/13 23:54, David Holsgrove wrote: Added the lwr/swr instructions pattern. lwr and swr instructions will load/store the data with opposite endianness. Changelog 2013-11-26 Nagaraju Mekala * gcc/config/microblaze/microblaze.md: Add movsi4_rev insn pattern. * gcc/config/microblaze/predicates.md: Add reg_or_mem_operand predicate. GCC-head: Committed revision 207683. GCC-4.8-branch: Committed revision 207684. Reverted GCC-4.8-branch commit. Committed revision 211750. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add optimized lshrsi3
On 02/13/14 21:48, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Sunday, 9 February 2014 2:58 am To: David Holsgrove; gcc-patches@gcc.gnu.org Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch, microblaze]: Add optimized lshrsi3 On 11/25/13 23:53, David Holsgrove wrote: Add optimized lshrsi3 instruction, to be used when optimizing for size with immediate values over 5 Changelog 2013-11-26 Nagaraju Mekala * gcc/config/microblaze/microblaze.md: Add size optimized lshrsi3 insn. David -- Please put the description of the patch in the text of the email, rather than hiding it within an attached patch. The patch describes a very specific situation where this patch will have an effect. Please provide a test case. Updated version of patch attached with testcase. New Changelog entries are; Changelog 2013-11-26 David Holsgrove * gcc/config/microblaze/microblaze.md: Add size optimized lshrsi3 insn ChangeLog/testsuite 2014-02-12 David Holsgrove * gcc/testsuite/gcc.target/microblaze/others/lshrsi_Os_1.c: New test. Sorry about the delay in reviewing this patch. I see number of failures in the new lshrsi_Os_1.c test case: PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -Os (test for excess errors) PASS: gcc.target
Re: [Patch, testsuite]: Add MicroBlaze pattern for dg-function-on-line
On 02/13/14 22:06, David Holsgrove wrote: Hi, Attached patch adds a MicroBlaze specific pattern for checking line number and generation of function in dg-function-on-line, in line with the mips method. Changelog/testsuite 2014-02-13 David Holsgrove * gcc/testsuite/lib/scanasm.exp (dg-function-on-line): Add MicroBlaze specific pattern. Committed revision 212189. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH 5/13] microblaze musl support
On 04/27/2015 07:35 AM, Szabolcs Nagy wrote: On 20/04/15 19:54, Szabolcs Nagy wrote: Set up dynamic linker name for microblaze. Patch v2. (undef MUSL_DYNAMIC_LINKER that comes from config/linux.h) gcc/Changelog: 2015-04-24 Gregor Richards * config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define. (DYNAMIC_LINKER): Change. Are you building with both glibc and musl to verify these patches? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized usage of fint instruction.
On 03/04/2015 08:20 AM, Michael Eager wrote: On 03/04/15 03:53, Ajit Kumar Agarwal wrote: -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Thursday, February 26, 2015 4:33 AM To: Ajit Kumar Agarwal; GCC Patches Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,microblaze]: Optimized usage of fint instruction. On 02/25/15 02:20, Ajit Kumar Agarwal wrote: Hello All: Please find the patch for the optimized usage of fint instruction changes. No regression is seen in the deja GNU tests. commit ed4dc0b96bf43c200cacad97f73a98ab7048e51b Author: Ajit Kumar Agarwal Date: Wed Feb 25 15:36:29 2015 +0530 [Patch,microblaze]: Optimized usage of fint instruction. The changes are made in the patch for optimized usage of fint instruction. The sequence of fint/cond_branch is replaced with fcmp/cond_branch. The fint instruction takes 6/7 cycles as compared to fcmp instruction which takes 1 cycles. The conversion from float to int with fint instruction is not required and can directly compared with fcmp instruction which takes 1 cycle as compared to 6/7 cycles with fint instruction. ChangeLog: 2015-02-25 Ajit Agarwal * config/microblaze/microblaze.md (peephole2): New. +emit_insn (gen_cstoresf4 (comp_reg, operands[2], + gen_rtx_REG(SFmode,REGNO(cmp_op0)), + gen_rtx_REG(SFmode,REGNO(cmp_op1; Spaces before left parens and after comma in last two lines. Changes are incorporated. Please find the log for updated patch. commit 492b0d0b67a5b12d2dc239de3215630c8838edea Author: Ajit Kumar Agarwal Date: Wed Mar 4 17:15:16 2015 +0530 [Patch,microblaze]: Optimized usage of fint instruction. The changes are made in the patch for optimized usage of fint instruction. The sequence of fint/cond_branch is replaced with fcmp/cond_branch. The fint instruction takes 6/7 cycles as compared to fcmp instruction which takes 1 cycles. The conversion from float to int with fint instruction is not required and can directly compared with fcmp instruction which takes 1 cycle as compared to 6/7 cycles with fint instruction. ChangeLog: 2015-03-04 Ajit Agarwal * config/microblaze/microblaze.md (peephole2): New. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit OK. Committed revision 222790. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized usage of pcmp conditional instruction.
On 03/06/2015 07:33 AM, Michael Eager wrote: On 03/05/15 21:12, Ajit Kumar Agarwal wrote: Changes are incorporated. Please find the log of the updated patch. commit 91f275c144165320850ddf18e3a1e059a66c Author: Ajit Kumar Agarwal Date: Fri Mar 6 09:55:11 2015 +0530 [Patch,microblaze]: Optimized usage of pcmp conditional instruction. The changes are made in the patch for optimized usage of pcmpne/pcmpeq instructions. The xor with register to register is replaced with pcmpeq /pcmpne instructions and for immediate check still the xori will be used. The purpose of the change is to acheive the aggressive usage of pcmpne /pcmpeq instructions instead of xor being used for comparison. ChangeLog: 2015-03-06 Ajit Agarwal * config/microblaze/microblaze.md (cbranchsi4): Added immediate constraints. (cbranchsi4_reg): New. * config/microblaze/microblaze.c (microblaze_expand_conditional_branch_reg): New. * config/microblaze/microblaze-protos.h (microblaze_expand_conditional_branch_reg): New prototype. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit OK. Committed revision 222791. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
On 12/01/14 14:02, Cary Coutant wrote: [+cc Michael Eager] Rather than having to lobby to keep it unchanged because we jumped the gun, can we lobby to get the number assigned in the near future rather than in the potentially far future? That feels more cooperative to me :-) Would that make Michael happier? I'm pretty confident that Michael will say, "don't rely on the value until the final spec is published." (He's told me exactly that in the past. I've been guilty of jumping the gun on a couple of DW_LANG codes and a few DW_AT values.) But we should let Michael answer for himself... As Cary said, the values are not fixed until the spec is released. As Jason said, the values are unlikely to change. The standards process can be a bit messy at times, particularly when we realize that something we added to a draft needs to be changed. We try to avoid making unnecessary changes, naturally. On the other hand, we don't want something in an internal draft of the DWARF specification to prevent us from making necessary changes. We will avoid changing the value of the DW_AT_noreturn or any other new attribute, if for no reason than it makes additional work for us. We're also aware that changes may affect work on GCC, GDB, or other tools, which we would like to avoid. The most conservative approach is to wait for the DWARF Version 5 spec to be released. While there is no guarantee that attribute values will not change in the final spec, the risk if this happening seems small. Michael, for your reference, here's the start of this thread: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03195.html and its continuation into December: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00099.html Michael, are you OK with sharing your target dates for publishing the spec? We will likely have a public review draft available in April or May with a 60 period for comments, with final release most likely in July. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized usage of pcmp conditional instruction.
On 02/25/15 02:19, Ajit Kumar Agarwal wrote:
Hello All:
Please find the patch for the optimized usage of pcmp instructions in
microblaze. No regressions is seen
In deja GNU tests. There are many testcases that are already there in deja GNU
to check the generation of
pcmpne/pcmpeq instructions and are used to check the validity.
commit b74acf44ce4286649e5be7cff7518d814cb2491f
Author: Ajit Kumar Agarwal
Date: Wed Feb 25 15:33:02 2015 +0530
[Patch,microblaze]: Optimized usage of pcmp conditional instruction.
The changes are made in the patch for optimized usage of pcmpne/pcmpeq
instructions. The xor with register to register is replaced with pcmpeq
/pcmpne instructions and for immediate check still the xori will be used.
The purpose of the change is to acheive the aggressive usage of pcmpne
/pcmpeq instructions instead of xor being used for comparison.
ChangeLog:
2015-02-25 Ajit Agarwal
* config/microblaze/microblaze.md (cbranchsi4): Added immediate
constraints.
(cbranchsi4_reg): New.
* config/microblaze/microblaze.c
(microblaze_expand_conditional_branch_reg): New.
* config/microblaze/microblaze-protos.h
(microblaze_expand_conditional_branch_reg): New prototype.
+ if (cmp_op1 == const0_rtx)
+{
+ comp_reg = cmp_op0;
+ condition = gen_rtx_fmt_ee (signed_condition (code),
+ SImode, comp_reg, const0_rtx);
+ emit_jump_insn (gen_condjump (condition, label1));
+}
+
+ else if (code == EQ || code == NE)
+{
+ if (code == NE)
+{
+ emit_insn (gen_sne_internal_pat (comp_reg, cmp_op0,
+ cmp_op1));
+ condition = gen_rtx_NE (SImode, comp_reg, const0_rtx);
+}
+ else
+{
+ emit_insn (gen_seq_internal_pat (comp_reg,
+ cmp_op0, cmp_op1));
+ condition = gen_rtx_EQ (SImode, comp_reg, const0_rtx);
+}
+ emit_jump_insn (gen_condjump (condition, label1));
+}
+ else
+{
...
No blank line between end brace of if and else.
Replace with
+ else if (code == EQ)
+{
+ emit_insn (gen_seq_internal_pat (comp_reg, cmp_op0, cmp_op1));
+ condition = gen_rtx_EQ (SImode, comp_reg, const0_rtx);
+ emit_jump_insn (gen_condjump (condition, label1));
+}
+ else if (code == NE)
+{
+ emit_insn (gen_sne_internal_pat (comp_reg, cmp_op0, cmp_op1));
+ condition = gen_rtx_NE (SImode, comp_reg, const0_rtx);
+ emit_jump_insn (gen_condjump (condition, label1));
+}
+ else
+{
...
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized usage of fint instruction.
On 02/25/15 02:20, Ajit Kumar Agarwal wrote: Hello All: Please find the patch for the optimized usage of fint instruction changes. No regression is seen in the deja GNU tests. commit ed4dc0b96bf43c200cacad97f73a98ab7048e51b Author: Ajit Kumar Agarwal Date: Wed Feb 25 15:36:29 2015 +0530 [Patch,microblaze]: Optimized usage of fint instruction. The changes are made in the patch for optimized usage of fint instruction. The sequence of fint/cond_branch is replaced with fcmp/cond_branch. The fint instruction takes 6/7 cycles as compared to fcmp instruction which takes 1 cycles. The conversion from float to int with fint instruction is not required and can directly compared with fcmp instruction which takes 1 cycle as compared to 6/7 cycles with fint instruction. ChangeLog: 2015-02-25 Ajit Agarwal * config/microblaze/microblaze.md (peephole2): New. +emit_insn (gen_cstoresf4 (comp_reg, operands[2], + gen_rtx_REG(SFmode,REGNO(cmp_op0)), + gen_rtx_REG(SFmode,REGNO(cmp_op1; Spaces before left parens and after comma in last two lines. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized usage of fint instruction.
On 03/04/15 03:53, Ajit Kumar Agarwal wrote: -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Thursday, February 26, 2015 4:33 AM To: Ajit Kumar Agarwal; GCC Patches Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,microblaze]: Optimized usage of fint instruction. On 02/25/15 02:20, Ajit Kumar Agarwal wrote: Hello All: Please find the patch for the optimized usage of fint instruction changes. No regression is seen in the deja GNU tests. commit ed4dc0b96bf43c200cacad97f73a98ab7048e51b Author: Ajit Kumar Agarwal Date: Wed Feb 25 15:36:29 2015 +0530 [Patch,microblaze]: Optimized usage of fint instruction. The changes are made in the patch for optimized usage of fint instruction. The sequence of fint/cond_branch is replaced with fcmp/cond_branch. The fint instruction takes 6/7 cycles as compared to fcmp instruction which takes 1 cycles. The conversion from float to int with fint instruction is not required and can directly compared with fcmp instruction which takes 1 cycle as compared to 6/7 cycles with fint instruction. ChangeLog: 2015-02-25 Ajit Agarwal * config/microblaze/microblaze.md (peephole2): New. +emit_insn (gen_cstoresf4 (comp_reg, operands[2], + gen_rtx_REG(SFmode,REGNO(cmp_op0)), + gen_rtx_REG(SFmode,REGNO(cmp_op1; Spaces before left parens and after comma in last two lines. Changes are incorporated. Please find the log for updated patch. commit 492b0d0b67a5b12d2dc239de3215630c8838edea Author: Ajit Kumar Agarwal Date: Wed Mar 4 17:15:16 2015 +0530 [Patch,microblaze]: Optimized usage of fint instruction. The changes are made in the patch for optimized usage of fint instruction. The sequence of fint/cond_branch is replaced with fcmp/cond_branch. The fint instruction takes 6/7 cycles as compared to fcmp instruction which takes 1 cycles. The conversion from float to int with fint instruction is not required and can directly compared with fcmp instruction which takes 1 cycle as compared to 6/7 cycles with fint instruction. ChangeLog: 2015-03-04 Ajit Agarwal * config/microblaze/microblaze.md (peephole2): New. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch,microblaze]: Optimized usage of pcmp conditional instruction.
On 03/05/15 21:12, Ajit Kumar Agarwal wrote: Changes are incorporated. Please find the log of the updated patch. commit 91f275c144165320850ddf18e3a1e059a66c Author: Ajit Kumar Agarwal Date: Fri Mar 6 09:55:11 2015 +0530 [Patch,microblaze]: Optimized usage of pcmp conditional instruction. The changes are made in the patch for optimized usage of pcmpne/pcmpeq instructions. The xor with register to register is replaced with pcmpeq /pcmpne instructions and for immediate check still the xori will be used. The purpose of the change is to acheive the aggressive usage of pcmpne /pcmpeq instructions instead of xor being used for comparison. ChangeLog: 2015-03-06 Ajit Agarwal * config/microblaze/microblaze.md (cbranchsi4): Added immediate constraints. (cbranchsi4_reg): New. * config/microblaze/microblaze.c (microblaze_expand_conditional_branch_reg): New. * config/microblaze/microblaze-protos.h (microblaze_expand_conditional_branch_reg): New prototype. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH 17/30] Changes to microblaze
OK On 6/25/19 1:22 PM, acsaw...@linux.ibm.com wrote: From: Aaron Sawdey * config/microblaze/microblaze.c: Change movmem to cpymem in comment. * config/microblaze/microblaze.md (movmemsi): Change name to cpymemsi. --- gcc/config/microblaze/microblaze.c | 2 +- gcc/config/microblaze/microblaze.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/microblaze/microblaze.c b/gcc/config/microblaze/microblaze.c index 947eef8..c2cbe3b 100644 --- a/gcc/config/microblaze/microblaze.c +++ b/gcc/config/microblaze/microblaze.c @@ -1250,7 +1250,7 @@ microblaze_block_move_loop (rtx dest, rtx src, HOST_WIDE_INT length) microblaze_block_move_straight (dest, src, leftover); } -/* Expand a movmemsi instruction. */ +/* Expand a cpymemsi instruction. */ bool microblaze_expand_block_move (rtx dest, rtx src, rtx length, rtx align_rtx) diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md index 183afff..1509e43 100644 --- a/gcc/config/microblaze/microblaze.md +++ b/gcc/config/microblaze/microblaze.md @@ -1144,7 +1144,7 @@ ;; Argument 2 is the length ;; Argument 3 is the alignment -(define_expand "movmemsi" +(define_expand "cpymemsi" [(parallel [(set (match_operand:BLK 0 "general_operand") (match_operand:BLK 1 "general_operand")) (use (match_operand:SI 2 "")) -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306
Re: [PATCH] microblaze.c: fix warnings
OK to apply,
On 06/01/2016 01:04 PM, David Malcolm wrote:
The two microblaze configurations in contrib/config-list.mk
microblaze-elf
microblaze-linux
currently fail to build due to warnings:
microblaze.c: In function 'void insert_wic_for_ilb_runout(rtx_insn*)':
microblaze.c:3653:7: error: unused variable 'wic_addr1'
[-Werror=unused-variable]
int wic_addr1 = 128 * 4;
^
microblaze.c: In function 'void insert_wic()':
microblaze.c:3696:10: error: unused variable 'j' [-Werror=unused-variable]
int i, j;
^
microblaze.c: In function 'rtx_def* get_branch_target(rtx)':
microblaze.c:3627:1: error: control reaches end of non-void function
[-Werror=return-type]
}
^
(tested with compiling trunk using gcc 6).
It looks like these warnings were introduced in this last commit to
microblaze.c, r232683:
2016-01-21 Ajit Agarwal
* config/microblaze/microblaze.c
(get_branch_target): New.
(insert_wic_for_ilb_runout): New.
(insert_wic): New.
(microblaze_machine_dependent_reorg): New.
(TARGET_MACHINE_DEPENDENT_REORG): Define macro.
* config/microblaze/microblaze.md
(UNSPEC_IPREFETCH): Define.
(iprefetch): New pattern
* config/microblaze/microblaze.opt
(mxl-prefetch): New flag.
The attached patch fixes them.
I picked NULL_RTX as a return value for get_branch_target; is this
sane? The result is only ever assigned to the local "branch_target"
here:
3732 if ((branch_target = get_branch_target (insn)))
and that local appears to be unused otherwise.
OK for trunk? (I've only verified that it compiles and fixes the
warnings; I haven't tested the results).
gcc/ChangeLog:
* config/microblaze/microblaze.c (get_branch_target): Add return
NULL_RTX for the non-CALL_P case.
(insert_wic_for_ilb_runout): Remove unused local "wic_addr1".
(insert_wic): Remove unused local "j".
---
gcc/config/microblaze/microblaze.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/microblaze/microblaze.c
b/gcc/config/microblaze/microblaze.c
index baff67a..8f4768e 100644
--- a/gcc/config/microblaze/microblaze.c
+++ b/gcc/config/microblaze/microblaze.c
@@ -3624,6 +3624,8 @@ get_branch_target (rtx branch)
abort ();
return XEXP (XEXP (call, 0), 0);
}
+
+ return NULL_RTX;
}
/* Heuristics to identify where to insert at the
@@ -3650,7 +3652,6 @@ insert_wic_for_ilb_runout (rtx_insn *first)
int addr_offset = 0;
int length;
int wic_addr0 = 128 * 4;
- int wic_addr1 = 128 * 4;
int first_addr = INSN_ADDRESSES (INSN_UID (first));
@@ -3693,7 +3694,7 @@ static void
insert_wic (void)
{
rtx_insn *insn;
- int i, j;
+ int i;
basic_block bb, prev = 0;
rtx branch_target = 0;
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: regression for microblaze architecture
From https://gcc.gnu.org/ml/gcc/2017-05/msg00221.html: On 05/27/2017 09:09 AM, Michael Eager wrote: On 05/27/2017 01:51 AM, Waldemar Brodkorb wrote: Hi, Buildroot and OpenADK have samples to create a Linux system to be bootup in Qemu system emulation for microblaze architecture. With gcc 6.3 and 7.1 the samples are not working anymore, because the Linux system userland does not boot. Qemu 2.9.0: Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b (with glibc, musl and uClibc-ng toolchains) I bisected gcc source code and found the bad commit: 6dcad60c0ef48af584395a40feeb256fb82986a8 When reverting the change, gcc 6.3 and 7.1 produces working Linux rootfs again. What can we do about it? I will revert this commit in GCC. Reverted on GCC mainline: Committed revision 248540. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Make MicroBlaze support DWARF EH (old Xilinx patch, needed for glibc build)
On 01/02/2017 03:45 PM, Joseph Myers wrote: This patch, taken from <https://git.busybox.net/buildroot/tree/package/gcc/5.4.0/840-microblaze-enable-dwarf-eh-support.patch> and with a few formatting cleanups and an update for the removal of gen_rtx_raw_REG, enables DWARF EH support for MicroBlaze. This is needed for building glibc with a compiler that includes shared libgcc; right now all glibc builds for MicroBlaze are failing with my bot for lack of this support. (It's dubious if we should have glibc ports at all where required support is missing in FSF GCC.) Tested building glibc with build-many-glibcs.py. I have *not* done any other testing or any execution testing for MicroBlaze. OK to commit? I have two concerns; 1. Lack of testing on MicroBlaze. Although the patch presumably works in the Buildroot environment, that's not the same source base. I may be able to build and test this patch, but it will be a couple weeks before I can get to it. 2. Ownership and copyright. This is clearly not your authorship. Submission of a patch explicitly indicates that you are assigning your copyright interest in the patch to the FSF. I don't believe that you have copyright to this patch and can't assign it to FSF. On multiple occasions, I have asked Xilinx to submit patches such as this one directly to the GCC/Binutils projects (assuming that they have a current FSF Copyright Assignment), or to give me explicit permission to do so on their behalf, as was the case when I originally submitted the MicroBlaze port to these projects. For whatever reason, neither has occurred. The first issue is procedural/technical and easily resolved. The second issue involves Copyright Law. IANAL, but my understanding is that a third party cannot take a patch from a non-FSF/GNU repository and apply it to an FSF/GNU repository without the authors' agreement and assignment of copyright. (If Buildroot were an FSF/GNU project, then copyright would have already been assigned to FSF, presumably, and accepting the patch into GCC would not involve any transfer of ownership.) Does anyone have any authority on this copyright issue? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Make MicroBlaze support DWARF EH (old Xilinx patch, needed for glibc build)
On 01/06/2017 01:34 AM, Edgar E. Iglesias wrote: On Thu, Jan 05, 2017 at 05:58:01PM +, Joseph Myers wrote: On Thu, 5 Jan 2017, Michael Eager wrote: On multiple occasions, I have asked Xilinx to submit patches such as this one directly to the GCC/Binutils projects (assuming that they have a current FSF Copyright Assignment), or to give me explicit permission to do so on their behalf, as was the case when I originally submitted the MicroBlaze port to these projects. For whatever reason, neither has occurred. copyright.list shows assignments from Xilinx for GCC, binutils, GDB and glibc, with no indication that they are not current, or of any restriction on who at Xilinx can contribute changes. Thus, I presume we simply need someone at Xilinx to approve the contribution of this patch to GCC. The last patch sent to gcc-patches by someone @xilinx.com appears to have been <https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02291.html>; author and other @xilinx.com people from that discussion CC:ed on this message. Hi Joseph, There's no problem from our side. In fact, a version of this patch has already been posted to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00657.html I don't do any work on the toolchain anymore and don't have the setup to run the testsuite. Ajit or Nagaraju are might be able to help resolve any issues. Cheers, Edgar -- Joseph S. Myers jos...@codesourcery.com OK to apply. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Enable no-exec stacks for more targets using the Linux kernel
On 09/19/2017 12:17 AM, Andreas Schwab wrote: On Sep 18 2017, Joseph Myers wrote: Building glibc for many different configurations and running the compilation parts of the testsuite runs into failures of the elf/check-execstack test for hppa, ia64 and microblaze. ia64 is non-execstack by default, so it doesn't need any marking. The same is true for every architecture that doesn't override elf_read_implies_exec, which includes microblaze and hppa. This fails because those configurations are not generating .note.GNU-stack sections to indicate that programs do not need an executable stack. This needs to be fixed in glibc. The requirement that a null .note.GNU-stack section needs to be defined to indicate that the default stack (i.e., non-executable) is used seems backward. I don't have any problem approving the MicroBlaze GCC changes, but, like Andreas, I think that this is a glibc problem. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [www patch] sort branches
On 02/13/2017 06:34 AM, Nathan Sidwell wrote: I've applied this patch to sort the other branch lists in svn.html. I also added an index and split the inactive branch list into merged and plain inactive. Attention branch maintainers: Please check whether I've incorrectly put a merged branch on the inactive list. nathan The microblaze branch has been merged into the gcc mainline. diff -urNp svn.html-orig svn.html --- svn.html-orig 2017-02-13 09:00:36.0 -0800 +++ svn.html2017-02-13 09:04:50.0 -0800 @@ -455,12 +455,6 @@ the command svn log --stop-on-copy are Dwarakanath Rajagopal <href="mailto:dwarak.rajago...@amd.com";>dwarak.rajago...@amd.com> and H.J. Lu <mailto:hjl.to...@gmail.com";>hjl.to...@gmail.com>. - microblaze - This branch contains support for the Xilinx MicroBlaze architecture. - This branch will be used to update MicroBlaze support from gcc-4.1.2 to - to the head. It is maintained by Michael Eager - <mailto:ea...@eagercon.com";>ea...@eagercon.com>. - mpx The goal of this branch is to support Intel MPX technology (href="https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf";>link). @@ -790,6 +784,13 @@ be prefixed with the initials of the dis and is currently unmaintained. This work now continues on the autovect-branch. + microblaze + This branch contained support for updating the Xilinx MicroBlaze + architecture to gcc-4.1.2. + It was created by Michael Eager + <mailto:ea...@eagercon.com";>ea...@eagercon.com>. + All changes have been merged into mainline. + https://gcc.gnu.org/wiki/MemRef";>mem-ref2 mips-3_4-rewrite-branch named-addr-spaces-branch -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH 3/6] microblaze: Fixes for RTL checking
On 02/21/2017 06:48 AM, Segher Boessenkool wrote:
REGNO can only be called on REGs, not SUBREGs; and INTVAL does not work
on REGs.
2017-02-21 Segher Boessenkool
* config/microblaze/microblaze.c (microblaze_expand_shift): Do not
test for register moves to themselves.
* config/microblaze/microblaze.md (*ashlsi3_byone, *ashrsi3_byone,
*lshrsi3_byone): Test for const1_rtx instead of calling INTVAL on
something that isn't necessarily a CONST_INT.
---
gcc/config/microblaze/microblaze.c | 5 ++---
gcc/config/microblaze/microblaze.md | 6 +++---
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/gcc/config/microblaze/microblaze.c
b/gcc/config/microblaze/microblaze.c
index 746bef1..4850e85 100644
--- a/gcc/config/microblaze/microblaze.c
+++ b/gcc/config/microblaze/microblaze.c
@@ -3322,11 +3322,10 @@ microblaze_expand_shift (rtx operands[])
|| (GET_CODE (operands[1]) == REG)
|| (GET_CODE (operands[1]) == SUBREG));
- /* Shift by zero -- copy regs if necessary. */
+ /* Shift by zero -- copy regs. */
if ((GET_CODE (operands[2]) == CONST_INT) && (INTVAL (operands[2]) == 0))
{
- if (REGNO (operands[0]) != REGNO (operands[1]))
- emit_insn (gen_movsi (operands[0], operands[1]));
+ emit_insn (gen_movsi (operands[0], operands[1]));
return 1;
}
Why generate an unnecessary NOP?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH 3/6] microblaze: Fixes for RTL checking
On 02/21/2017 12:15 PM, Jakub Jelinek wrote: On Tue, Feb 21, 2017 at 02:48:15PM +, Segher Boessenkool wrote: - /* Shift by zero -- copy regs if necessary. */ + /* Shift by zero -- copy regs. */ if ((GET_CODE (operands[2]) == CONST_INT) && (INTVAL (operands[2]) == 0)) You could have changed this line to if (operands[2] == const0_rtx) as well. And this would not change the generated code. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH 3/6] microblaze: Fixes for RTL checking
On 02/21/2017 12:25 PM, Segher Boessenkool wrote:
On Tue, Feb 21, 2017 at 12:08:34PM -0800, Michael Eager wrote:
- /* Shift by zero -- copy regs if necessary. */
+ /* Shift by zero -- copy regs. */
if ((GET_CODE (operands[2]) == CONST_INT) && (INTVAL (operands[2]) ==
0))
{
- if (REGNO (operands[0]) != REGNO (operands[1]))
- emit_insn (gen_movsi (operands[0], operands[1]));
+ emit_insn (gen_movsi (operands[0], operands[1]));
return 1;
}
Why generate an unnecessary NOP?
Why not? It will be optimised away anyway, and the code to get at the
subregs is hairy... But could optimise away the useless move here
already if both ops are a reg and both are the same, if you prefer that?
Or rtx_equal_p (operands[0], operands[1])?
It's optimized away only if optimization is on.
The existing code checks and does not generate the unneeded move.
Whatever you change to clean up code should maintain the same behavior.
if ((operands[2] == const0_rtx) && !rtx_equal_p (operands[0], operands[1]))
{
emit_insn (gen_movsi (operands[0], operands[1]));
}
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [www patch] sort branches
On 02/26/2017 01:38 AM, Gerald Pfeifer wrote: On Mon, 13 Feb 2017, Michael Eager wrote: The microblaze branch has been merged into the gcc mainline. Thanks for the patch, Michael. I noticed you had not committed it, so I just did that for you (with a little tweak in how we refer to GCC 4.2.1 as opposed to gcc-4.2.1). Thanks. (I don't think that I have write permission for wwwdocs.) -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[PATCH] Microblaze: Fixes for RTL Checking
2017-03-09 Michael Eager
Correct failures with --enable-checking=yes,rtl.
* config/microblaze/microblaze.c (microblaze_expand_shift):
Replace GET_CODE test with CONST_INT_P and INTVAL test with
test for const0_rtx.
* config/microblaze/microblaze.md (ashlsi3_byone, ashrsi3_byone,
lshrsi3_byone): Replace INTVAL with test for const1_rtx.
diff --git a/gcc/config/microblaze/microblaze.c
b/gcc/config/microblaze/microblaze.c
index 746bef1..fb115e6 100644
--- a/gcc/config/microblaze/microblaze.c
+++ b/gcc/config/microblaze/microblaze.c
@@ -3323,10 +3323,10 @@ microblaze_expand_shift (rtx operands[])
|| (GET_CODE (operands[1]) == SUBREG));
/* Shift by zero -- copy regs if necessary. */
- if ((GET_CODE (operands[2]) == CONST_INT) && (INTVAL (operands[2]) == 0))
+ if (CONST_INT_P (operands[2]) && (operands[2] == const0_rtx)
+ && !rtx_equal_p (operands[0], operands[1]))
{
- if (REGNO (operands[0]) != REGNO (operands[1]))
- emit_insn (gen_movsi (operands[0], operands[1]));
+ emit_insn (gen_movsi (operands[0], operands[1]));
return 1;
}
diff --git a/gcc/config/microblaze/microblaze.md
b/gcc/config/microblaze/microblaze.md
index 66ebc1e..b3a0011 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -1321,7 +1321,7 @@
[(set (match_operand:SI 0 "register_operand" "=d")
(ashift:SI (match_operand:SI 1 "register_operand" "d")
(match_operand:SI 2 "arith_operand""I")))]
- "(INTVAL (operands[2]) == 1)"
+ "(operands[2] == const1_rtx)"
"addk\t%0,%1,%1"
[(set_attr "type""arith")
(set_attr "mode""SI")
@@ -1482,7 +1482,7 @@
[(set (match_operand:SI 0 "register_operand" "=d")
(ashiftrt:SI (match_operand:SI 1 "register_operand" "d")
(match_operand:SI 2 "arith_operand""I")))]
- "(INTVAL (operands[2]) == 1)"
+ "(operands[2] == const1_rtx)"
"sra\t%0,%1"
[(set_attr "type""arith")
(set_attr "mode""SI")
@@ -1571,7 +1571,7 @@
[(set (match_operand:SI 0 "register_operand" "=d")
(lshiftrt:SI (match_operand:SI 1 "register_operand" "d")
(match_operand:SI 2 "arith_operand""I")))]
- "(INTVAL (operands[2]) == 1)"
+ "(operands[2] == const1_rtx)"
"srl\t%0,%1"
[(set_attr "type""arith")
(set_attr "mode""SI")
Committed revision 246012.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] Microblaze: Fixes for RTL Checking
On 03/09/2017 03:35 PM, Segher Boessenkool wrote: Hi! On Thu, Mar 09, 2017 at 10:18:43AM -0800, Michael Eager wrote: --- a/gcc/config/microblaze/microblaze.c +++ b/gcc/config/microblaze/microblaze.c @@ -3323,10 +3323,10 @@ microblaze_expand_shift (rtx operands[]) || (GET_CODE (operands[1]) == SUBREG)); /* Shift by zero -- copy regs if necessary. */ - if ((GET_CODE (operands[2]) == CONST_INT) && (INTVAL (operands[2]) == 0)) + if (CONST_INT_P (operands[2]) && (operands[2] == const0_rtx) You don't need that first test since you have the second (and the parens are superfluous as well). Yes. Fixed. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] fix linker name for uClibc
On 10/28/2016 11:14 AM, Waldemar Brodkorb wrote:
Hi,
uClibc-ng can be used for Microblaze architecture.
It is regulary tested with qemu-system-microblaze in little and
big endian mode.
2016-10-28 Waldemar Brodkorb
gcc/
* config/microblaze/linux.h: add UCLIBC_DYNAMIC_LINKER
diff --git a/gcc/config/microblaze/linux.h b/gcc/config/microblaze/linux.h
index ae8523c..b3bf43a 100644
--- a/gcc/config/microblaze/linux.h
+++ b/gcc/config/microblaze/linux.h
@@ -29,6 +29,7 @@
#define TLS_NEEDS_GOT 1
#define GLIBC_DYNAMIC_LINKER "/lib/ld.so.1"
+#define UCLIBC_DYNAMIC_LINKER "/lib/ld-uClibc.so.0"
#if TARGET_BIG_ENDIAN_DEFAULT == 0 /* LE */
#define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:;:el}"
best regards
Waldemar
OK to apply.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] fix linker name for uClibc
On 10/31/2016 08:04 AM, Jeff Law wrote:
On 10/28/2016 03:30 PM, Michael Eager wrote:
On 10/28/2016 11:14 AM, Waldemar Brodkorb wrote:
Hi,
uClibc-ng can be used for Microblaze architecture.
It is regulary tested with qemu-system-microblaze in little and
big endian mode.
2016-10-28 Waldemar Brodkorb
gcc/
* config/microblaze/linux.h: add UCLIBC_DYNAMIC_LINKER
diff --git a/gcc/config/microblaze/linux.h
b/gcc/config/microblaze/linux.h
index ae8523c..b3bf43a 100644
--- a/gcc/config/microblaze/linux.h
+++ b/gcc/config/microblaze/linux.h
@@ -29,6 +29,7 @@
#define TLS_NEEDS_GOT 1
#define GLIBC_DYNAMIC_LINKER "/lib/ld.so.1"
+#define UCLIBC_DYNAMIC_LINKER "/lib/ld-uClibc.so.0"
#if TARGET_BIG_ENDIAN_DEFAULT == 0 /* LE */
#define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:;:el}"
best regards
Waldemar
OK to apply.
Thanks. I don't believe Waldemar has write access, so I committed the patch
for him.
Thanks.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [doc, committed] document MicroBlaze interrupt_handler and fast_interrupt attributes
On 01/05/2016 10:08 AM, Sandra Loosemore wrote: I've checked in this patch to add some minimal documentation for the MicroBlaze interrupt handler attributes. I was able to figure this out by inspection of the code and reading the processor documentation, which has a more extensive discussion of how to use these features. -Sandra OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 12/20/14 02:09, Chen Gang wrote: By the way, if this thread really has negative effect with other members, please warn me, I should not notify it to mailing list again, and try my best to finish it within myself. I appreciate your enthusiasm and perseverance in pursuing this bug. If the problem you are working on has changed from the mb-gcc issue, change the subject. Otherwise, keep up the good work. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/14/14 00:51, Chen Gang wrote: Hello maintainers: I also find some warnings during compiling microblaze, I also shall try to fix them, but excuse me, I am not quite familiar the testsuite for microblaze, could you provide any related information for it? Hi Chen -- This is the gcc DejaGNU test suite. You can find info about DejaGNU at http://www.gnu.org/software/dejagnu. There is also info about testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC Rather than the standard "make check-gcc" described on the wiki page and elsewhere, I use a script which sets some configuration options and executes runtest directly. This uses a MicroBlaze processor simulator called vpexec which was included with an older version of Xilinx's EDK. Xilinx no longer supports vpexec. You can use a hardware target board to test microblaze-gcc, or a different simulator such as QEMU. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/14/14 21:19, Chen Gang wrote: On 9/15/14 11:03, Michael Eager wrote: On 09/14/14 00:51, Chen Gang wrote: Hello maintainers: I also find some warnings during compiling microblaze, I also shall try to fix them, but excuse me, I am not quite familiar the testsuite for microblaze, could you provide any related information for it? Hi Chen -- This is the gcc DejaGNU test suite. You can find info about DejaGNU at http://www.gnu.org/software/dejagnu. There is also info about testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC OK, thanks. I finished about x86_64 testsuite, and also tried microblaze testsuite under x86_64 machine, but failed. Do I need any additional information for microblaze testsuite? I run tests using these options: -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a Configuring DejaGNU for cross-target testing requires creating a configuration file describing the target board. Rather than the standard "make check-gcc" described on the wiki page and elsewhere, I use a script which sets some configuration options and executes runtest directly. This uses a MicroBlaze processor simulator called vpexec which was included with an older version of Xilinx's EDK. Xilinx no longer supports vpexec. You can use a hardware target board to test microblaze-gcc, or a different simulator such as QEMU. OK, thanks, I shall try Qemu (it is the additional chance for me to familiar with Qemu). And do you mean I need try testsuite under the related microblaze host ( e.g. Qemu microblaze simulator)? After finish environments construction, I shall also try to test a patch for "((void (*)(void)) 0)()" fixing. Thanks. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/15/14 15:53, Chen Gang wrote:
On 09/15/2014 11:30 PM, Michael Eager wrote:
Configuring DejaGNU for cross-target testing requires creating a configuration
file describing the target board.
OK, thank you very much. And could you share your configuration file,
which I can reference to?
See attached.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
# Xilinx remote for MicroBlaze using XMD
#load_generic_config "monitor"
load_generic_config "xmd"
# Identify multilib flags using libgloss
process_multilib_options ""
# The default compiler for this target.
set_board_info compiler "mb-gcc"
# We will be using the standard GDB remote protocol
set_board_info gdb_protocol "remote"
# Name of the computer whose socket will be used, if required.
#set_board_info sockethost "gdb"
set_board_info sockethost "localhost"
# Port ID to use for socket connection
set_board_info gdb,socketport "1234"
# Port for target
#set_board_info netport "gdb:1234"
set_board_info netport "localhost:1234"
# Use techniques appropriate to a stub (don't do "run" command)
set_board_info use_gdb_stub 1
# This gdbserver can only run a process once per session.
set_board_info gdb,do_reload_on_run 1
# There's no support for argument-passing (yet).
set_board_info noargs 1
# Can't do input (or output) in the current gdbserver.
set_board_info gdb,noinferiorio 1
# Can't do singnals
set_board_info gdb,nosignals 1
# Can't do hardware watchpoints, in general
set_board_info gdb,no_hardware_watchpoints 1
#set_board_info cflags "[newlib_include_flags] [libgloss_include_flags]"
set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
set_board_info addl_link_flags "-L /home/eager/Xilinx/dg/microblaze_0/lib
-Wl,-defsym -Wl,_HEAP_SIZE=0x100 -Wl,-defsym -Wl,_STACK_SIZE=0x8"
set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] [board_info
$board addl_link_flags]"
# Use remote protocol to XMD server
load_config "monitor.exp"
proc set_host_info { entry value } {
global target_info board_info
verbose "set_host_info $entry $value" 3
set machine host
if [info exists target_info($machine,name)] {
set machine $target_info($machine,name)
}
set board_info($machine,$entry) $value
}
proc gdb_target_exec { } {
send_gdb "cont"
#gdb_test "target exec" "No executable file now." "" ".*Kill it.*y or n.*"
"y"
}
proc remote_reboot { host } {
}
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/20/14 08:52, Chen Gang wrote:
Thank you very much for your attachments, it is very useful to me!
I tried testsuite for microblaze cross target on x86_64 host, it says
OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
that my configuration is incorrect), please help check, thanks.
Welcome to the joys of DejaGNU. Configuration can be confusing.
As you can see, the return code is not useful.
dejagnu configuration:
cp xmd.exp /usr/local/share/dejagnu/config/
cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
vi microblaze-xilinx-gdb.exp
"s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
gcc operation:
../gcc/configure --target=microblaze-gchen-linux --disable-nls
--enable-languages=c --disable-threads --disable-shared \
--without-headers --disable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic
make
make -k check-gcc
RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
Check whether these compiler options are being passed to mb-gcc. There is a
line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
This is likely overriding any options passed to runtest.
Make sure that the options match the features of your target board. You might
not need any options for your initial tests.
Make sure that the correct flags are being passed to the linker.
Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
You might want to limit the number of tests run until you get problems worked
out:
make check-gcc RUNTESTFLAGS="execute.exp -v -v
--target_board=microblaze-xilinx-gdb"
This will run only the gcc.c-torture/execute/execute.exp tests.
gcc result:
=== gcc Summary ===
# of expected passes 48408
# of unexpected failures 17253
# of unexpected successes 1
# of expected failures97
# of unresolved testcases 16570
# of unsupported tests1854
/upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)
Look at gcc.sum and gcc.log to find out what is causing the large number of
unexpected failures. A large number of unresolved test cases often means that
the compiler returned an error.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/20/14 23:24, Chen Gang wrote: And it seems, we also need 'LinkScr.ld' for ldscript, could you share it to me, thanks. set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld" Hi Chen -- The DejaGNU configuration I provided is for a bare-metal environment. If you are testing in a Linux environment, the tool chain you uses should provide a default linker script which matches your hardware's memory layout. You should not need to provide a separate linker script. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/21/14 03:46, Chen Gang wrote: Excuse me, I want to consult one thing: I installed raw microblaze cross compiler, binutils and glibc into one directory (/upstream/release), and try to build a "Hello world" C program for microblaze under x86_64 host. I guess it is OK, but I am not quite sure about it (I use raw compiler, and have to point out "/upstream/release/lib/ld.so.1" explicitly, and receive a warning related with 'ld'). Is it really OK? can I still use raw compiler for our testsuite? Is 'LinkScr.ld' for ldscript related with current case? [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 1180 Generally, you should use "gcc" to link programs, not "ld". gcc is a driver which will select the appropriate libraries and support routines (such as crt0.o, which contains _start) and pass them to the linker. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/21/14 21:10, Chen Gang wrote: On 9/22/14 2:09, Michael Eager wrote: Generally, you should use "gcc" to link programs, not "ld". gcc is a driver which will select the appropriate libraries and support routines (such as crt0.o, which contains _start) and pass them to the linker. OK, thanks. When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g. "/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/ release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o". You likely need to build mb-gcc with --sysroot=/upstream. How are you building gcc? What are your configuration options? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/21/14 20:55, Chen Gang wrote: On 9/22/14 2:03, Michael Eager wrote: On 09/20/14 23:24, Chen Gang wrote: And it seems, we also need 'LinkScr.ld' for ldscript, could you share it to me, thanks. set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld" Hi Chen -- The DejaGNU configuration I provided is for a bare-metal environment. If you are testing in a Linux environment, the tool chain you uses should provide a default linker script which matches your hardware's memory layout. You should not need to provide a separate linker script. OK, thanks, I shall try to find the default linker script for it. If you are running mb-gcc which generates executables which run on the target, you do not need to provide a linker script. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/24/14 07:31, Chen Gang wrote: Hello Michael: Firstly, thank you very much for always providing your aid to me for microblaze. At present, after try testsuite, the result is much better than my original trying, please help check the result: "is it enough for our microblaze testsuite" (can we say it pass checking)? Current result: # of expected passes65987 # of unexpected failures82 # of unexpected successes 1 # of expected failures 97 # of unresolved testcases 16378 # of unsupported tests 1810 This is good. Original result: # of expected passes 48408 # of unexpected failures 17253 # of unexpected successes 1 # of expected failures97 # of unresolved testcases 16570 # of unsupported tests1854 After check the current result log, I find many remote target test related sentences, do we have to process it? e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory." The test suite uses rcp to transfer files to or from the target, either to provide input to a test case or to check the output. Most Linux systems do not install rcp, since it is a security risk. And I guess, it is a glibc bug: which still add root directory (e.g. /upstream/release) in 'libc.so' when already has --with-sysroot for configure. Oh, sorry, glibc should also need --with-sysroot. I shall try it today, hope it will let all things OK. After add --with-sysroot for glibc, this issue is still existance. And I remove the redundant direcltory manually for libc.so and libpthread.so. If our microblaze testsuite is OK, I will skip this issue (since I have no enough time resource on glibc, at present). OK with me. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/24/14 09:23, Chen Gang wrote:
On 09/24/2014 11:37 PM, Mike Stump wrote:
On Sep 24, 2014, at 8:28 AM, Michael Eager wrote:
After check the current result log, I find many remote target test
related sentences, do we have to process it?
e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such
file or directory."
The test suite uses rcp to transfer files to or from the target,
either to provide input to a test case or to check the output.
Most Linux systems do not install rcp, since it is a security risk.
To clarify:
if {[board_info $desthost exists rcp_prog]} {
set RCP [board_info $desthost rcp_prog]
} else {
set RCP rcp
}
So, if you set rcp_prog to something else, you should be able to avoid rsh if
you want. Most people use ssh now-a-days. You will want it set up to not
require a password for testing.
OK, thank you for your information.
For one simple solving way under fedora: "yum install rsh", and I will
get another issue:
"Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown
host"
So I guess the root cause is: I only use cross-compiling environments
under fedora x86_64, no any real or virtual target for test.
You can see the command which is getting the error by looking at gcc.log.
If the command is not displayed, add another "-v" (or two) to RUNTESTFLAGS.
If I recall correctly, DejaGNU is executing a command like "rcp file
microblaze-xilinx-gdb".
This means that you need to have the name microblaze-xilinx-gdb resolved into
an IP address.
This can be done by adding it to /etc/hosts. Or you can specify the target IP
address
in the DejaGNU options. I don't recall which one off the top of my head.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use VOID instead of SI to fix "((void (*)(void)) 0)()" issue
On 09/25/14 07:03, Chen Gang wrote: Need use VOID instead of SI, or when real VOIDmode comes, it does not match SImode, so cause issue. This patch can fix this issue and pass testsuite. Did you forget to attach the patch? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use VOID instead of SI to fix "((void (*)(void)) 0)()" issue
On 09/25/14 10:38, Michael Eager wrote: On 09/25/14 07:03, Chen Gang wrote: Need use VOID instead of SI, or when real VOIDmode comes, it does not match SImode, so cause issue. This patch can fix this issue and pass testsuite. Did you forget to attach the patch? Never mind. My eyes were playing tricks on me. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use VOID instead of SI to fix "((void (*)(void)) 0)()" issue
On 09/25/14 07:03, Chen Gang wrote:
Need use VOID instead of SI, or when real VOIDmode comes, it does not
match SImode, so cause issue. This patch can fix this issue and pass
testsuite.
The related test code ('void' will cause CALL instead of SET):
typedef void (*T)(void);
f1 ()
{
((T) 0)();
}
The related error:
[root@localhost gcc]# ./cc1 /tmp/calls.c -o /tmp/1.s
f1
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
f1
/tmp/calls.c: In function 'f1':
/tmp/calls.c:5:1: error: unrecognizable insn:
}
^
(call_insn 5 2 8 2 (parallel [
(call (mem:SI (const_int 0 [0]) [0 MEM[(void (*)
(void))0B] S4 A32])
(const_int 24 [0x18]))
(clobber (reg:SI 15 r15))
]) /tmp/calls.c:4 -1
(nil)
(nil))
/tmp/calls.c:5:1: internal compiler error: in extract_insn, at recog.c:2204
0xb0e71b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0xb0e75c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:117
0xac552b extract_insn(rtx_def*)
../../gcc/gcc/recog.c:2204
0x8b919e instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1614
0x8ba347 instantiate_virtual_regs
../../gcc/gcc/function.c:1934
0x8ba452 execute
../../gcc/gcc/function.c:1983
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Is this test case (or a similar one) in the gcc test suite?
If not, can you please add it to the test suite.
2014-09-25 Chen Gang
* config/microblaze/microblaze.md (call_internal1): Use VOID
instead of SI to fix "((void (*)(void)) 0)()" issue
---
gcc/config/microblaze/microblaze.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/microblaze/microblaze.md
b/gcc/config/microblaze/microblaze.md
index b971737..3b4faf4 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2062,7 +2062,7 @@
(set_attr "length""4")])
(define_insn "call_internal1"
- [(call (mem (match_operand:SI 0 "call_insn_simple_operand" "ri"))
+ [(call (mem (match_operand:VOID 0 "call_insn_simple_operand" "ri"))
(match_operand:SI 1 "" "i"))
(clobber (reg:SI R_SR))]
""
I've verified that your patch does not cause any test suite regressions.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] microblaze: microblaze.md: Use VOID instead of SI to fix "((void (*)(void)) 0)()" issue
On 09/25/14 07:03, Chen Gang wrote: 2014-09-25 Chen Gang gcc: * config/microblaze/microblaze.md (call_internal1): Use VOID instead of SI to fix "((void (*)(void)) 0)()" issue gcc/testsuite/: 2014-09-28 Chen Gang * gcc.c-torture/compile/calls-void.c: New test. Committed revision 215684. Thanks for adding the test case. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 07/14/13 21:37, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Saturday, 13 July 2013 9:33 am To: David Holsgrove Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. I had sent a separate patch which should have been applied prior to this one which extended the jump insn to accommodate branching without the "%l" print operand, but I've since reworked our thunk support to avoid needing this second patch. When that patch was not accepted, I moved on to the next submission. Please make sure that patches identify that they are dependent on previous patches. Thanks for reworking the patch to be independent. I'll post updated patches on the other threads out for review now. Thanks. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add -fstack-usage support
On 03/18/13 05:48, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c (microblaze_expand_prologue): Add check for flag_stack_usage to handle -fstack-usage support Signed-off-by: David Holsgrove Applied revision 201035. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add -fstack-usage support
On 07/18/13 16:25, David Holsgrove wrote: On 19 July 2013 02:42, Michael Eager wrote: On 03/18/13 05:48, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c (microblaze_expand_prologue): Add check for flag_stack_usage to handle -fstack-usage support Signed-off-by: David Holsgrove Applied revision 201035. Thanks Michael - did this get applied to trunk? I can't see the commit upstream. Not sure what happened before, but it did not get committed. Committed revision 201042. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 07/14/13 21:37, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Saturday, 13 July 2013 9:33 am To: David Holsgrove Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. I had sent a separate patch which should have been applied prior to this one which extended the jump insn to accommodate branching without the "%l" print operand, but I've since reworked our thunk support to avoid needing this second patch. Please find attached updated patch, and new Changelog entry; 2013-07-15 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK I'll post updated patches on the other threads out for review now. thanks, David Committed revision 201185. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add -fstack-usage support
On 07/22/13 22:50, David Holsgrove wrote: Hi Eric / Chung-Ju, On 21 July 2013 01:33, Chung-Ju Wu wrote: On 7/20/13 4:14 PM, Eric Botcazou wrote: 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c (microblaze_expand_prologue): Add check for flag_stack_usage to handle -fstack-usage support Signed-off-by: David Holsgrove Patch remains the same, please apply when ready. The patch is incorrect, please adjust it to match the other architectures. Hi, David, Specifically speaking, what Eric meant is to check flag_stack_usage_info rather than flag_stack_usage due to the changes after gcc-4.7. Ah, thanks for the catch - patch had been sitting in my tree for quite a while, hadn't realised the variable name had changed on trunk. Patch attached which adjusts microblaze's usage to align with other archs. Committed revision 201186. Please send an updated ChangeLog when it is different from the original. ChangeLog: 2013-07-23 David Holsgrove * config/microblaze/microblaze.c (microblaze_expand_prologue): Rename flag_stack_usage to flag_stack_usage_info. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add atomic builtin implementation
On 07/14/13 21:43, David Holsgrove wrote: Hi Michael, On 21 March 2013 03:00, Richard Henderson wrote: On 03/18/2013 05:48 AM, David Holsgrove wrote: * gcc/config/microblaze/sync.md: New file. * gcc/config/microblaze/microblaze.md: Add UNSPEC_SYNC_CAS, UNSPEC_SYNC_XCHG and include sync.md. * gcc/config/microblaze/microblaze.c: Add print_operand 'y'. * gcc/config/microblaze/constraints.md: Add memory_contraint 'Q' which is a single register. Do not add new __sync implementations. Use the __atomic builtins. r~ Please find attached reworked patch using __atomic builtin. Changelog entry would be; 2013-07-15 David Holsgrove * gcc/config/microblaze/sync.md: New file. * gcc/config/microblaze/microblaze.md: Include sync.md * gcc/config/microblaze/microblaze.c: Add print_operand 'y'. * gcc/config/microblaze/constraints.md: Add memory_contraint 'Q' which is a single register. thanks, David Committed revision 201185. ChangeLog corrected: revision 201200 -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 07/23/13 16:23, David Holsgrove wrote: On 24 July 2013 07:10, Michael Eager wrote: On 07/14/13 21:37, David Holsgrove wrote: Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Saturday, 13 July 2013 9:33 am To: David Holsgrove Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. I had sent a separate patch which should have been applied prior to this one which extended the jump insn to accommodate branching without the "%l" print operand, but I've since reworked our thunk support to avoid needing this second patch. Please find attached updated patch, and new Changelog entry; 2013-07-15 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK I'll post updated patches on the other threads out for review now. thanks, David Committed revision 201185. Thanks Michael. I think the content of your commit doesnt line up with this Changelog entry or mail though, http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c4fcbf4cd03c11aa1bc707b00dd95ba52f963b39 It looks like the atomic builtin patch which was posted as this mail; http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00551.html Yes, I picked up the wrong ChangeLog and email. I fixed the ChangeLog. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] Enable non-complex math builtins from C99 for Bionic
On 07/27/13 15:18, Alexander Ivchenko wrote: Hi Joseph, thanks for your comments. I updated the patch: 2013/7/9 Joseph S. Myers : * It looks rather like microblaze*-*-* don't use elfos.h, so meaning semantics aren't preserved for those (non-Linux) targets either. Now, I don't know if there's a good reason for not using that file (ask the architecture maintainer), but in any case semantics should be preserved. I don't know why microblaze does not include elfos.h. It looks like it should, to be consistent with other targets. This would require some cleanup and verification. Your patch adds the following to microblaze.h, duplicating the change to elfos.h: +/* microblaze-unknown-elf target has no support of C99 runtime */ +#undef TARGET_LIBC_HAS_FUNCTION +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function I'm assuming that this means that no other change to microblaze is needed and the question about elfos.h is moot. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add support for swap instructions and reorder option
On 02/10/2013 10:39 PM, David Holsgrove wrote:
Add support for swap instructions and reorder option
swapb and swaph instructions are introduced in microblaze cpu (mcpu) v8.30a,
but have an undocumented dependence on -mxl-pattern-compare being set.
The conditions for their use are;
mcpu < 8.30a; no swap insns, use of -mxl-reorder produces warning
and ignored
mcpu == 8.30a and -mxl-pattern-compare specified;
and if -mno-xl-reorder not specified, then swap insns allowed
mcpu > 8.30a;
if -mno-xl-reorder not specified, then swap insns allowed
Changelog
2013-02-11 David Holsgrove
Is this correct?
* config/microblaze/microblaze.c: microblaze_has_swap = 0
Add version check for v8.30.a to enable microblaze_has_swap
* config/microblaze/microblaze.h: Add TARGET_HAS_SWAP
* config/microblaze/microblaze.md: New bswapsi2 and bswaphi2
instructions
* config/microblaze/microblaze.opt: New options -mxl-reorder
and -mno-xl-reorder
Don't specify both -mxl-reorder and -mno-xl-reorder as options.
Don't specify a "no" version with the RejectNegative option.
GCC option handling already process the "no" prefix automatically.
There is no need to have both TARGET_REORDER and TARGET_NOREORDER
since they have exactly the same information. Define only TARGET_REORDER.
How does the name of the option (-mxl-reorder) relate to using swap
instructions? Nothing is being reordered. What are "reorder" instructions?
How about -mxl-swap, similar to -mxl-pattern-compare or -mxl-float-sqrt?
+ else if (ver == 0)
+{
+if (!TARGET_NO_REORDER)
+ {
+target_flags |= MASK_REORDER;
+/* MicroBlaze v8.30a has an undocumented dependency on
+ pattern compare for swapb / swaph insns. */
+if (TARGET_PATTERN_COMPARE)
+ microblaze_has_swap = 1;
+ }
+}
+ else
+{
+if (!TARGET_NO_REORDER)
+ {
+target_flags |= MASK_REORDER;
+/* Microblaze versions greater than v8.30a will be able to use
+ swapb / swaph without pattern compare */
+microblaze_has_swap = 1;
+ }
+}
+
Refactor to eliminate duplicated code.
Why set the MASK_REORDER flag in target_flags if this is never used?
Options processing will set this automatically since you have
mxl-reorder
Target RejectNegative Mask(REORDER)
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
