[gcc r15-1866] Fortran: switch test to use issignaling() built-in
https://gcc.gnu.org/g:eec30733bba305b02ba3c368289ef935f17c87e6
commit r15-1866-geec30733bba305b02ba3c368289ef935f17c87e6
Author: Francois-Xavier Coudert
Date: Sat Jul 6 00:02:03 2024 +0200
Fortran: switch test to use issignaling() built-in
The macro may not be present in all libc's, but the built-in
is always available.
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/signaling_2.f90: Adjust test.
* gfortran.dg/ieee/signaling_2_c.c: Adjust test.
Diff:
---
gcc/testsuite/gfortran.dg/ieee/signaling_2.f90 | 3 ---
gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c | 10 +++---
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/ieee/signaling_2.f90
b/gcc/testsuite/gfortran.dg/ieee/signaling_2.f90
index 03b04c783eb..79a85edefd1 100644
--- a/gcc/testsuite/gfortran.dg/ieee/signaling_2.f90
+++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2.f90
@@ -1,9 +1,6 @@
! { dg-do run { target { ! ia32 } } }
! x87 / x86-32 ABI is unsuitable for signaling NaNs
!
-! { dg-require-effective-target issignaling } */
-! The companion C source needs access to the issignaling macro.
-!
! { dg-additional-sources signaling_2_c.c }
! { dg-additional-options "-w" }
! The -w option is needed to make cc1 not report a warning for
diff --git a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
index ea7fc0467bd..dde09638c6f 100644
--- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
+++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
@@ -1,8 +1,4 @@
-#define _GNU_SOURCE
-#include
-#include
-
-int isnansf (float x) { return issignaling (x) ? 1 : 0; }
-int isnans (double x) { return issignaling (x) ? 1 : 0; }
-int isnansl (long double x) { return issignaling (x) ? 1 : 0; }
+int isnansf (float x) { return __builtin_issignaling (x) ? 1 : 0; }
+int isnans (double x) { return __builtin_issignaling (x) ? 1 : 0; }
+int isnansl (long double x) { return __builtin_issignaling (x) ? 1 : 0; }
[gcc r15-1697] fixincludes: adjust stdio fix for macOS 15 headers
https://gcc.gnu.org/g:1dc143181550573c9c902fb7a3b495e9b409d0b0
commit r15-1697-g1dc143181550573c9c902fb7a3b495e9b409d0b0
Author: Francois-Xavier Coudert
Date: Thu Jun 27 18:55:22 2024 +0200
fixincludes: adjust stdio fix for macOS 15 headers
fixincludes/ChangeLog:
* fixincl.x: Regenerate.
* inclhack.def (apple_local_stdio_fn_deprecation): Also apply to
_stdio.h.
Diff:
---
fixincludes/fixincl.x| 6 +++---
fixincludes/inclhack.def | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index 54a530b50ca..fb9950d9b21 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed June 7, 2024 at 11:03:58 AM by AutoGen 5.18.16
+ * It has been AutoGen-ed June 27, 2024 at 06:52:39 PM by AutoGen 5.18.16
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Fri Jun 7 11:03:58 CEST 2024
+/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Jun 27 18:52:39 CEST 2024
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -2619,7 +2619,7 @@ tSCC zApple_Local_Stdio_Fn_DeprecationName[] =
* File name selection pattern
*/
tSCC zApple_Local_Stdio_Fn_DeprecationList[] =
- "stdio.h\0";
+ "stdio.h\0_stdio.h\0";
/*
* Machine/OS name selection pattern
*/
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index f7fc5cdbabd..9f4a41199a1 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1273,6 +1273,7 @@ fix = {
hackname = apple_local_stdio_fn_deprecation;
mach = "*-*-*darwin2*";
files = stdio.h;
+files = _stdio.h;
select= "__deprecated_msg([^\n]*)$";
c_fix = format;
c_fix_arg = "#if defined(__APPLE_LOCAL_DEPRECATIONS)\n"
[gcc r15-1173] fixincludes: bypass the math_exception fix on __cplusplus
https://gcc.gnu.org/g:66d6b1861ec57ba29540a5fa7854df3978ba5409
commit r15-1173-g66d6b1861ec57ba29540a5fa7854df3978ba5409
Author: Francois-Xavier Coudert
Date: Fri Jun 7 11:05:39 2024 +0200
fixincludes: bypass the math_exception fix on __cplusplus
fixincludes/ChangeLog:
* fixincl.x: Regenerate.
* inclhack.def (math_exception): Bypass on __cplusplus.
* tests/base/math.h: Regenerate.
Diff:
---
fixincludes/fixincl.x | 12 +---
fixincludes/inclhack.def | 12 +---
fixincludes/tests/base/math.h | 11 ---
3 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index caaff2883e0..54a530b50ca 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed June 4, 2024 at 02:35:55 PM by AutoGen 5.18.16
+ * It has been AutoGen-ed June 7, 2024 at 11:03:58 AM by AutoGen 5.18.16
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Jun 4 14:35:55 CEST 2024
+/* DO NOT SVN-MERGE THIS FILE, EITHER Fri Jun 7 11:03:58 CEST 2024
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -6793,9 +6793,7 @@ tSCC zMath_ExceptionList[] =
/*
* Machine/OS name selection pattern
*/
-tSCC* apzMath_ExceptionMachs[] = {
-"*-*-solaris2.1[0-9]*",
-(const char*)NULL };
+#define apzMath_ExceptionMachs (const char**)NULL
/*
* content selection pattern - do fix if pattern found
@@ -6807,7 +6805,7 @@ tSCC zMath_ExceptionSelect0[] =
* content bypass pattern - skip fix if pattern found
*/
tSCC zMath_ExceptionBypass0[] =
- "We have a problem when using C\\+\\+|for C\\+\\+,
_[a-z0-9A-Z_]+_exception; for C, exception";
+ "__cplusplus";
#defineMATH_EXCEPTION_TEST_CT 2
static tTestDesc aMath_ExceptionTests[] = {
@@ -12304,7 +12302,7 @@ tFixDesc fixDescList[ FIX_COUNT ] = {
{ zMath_ExceptionName,zMath_ExceptionList,
apzMath_ExceptionMachs,
- MATH_EXCEPTION_TEST_CT, FD_MACH_IFNOT | FD_SUBROUTINE,
+ MATH_EXCEPTION_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
aMath_ExceptionTests, apzMath_ExceptionPatch, 0 },
{ zMath_Huge_Val_From_Dbl_MaxName,zMath_Huge_Val_From_Dbl_MaxList,
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 35402d0621c..f7fc5cdbabd 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -3412,17 +3412,7 @@ fix = {
hackname = math_exception;
files = math.h;
select= "struct exception";
-/*
- * This should be bypassed on __cplusplus, but some supposedly C++
- * aware headers, such as Solaris 8 and 9, don't wrap their struct
- * exception either. So currently we bypass only for glibc, based on a
- * comment in the fixed glibc header. Ick.
- */
-bypass= 'We have a problem when using C\+\+|for C\+\+, '
- '_[a-z0-9A-Z_]+_exception; for C, exception';
-/* The Solaris 10 headers already get this right. */
-mach = '*-*-solaris2.1[0-9]*';
-not_machine = true;
+bypass= '__cplusplus';
c_fix = wrap;
c_fix_arg = "#ifdef __cplusplus\n"
diff --git a/fixincludes/tests/base/math.h b/fixincludes/tests/base/math.h
index 7b92f29a409..3c378c5df95 100644
--- a/fixincludes/tests/base/math.h
+++ b/fixincludes/tests/base/math.h
@@ -7,12 +7,6 @@
This had to be done to correct non-standard usages in the
original, manufacturer supplied header file. */
-#ifndef FIXINC_WRAP_MATH_H_MATH_EXCEPTION
-#define FIXINC_WRAP_MATH_H_MATH_EXCEPTION 1
-
-#ifdef __cplusplus
-#define exception __math_exception
-#endif
#if defined( BROKEN_CABS_CHECK )
@@ -146,8 +140,3 @@ int foo;
#endif /* _C99 */
#endif /* VXWORKS_MATH_H_FP_C99_CHECK */
-#ifdef __cplusplus
-#undef exception
-#endif
-
-#endif /* FIXINC_WRAP_MATH_H_MATH_EXCEPTION */
[gcc r15-1095] fixincludes: bypass some fixes for recent darwin headers
https://gcc.gnu.org/g:e4f1c1be61d916345655d5edba309502046c9473
commit r15-1095-ge4f1c1be61d916345655d5edba309502046c9473
Author: Francois-Xavier Coudert
Date: Sun Jun 2 21:07:23 2024 +0200
fixincludes: bypass some fixes for recent darwin headers
fixincludes/ChangeLog:
* fixincl.x: Regenerate.
* inclhack.def (darwin_stdint_7, darwin_dispatch_object_1,
darwin_os_trace_2, darwin_os_base_1): Include bypasses
for recent headers, fixed by Apple.
Diff:
---
fixincludes/fixincl.x| 42 +++---
fixincludes/inclhack.def | 4
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index e52f11d8460..caaff2883e0 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed August 17, 2023 at 10:16:38 AM by AutoGen 5.18.12
+ * It has been AutoGen-ed June 4, 2024 at 02:35:55 PM by AutoGen 5.18.16
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Aug 17 10:16:38 CEST 2023
+/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Jun 4 14:35:55 CEST 2024
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -3070,8 +3070,15 @@ tSCC* apzDarwin_Os_Trace_2Machs[] = {
tSCC zDarwin_Os_Trace_2Select0[] =
"typedef.*\\^os_trace_payload_t.*";
-#defineDARWIN_OS_TRACE_2_TEST_CT 1
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zDarwin_Os_Trace_2Bypass0[] =
+ "#ifdef __BLOCKS__";
+
+#defineDARWIN_OS_TRACE_2_TEST_CT 2
static tTestDesc aDarwin_Os_Trace_2Tests[] = {
+ { TT_NEGREP, zDarwin_Os_Trace_2Bypass0, (regex_t*)NULL },
{ TT_EGREP,zDarwin_Os_Trace_2Select0, (regex_t*)NULL }, };
/*
@@ -3199,8 +3206,15 @@ tSCC zDarwin_Os_Base_1Select0[] =
"#define __has_attribute.*\n\
#endif";
-#defineDARWIN_OS_BASE_1_TEST_CT 1
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zDarwin_Os_Base_1Bypass0[] =
+ "#define __has_extension";
+
+#defineDARWIN_OS_BASE_1_TEST_CT 2
static tTestDesc aDarwin_Os_Base_1Tests[] = {
+ { TT_NEGREP, zDarwin_Os_Base_1Bypass0, (regex_t*)NULL },
{ TT_EGREP,zDarwin_Os_Base_1Select0, (regex_t*)NULL }, };
/*
@@ -3239,8 +3253,15 @@ tSCC* apzDarwin_Dispatch_Object_1Machs[] = {
tSCC zDarwin_Dispatch_Object_1Select0[] =
"typedef void.*\\^dispatch_block_t.*";
-#defineDARWIN_DISPATCH_OBJECT_1_TEST_CT 1
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zDarwin_Dispatch_Object_1Bypass0[] =
+ "#ifdef __BLOCKS__";
+
+#defineDARWIN_DISPATCH_OBJECT_1_TEST_CT 2
static tTestDesc aDarwin_Dispatch_Object_1Tests[] = {
+ { TT_NEGREP, zDarwin_Dispatch_Object_1Bypass0, (regex_t*)NULL },
{ TT_EGREP,zDarwin_Dispatch_Object_1Select0, (regex_t*)NULL }, };
/*
@@ -3591,8 +3612,15 @@ tSCC zDarwin_Stdint_7Select0[] =
"#define INTMAX_C\\(v\\)[ \t]+\\(v ## LL\\)\n\
#define UINTMAX_C\\(v\\)[ \t]+\\(v ## ULL\\)";
-#defineDARWIN_STDINT_7_TEST_CT 1
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zDarwin_Stdint_7Bypass0[] =
+ "#ifdef __LP64__";
+
+#defineDARWIN_STDINT_7_TEST_CT 2
static tTestDesc aDarwin_Stdint_7Tests[] = {
+ { TT_NEGREP, zDarwin_Stdint_7Bypass0, (regex_t*)NULL },
{ TT_EGREP,zDarwin_Stdint_7Select0, (regex_t*)NULL }, };
/*
@@ -11169,7 +11197,7 @@ static const char* apzX11_SprintfPatch[] = {
*
* List of all fixes
*/
-#define REGEX_COUNT 313
+#define REGEX_COUNT 317
#define MACH_LIST_SIZE_LIMIT 187
#define FIX_COUNT274
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 19e0ea2df66..35402d0621c 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1486,6 +1486,7 @@ fix = {
mach = "*-*-darwin*";
files = os/trace.h;
select= "typedef.*\\^os_trace_payload_t.*";
+ bypass= "#ifdef __BLOCKS__";
c_fix = format;
c_fix_arg = "#if __BLOCKS__\n%0\n#endif";
test_text = "typedef void (^os_trace_payload_t)(xpc_object_t xdict);";
@@ -1566,6 +1567,7 @@ fix = {
#define __has_attribute.*
#endif
OS_BASE_1_SEL;
+ bypass= "#define __has_extension";
c_fix = format;
c_fix_arg = <<- OS_BASE_1_FIX
%0
@@ -1589,6 +1591,7 @@ fix = {
mach = "*-*-darwin*";
files = dispatch/object.h;
select= "typedef void.*\\^dispatch_block_t.*";
+ bypass= "#ifdef __BLOCKS__";
c_fix = format;
c_fix_arg = "#if __BLOCKS__\n%0\n#endif";
test_text = <<- DISPATCH_OBJECT_1_TEST
@@ -1791,6 +1794,7 @@ fix = {
"#endif";
select= "#define INTMAX_C\\(v\\)[ \t]+\\(v ## LL\\)\n"
"#define UINTMAX_C\\(v\\)[ \t]+\\(v ## ULL\\)";
+bypass = '#ifdef __LP64__';
test_text = "#define INTMAX_C(v) (v ## LL)\n"
[gcc r15-50] Fortran: add F2023 ISO_FORTRAN_ENV named constants
https://gcc.gnu.org/g:1dba1d860a1e3e32e5d061a1d6dc600c96d2597f
commit r15-50-g1dba1d860a1e3e32e5d061a1d6dc600c96d2597f
Author: Francois-Xavier Coudert
Date: Tue Mar 19 14:16:38 2024 +0100
Fortran: add F2023 ISO_FORTRAN_ENV named constants
gcc/fortran/ChangeLog:
* iso-fortran-env.def: Add logical{8,16,32,64} and
real16 named constants.
gcc/testsuite/ChangeLog:
* gfortran.dg/iso_fortran_env_8.f90: New test.
* gfortran.dg/iso_fortran_env_9.f90: New test.
Diff:
---
gcc/fortran/iso-fortran-env.def | 10
gcc/testsuite/gfortran.dg/iso_fortran_env_8.f90 | 32 +
gcc/testsuite/gfortran.dg/iso_fortran_env_9.f90 | 29 ++
3 files changed, 71 insertions(+)
diff --git a/gcc/fortran/iso-fortran-env.def b/gcc/fortran/iso-fortran-env.def
index ed7946a2594..069bbc1fb86 100644
--- a/gcc/fortran/iso-fortran-env.def
+++ b/gcc/fortran/iso-fortran-env.def
@@ -68,10 +68,20 @@ NAMED_INTCST (ISOFORTRANENV_IOSTAT_EOR, "iostat_eor",
LIBERROR_EOR, \
NAMED_INTCST (ISOFORTRANENV_IOSTAT_INQUIRE_INTERNAL_UNIT, \
"iostat_inquire_internal_unit", LIBERROR_INQUIRE_INTERNAL_UNIT, \
GFC_STD_F2008)
+NAMED_INTCST (ISOFORTRANENV_LOGICAL8, "logical8", \
+ gfc_get_int_kind_from_width_isofortranenv (8), GFC_STD_F2023)
+NAMED_INTCST (ISOFORTRANENV_LOGICAL16, "logical16", \
+ gfc_get_int_kind_from_width_isofortranenv (16), GFC_STD_F2023)
+NAMED_INTCST (ISOFORTRANENV_LOGICAL32, "logical32", \
+ gfc_get_int_kind_from_width_isofortranenv (32), GFC_STD_F2023)
+NAMED_INTCST (ISOFORTRANENV_LOGICAL64, "logical64", \
+ gfc_get_int_kind_from_width_isofortranenv (64), GFC_STD_F2023)
NAMED_INTCST (ISOFORTRANENV_NUMERIC_STORAGE_SIZE, "numeric_storage_size", \
gfc_numeric_storage_size, GFC_STD_F2003)
NAMED_INTCST (ISOFORTRANENV_OUTPUT_UNIT, "output_unit",
GFC_STDOUT_UNIT_NUMBER, \
GFC_STD_F2003)
+NAMED_INTCST (ISOFORTRANENV_REAL16, "real16", \
+ gfc_get_real_kind_from_width_isofortranenv (16), GFC_STD_F2023)
NAMED_INTCST (ISOFORTRANENV_REAL32, "real32", \
gfc_get_real_kind_from_width_isofortranenv (32), GFC_STD_F2008)
NAMED_INTCST (ISOFORTRANENV_REAL64, "real64", \
diff --git a/gcc/testsuite/gfortran.dg/iso_fortran_env_8.f90
b/gcc/testsuite/gfortran.dg/iso_fortran_env_8.f90
new file mode 100644
index 000..d3661b3b592
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/iso_fortran_env_8.f90
@@ -0,0 +1,32 @@
+! { dg-do run }
+!
+! Check for the new Fortran 2023 ISO_FORTRAN_ENV named constants
+
+program test
+ use iso_fortran_env
+ implicit none
+
+ ! These integer kinds are guaranteed on
+ integer(int8) :: i8
+ integer(int16) :: i16
+ integer(int32) :: i32
+ integer(int64) :: i64
+
+ logical(logical8) :: l8
+ logical(logical16) :: l16
+ logical(logical32) :: l32
+ logical(logical64) :: l64
+
+ ! We do not support REAL16 for now, but check it can
+ ! still be used in specification expressions
+ real(kind=max(real16, real32)) :: x
+
+ if (logical8 /= int8) stop 1
+ if (logical16 /= int16) stop 2
+ if (logical32 /= int32) stop 3
+ if (logical64 /= int64) stop 4
+
+ ! We do not support REAL16 for now
+ if (real16 /= -2) stop 101
+
+end program test
diff --git a/gcc/testsuite/gfortran.dg/iso_fortran_env_9.f90
b/gcc/testsuite/gfortran.dg/iso_fortran_env_9.f90
new file mode 100644
index 000..ffd70b23159
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/iso_fortran_env_9.f90
@@ -0,0 +1,29 @@
+! { dg-do compile }
+! { dg-options "-std=f2018" }
+!
+! Check diagnostics for new F2023 named constants
+! in ISO_FORTRAN_ENV
+!
+
+subroutine foo
+ use iso_fortran_env
+ implicit none
+ logical(kind=logical8) :: x ! { dg-error "has no IMPLICIT type" }
+end subroutine
+
+subroutine bar
+ use iso_fortran_env, only : logical8 ! { dg-error "not in the selected
standard" }
+ use iso_fortran_env, only : logical16 ! { dg-error "not in the selected
standard" }
+ use iso_fortran_env, only : logical32 ! { dg-error "not in the selected
standard" }
+ use iso_fortran_env, only : logical64 ! { dg-error "not in the selected
standard" }
+ use iso_fortran_env, only : real16 ! { dg-error "not in the selected
standard" }
+ implicit none
+end subroutine
+
+subroutine gee
+ use iso_fortran_env, only : int8
+ use iso_fortran_env, only : int16
+ use iso_fortran_env, only : int32
+ use iso_fortran_env, only : int64
+ implicit none
+end subroutine
[gcc r14-9937] libgfortran: Fix compilation of gf_vsnprintf
https://gcc.gnu.org/g:3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
commit r14-9937-g3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
Author: Ian McInerney
Date: Thu Apr 4 16:16:32 2024 +0100
libgfortran: Fix compilation of gf_vsnprintf
The fallback function (gf_vsnprintf) to provide a vsnprintf function
if the system library doesn't have one would not compile due to the
variable name for the string's destination buffer not being updated
after the refactor in 2018 in edaaef601d0d6d263fba87b42d6d04c99dd23dba.
This updates the internal logic of gf_vsnprintf to now use the str
variable defined in the function signature.
libgfortran/ChangeLog:
2024-04-04 Ian McInerney
* runtime/error.c (gf_vsnprintf): Fix compilation
Signed-off-by: Ian McInerney
Diff:
---
libgfortran/runtime/error.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libgfortran/runtime/error.c b/libgfortran/runtime/error.c
index e840f539599..044298294d8 100644
--- a/libgfortran/runtime/error.c
+++ b/libgfortran/runtime/error.c
@@ -142,15 +142,15 @@ gf_vsnprintf (char *str, size_t size, const char *format,
va_list ap)
{
int written;
- written = vsprintf(buffer, format, ap);
+ written = vsprintf(str, format, ap);
if (written >= size - 1)
{
- /* The error message was longer than our buffer. Ouch. Because
+ /* The error message was longer than the string size. Ouch. Because
we may have messed up things badly, report the error and
quit. */
-#define ERROR_MESSAGE "Internal error: buffer overrun in gf_vsnprintf()\n"
- write (STDERR_FILENO, buffer, size - 1);
+#define ERROR_MESSAGE "Internal error: string overrun in gf_vsnprintf()\n"
+ write (STDERR_FILENO, str, size - 1);
write (STDERR_FILENO, ERROR_MESSAGE, strlen (ERROR_MESSAGE));
sys_abort ();
#undef ERROR_MESSAGE
[gcc r14-9500] libcc1: fix include
https://gcc.gnu.org/g:5213047b1d50af63dfabb5e5649821a6cb157e33 commit r14-9500-g5213047b1d50af63dfabb5e5649821a6cb157e33 Author: Francois-Xavier Coudert Date: Sat Mar 16 09:50:00 2024 +0100 libcc1: fix include Use INCLUDE_VECTOR before including system.h, instead of directly including , to avoid running into poisoned identifiers. Signed-off-by: Dimitry Andric libcc1/ChangeLog: PR middle-end/111632 * libcc1plugin.cc: Fix include. * libcp1plugin.cc: Fix include. Diff: --- libcc1/libcc1plugin.cc | 3 +-- libcc1/libcp1plugin.cc | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/libcc1/libcc1plugin.cc b/libcc1/libcc1plugin.cc index 72d17c3b81c..e64847466f4 100644 --- a/libcc1/libcc1plugin.cc +++ b/libcc1/libcc1plugin.cc @@ -32,6 +32,7 @@ #undef PACKAGE_VERSION #define INCLUDE_MEMORY +#define INCLUDE_VECTOR #include "gcc-plugin.h" #include "system.h" #include "coretypes.h" @@ -69,8 +70,6 @@ #include "gcc-c-interface.h" #include "context.hh" -#include - using namespace cc1_plugin; diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc index 0eff7c68d29..da68c5d0ac1 100644 --- a/libcc1/libcp1plugin.cc +++ b/libcc1/libcp1plugin.cc @@ -33,6 +33,7 @@ #undef PACKAGE_VERSION #define INCLUDE_MEMORY +#define INCLUDE_VECTOR #include "gcc-plugin.h" #include "system.h" #include "coretypes.h" @@ -71,8 +72,6 @@ #include "rpc.hh" #include "context.hh" -#include - using namespace cc1_plugin;
[gcc r14-9367] testsuite, darwin: improve check for -shared support
https://gcc.gnu.org/g:0ed6e5b4820e01fa86b48a7b1d62f752ec97ea41
commit r14-9367-g0ed6e5b4820e01fa86b48a7b1d62f752ec97ea41
Author: Francois-Xavier Coudert
Date: Thu Mar 7 17:27:17 2024 +0100
testsuite, darwin: improve check for -shared support
The undefined symbols are allowed for C checks, but when
this is run as C++, the mangled foo() symbol is still
seen as undefined, and the testsuite thinks darwin does not
support -shared.
gcc/testsuite/ChangeLog:
PR target/114233
* lib/target-supports.exp: Fix test for C++.
Diff:
---
gcc/testsuite/lib/target-supports.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index ae33c4f1e3a..467b539b20d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1390,7 +1390,7 @@ proc check_effective_target_shared { } {
# here to be undefined.
set extra_flags ""
if { [istarget *-*-darwin\[912\]*] } {
- set extra_flags "-Wl,-U,_foo,-U,_bar"
+ set extra_flags "-Wl,-U,_foo,-U,_bar,-U,__Z3foov"
}
# Note that M68K has a multilib that supports -fpic but not
# -fPIC, so we need to check both. We test with a program that
[gcc r14-9360] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
https://gcc.gnu.org/g:9970b576b7e4ae337af1268395ff221348c4b34a commit r14-9360-g9970b576b7e4ae337af1268395ff221348c4b34a Author: Francois-Xavier Coudert Date: Thu Mar 7 14:36:03 2024 +0100 Include safe-ctype.h after C++ standard headers, to avoid over-poisoning When building gcc's C++ sources against recent libc++, the poisoning of the ctype macros due to including safe-ctype.h before including C++ standard headers such as , , etc, causes many compilation errors, similar to: In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: In file included from /home/dim/src/gcc/master/gcc/system.h:233: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces 546 | _LIBCPP_INLINE_VISIBILITY | ^ /usr/include/c++/v1/__config:813:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY' 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI | ^ /usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI' 792 | __attribute__((__abi_tag__(_LIBCPP_TOSTRING( _LIBCPP_VERSIONED_IDENTIFIER | ^ In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: In file included from /home/dim/src/gcc/master/gcc/system.h:233: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of declaration list 547 | char_type toupper(char_type __c) const | ^ /usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation 553 | const char_type* toupper(char_type* __low, const char_type* __high) const |^ /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype | ^ This is because libc++ uses different transitive includes than libstdc++, and some of those transitive includes pull in various ctype declarations (typically via ). There was already a special case for including before safe-ctype.h, so move the rest of the C++ standard header includes to the same location, to fix the problem. gcc/ChangeLog: * system.h: Include safe-ctype.h after C++ standard headers. Signed-off-by: Dimitry Andric Diff: --- gcc/system.h | 39 ++- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/gcc/system.h b/gcc/system.h index b0edab02885..ab29fc19776 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -194,27 +194,8 @@ extern int fprintf_unlocked (FILE *, const char *, ...); #undef fread_unlocked #undef fwrite_unlocked -/* Include before "safe-ctype.h" to avoid GCC poisoning - the ctype macros through safe-ctype.h */ - -#ifdef __cplusplus -#ifdef INCLUDE_STRING -# include -#endif -#endif - -/* There are an extraordinary number of issues with . - The last straw is that it varies with the locale. Use libiberty's - replacement instead. */ -#include "safe-ctype.h" - -#include - -#include - -#if !defined (errno) && defined (HAVE_DECL_ERRNO) && !HAVE_DECL_ERRNO -extern int errno; -#endif +/* Include C++ standard headers before "safe-ctype.h" to avoid GCC + poisoning the ctype macros through safe-ctype.h */ #ifdef __cplusplus #if defined (INCLUDE_ALGORITHM) || !defined (HAVE_SWAP_IN_UTILITY) @@ -229,6 +210,9 @@ extern int errno; #ifdef INCLUDE_SET # include #endif +#ifdef INCLUDE_STRING +# include +#endif #ifdef INCLUDE_VECTOR # include #endif @@ -245,6 +229,19 @@ extern int errno; # include #endif +/* There are an extraordinary number of issues with . + The last straw is that it varies with the locale. Use libiberty's + replacement instead. */ +#include "safe-ctype.h" + +#include + +#include + +#if !defined (errno) && defined (HAVE_DECL_ERRNO) && !HAVE_DECL_ERRNO +extern int errno; +#endif + /* Some of glibc's string inlines cause warnings. Plus we'd rather rely on (and therefore test) GCC's string builtins. */ #define
Re: Using crlibm as the default math library in GCC sources
Hi Uros, It sounds like a great idea! I'm forwarding this to the Fortran list, because I think it might raise quite some interest there also : http://gcc.gnu.org/ml/gcc/2007-11/msg00164.html FX
i386-linux bootstrap failure
Bootstrap on i386-linux has been broken for a week now, from what I can see. I have reported it as PR33679 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679), but AFAIK noone has reproduced it, as most people now build for i686-linux. Could someone please spare a cycle to confirm this problem? I configure with --enable-languages=c,fortran --build=i386-pc-linux-gnu --enable-checking=release Thanks, FX
Re: [RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor
ping? Gerald, being web pages maintainers, what's your opinion? Answering to Janne's comment, I'm certainly not opposed to any preprocessor/templating system. My own goal is to rewrite the fortran pages, including the common navigation bar, and I can't use MetaHTML to do that. On 9/29/07, FX Coudert [EMAIL PROTECTED] wrote: Hi, I am in the process of rewriting the Fortran part of our website (http://gcc.gnu.org/), part of which consists of adding the GCC navigation bar. To do so, I had to install localy MetaHTML, our current web preprocessor, and my experiences with it have left me less than impressed [1]. We currently use it for including headers and footer, making them depend on whether we are preprocessing HTML or XHTML, modifying in place a few tags (title, h1, body) and adding navigation bar on files that need it. This can easily be done by a simple preprocessing script, and seeing that MetaHTML was last released 1999 and apparently unsupported since then, I suggest that we do this move right now. This patch includes the new preprocessor, changes to the script, and quite a few new files (footer, navigation bars, etc.) split from the MetaHTML file, style.mhtml. I chose to write the preprocessor script in Perl, since Perl is already used for the wwwdocs/bin/preprocess script, so I'm sure it will be available on the webserver. The preprocessor does what MetaHTML was needed, but it can be extended in the future if we need more functionality. Also, we can in the future offload some of its work, such as body and h1 modifications and part of the navigation bar to CSS, which is obviously better suited for the job. I intend to do so as a follow-up to the preprocessor change, if/when it is accepted. This change shouldn't change the website, but I can't check since I don't have MetaHTML, so I'd appreciate if someone with shell access to the webserver could check it. Oh, there is one thing that I changed: the detailled search page, http://gcc.gnu.org/search.html, currently has a Database last updated -MM-DD line that doesn't work (it displays 1900--), so I removed it. Comments are highly welcome, both on the idea itself, and on the Perl script (my Perl is a bit rusty since I haven't used it for years). Thanks, FX [1] As a record, here's what my final status is: in addition to Gerald's patch and script provided by Joel Sherrill (thanks guys), I needed to patch of few more (~ 15) occurences of multilines strings, force the Makefiles to use the version of readline included in metahtml instead of the system one (too recent, apparently there's been an ABI change), and tweak the Makefiles for the shared modules, which aren't portable (at least, not to Mac OS). As of yesterday, I've managed to compile it, but the resulting binary acts as an endless cpu-consuming loop. At that point, I gave up.
Bootstrap broken on mips-sgi-irix6.5
Hi there,
Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE
while compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This
happens, afaict, with any use of the TF mode with either -mabi=64 or
-mabi=n32:
$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF {}
$ /usr/people/francois/devel/ibin/./gcc/cc1 -fpreprocessed foo.i -quiet
zsh: segmentation fault /usr/people/francois/devel/ibin/./gcc/cc1
-fpreprocessed foo.i -quiet
The backtrace for the segfault is:
Program received signal SIGSEGV, Segmentation fault.
0x104d7d50 in reg_classes_intersect_p (c1=32, c2=MD0_REG)
at ../../trunk/gcc/regclass.c:2481
2481{
(gdb) where
#0 0x104d7d50 in reg_classes_intersect_p (c1=32, c2=MD0_REG)
at ../../trunk/gcc/regclass.c:2481
#1 0x102323cc in mips_cannot_change_mode_class (from=TFmode, to=DImode,
class=FP_REGS) at ../../trunk/gcc/config/mips/mips.c:9346
#2 0x10823a38 in simplify_subreg (outermode=DImode, op=0x40b4c80,
innermode=TFmode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5014
#3 0x10824968 in simplify_gen_subreg (outermode=DImode, op=0x40b4c80,
innermode=TFmode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5211
#4 0x1027a700 in operand_subword (op=0x40b4c80, offset=0,
validate_address=1, mode=TFmode) at ../../trunk/gcc/emit-rtl.c:1425
#5 0x1027a76c in operand_subword_force (op=0x40b4c80, offset=0, mode=TFmode)
at ../../trunk/gcc/emit-rtl.c:1438
#6 0x10337484 in emit_move_multi_word (mode=TFmode, x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3275
#7 0x10337980 in emit_move_insn_1 (x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3347
#8 0x10337dc0 in emit_move_insn (x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3407
#9 0x102b4894 in copy_to_reg (x=0x40b4c80) at ../../trunk/gcc/explow.c:617
#10 0x1027a7cc in operand_subword_force (op=0x40b4c80, offset=0, mode=TFmode)
at ../../trunk/gcc/emit-rtl.c:1448
I'm keeping the build tree so that I can investigate more if needed,
please tell me what to do. PR33635 has been opened to keep track of
this problem.
Thanks,
FX
Add a symlink for each branch in online docs
The documentation for different releases of GCC in the same branch vary only slightly. For that reason, I think it would be nice to be able to have a URL for the doc of a given branch, meaning the doc of the last released version of this branch. For example, that would be achieved by creating a symlink http://gcc.gnu.org/onlinedocs/gcc-4.2 - http://gcc.gnu.org/onlinedocs/gcc-4.2.1 Would that be considered useful? And if yes, how to implement it? FX
Fwd: MetaHTML and the GCC web site
Hi all, I'm currently rewriting the fortran/ part of the GCC website and trying to use the website preprocessor locally, to check my modifications (which include bringing fortran/ to the website common style). The script needs mhc, which seems to be the metahtml compiler. I tried to compile metahtml-5.08 as well as metahtml-5.091 (tarbal from the sources on sourceware, kindly provided by Ian Taylor) but both compilations dies in a subdirectory. I then wanted to ask for help on the metahtml mailing-list, but noticed that there has been no activity on those since 1999, which brings two questions: how was metahtml compiled for the current webserver (the error I see is certainly not target-specific), and should we use a tool that has been deceased for 8 years to produce our website? FX PS: The compilation error I get, if that rings a bell to someone who installed metahtml on the webserver, is in libmhtml: Compiling pagefuncs.c into pagefuncs.o gcc -Wall -Wstrict-prototypes -Wshadow -g -DHAVE_CONFIG_H -I. -I.. - I../libutils -I../libutils/regex -I/tmp/gdbm-1.8.3/include -I..- DCOMPILE_TIME_MODULE_DIRECTORY='/opt/metahtml-5.091/lib' -c pagefuncs.c pagefuncs.c:1070:1: error: unterminated argument list invoking macro DEFINE_SECTION pagefuncs.c:135: error: parse error at end of input where pagefuncs.c contains at line 135: DEFINE_SECTION (PAGE-VARIABLES, , [... here was multiline text ...], [... and here was also multiline text like that ...])
Recent (middle-end?) regressions in the Fortran testsuite
The last few days have seen a regression in the Fortran testsuite on
i386-linux and x86_64-linux (filed as PR33391). The following code
gives wrong results at -O2 while it works at -O1:
program test
integer(kind=1) :: i
do i = -128, 127
end do
if (i /= -128) call abort
end program test
Also of interest, gfortran.dg/vect/vect-{1,2,4}.f90 have started
failing on ia64 and i386 (but not x86_64 and i686, apparently).
FX
Re: Someone has caused regressions in gfortran (c_char_tests_red.f03, now PR33330)
Does anyone knows the answer? or should it be asked on comp.lang.fortran? It's very specific to the problem at hand, so I doubt c.l.f could give us much input on that. As I understand, in this case, it actually is the right thing to do. FX
Re: Someone has caused regressions in gfortran
Because of the famous duplicated declaration problem This sentence is reminding me that I forgot to send the following update: As I said I was going to give it a shot over the week-end, here's an update on this: it won't make it into 4.3, because it's a big change and my current patch is triggering a very long string of ice-on-invalid-code bugs (all type mismatches in Fortran interfaces for procedures end up dying badly) as well as a few ice-on-valid-code that are currently hard to track (and might be preexisting front-end bugs exposed by the patch). I intend to work slowly on this, and hopefully will have put a complete patch together when 4.4 stage1 opens. I am not sure if inlining is not completely unsafe for fortan and we would not be forced to disable it completely (not just partly as before the patch). This would be rather sad. I think the current situation is safe: we can online local functions (functions declared and inside other functions), which are the Fortran CONTAIN'ed functions. This should be safe, while all other inlining is currently impossible. FX
Re: Someone has caused regressions in gfortran
As I said I was going to give it a shot over the week-end, here's an update on this: it won't make it into 4.3, because it's a big change and my current patch is triggering a very long string of Huh, still I would be interested in seeing the patch. It's based on Michal Matz's patch at http://gcc.gnu.org/ml/gcc/2007-08/msg00236.html I'll send it tomorrow, I don't have my laptop with me today. Can we trick fotran to set DECL_UNINLINABLE in the non CONTAIN'ed functions? Yes, I think we can do that. Grep the front-end sources for FUNCTION_DECL as argument to build_decl: * the decl built in gfc_get_intrinsic_lib_fndecl (trans-intrinsic.c) can be made DECL_UNINLINABLE unconditionally * in trans-decl.c, the decls built in gfc_get_extern_function_decl and gfc_build_library_function_decl can also be made DECL_UNINLINABLE unconditionally * finally, in build_function_decl (trans-decl.c), you can do something like Index: trans-decl.c === --- trans-decl.c(revision 127902) +++ trans-decl.c(working copy) @@ -1217,6 +1217,8 @@ build_function_decl (gfc_symbol * sym) type = gfc_get_function_type (sym); fndecl = build_decl (FUNCTION_DECL, gfc_sym_identifier (sym), type); + if (!sym-attr.contained) +DECL_UNINLINABLE (fndecl) = 1; /* Perform name mangling if this is a top level or module procedure. */ if (current_function_decl == NULL_TREE) I have neither built nor regtested this, and I won't be able to do it in the next few days. If you feel like trying, please go ahead. FX
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
Well, at least the culprit is easy to find! 2007-08-16 H.J. Lu [EMAIL PROTECTED] * Makefile.in (REVISION): New. (REVISION_c): New. (REVISION_s): New. (version.o): Also depend on $(REVISION). Add -DREVISION=$(REVISION_s). * version.c (version_string): Add REVISION.
Re: Fortran regressions on Cygwin_NT
FAIL: gfortran.dg/g77/980310-3.f (internal compiler error) FAIL: gfortran.dg/g77/980310-3.f (test for excess errors) I saw this one on x86_64-linux with -m32, and filed it as PR33074. I asked about it on IRC yesterday, and if I understood Andrew Pinksi, it probably is a middle-end problem, as people have been messing with reload recently. FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution, -O0 This one apparently appeared between rev. 127178 and 2007-08-06 (see http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00161.html and http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00278.html; there is no revision number for the second one), and it is also seen on a few platforms. It probably was introduced by me (recent NINT patch) and fixed as per http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00902.html FX
Bootstrap broken on i386-pc-mingw32; ICE while building libgfortran
Hi all,
Bootstrap including gfortran has been broken on native i386-pc-mingw32
for at least 10 days, with the C compiler having an ICE while
compiling libgfortran/io/write.c. I finally found the opportunity to
reduce the ICE to the following code:
$ cat write.i
extern void fflush (int);
extern __attribute__ ((__dllimport__)) int _iob[];
static int __gthrw_pthread_once () __attribute__
((__weakref__(pthread_once)));
void flush_if_preconnected ()
{
fflush (_iob[0]);
}
$ C:/msys/1.0.10/home/FX/ibin/gcc/cc1.exe write.i -quiet
write.i:8: internal compiler error: Segmentation fault
The backtrace I could get from gdb can be found at the bottom of this
mail, and looks seriously garbled. I was wondering:
1. if someone else sees this issue? (for native compilers? for cross
compilers?)
2. what to do next? I've filed PR32915 , but I don't know what I
could do to debug further... I've nether done much programming or
debugging with Windows
Thanks for advice,
FX
-
Program received signal SIGSEGV, Segmentation fault.
decl_assembler_name_equal (decl=0x2ae2360, asmname=0x2ae1930)
at ../../trunk/gcc/tree.c:323
323 if (IDENTIFIER_POINTER (decl_asmname)[0] == '*')
(gdb) where
#0 decl_assembler_name_equal (decl=0x2ae2360, asmname=0x2ae1930)
at ../../trunk/gcc/tree.c:323
#1 0x00512973 in decl_assembler_name_equal (decl=0x2ae1930,
asmname=0x290f200) at ../../trunk/gcc/tree.c:314
#2 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x3d2412)
at ../../trunk/gcc/tree.c:314
#3 0x00512973 in decl_assembler_name_equal (decl=0x3d2412, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#4 0x00512973 in decl_assembler_name_equal (decl=0x3d2412, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#5 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#6 0x00512973 in decl_assembler_name_equal (decl=0x3, asmname=0x3d24a0)
at ../../trunk/gcc/tree.c:314
#7 0x00512973 in decl_assembler_name_equal (decl=0x3a, asmname=0x4)
at ../../trunk/gcc/tree.c:314
#8 0x00512973 in decl_assembler_name_equal (decl=0x1, asmname=0x9)
at ../../trunk/gcc/tree.c:314
#9 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x2)
at ../../trunk/gcc/tree.c:314
#10 0x00512973 in decl_assembler_name_equal (decl=0x401280, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#11 0x00512973 in decl_assembler_name_equal (decl=)
at ../../trunk/gcc/tree.c:314
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Re: [gnu.org #220291] Copyright assignment
Hello, It too is possible that you have completed your assignment process with the FSF, but have yet to be removed from the list of outstanding assignments. If this is the case please let me know so that I can update the record. This is the case: I have had a copyright assignment on file for almost two years, and have been contributing actively during that time. You can remove me from the list of outstanding assignments. Regards, FX
Re: Volunteer for bug summaries?
Hi, When the commit which introduced the regression is known, why not simply assign the bug to the committer? Surely, people do follow regularly the bugs that are assigned to them, don't they? In my opinion, all regressions should always be assigned to someone, at all times. Either to the identified guilty party, or to a volunteer or maintainer of that field, who is then responsible for identifying the guilty party, or finding someone who accepts to do it. This sounds like a reasonable way of making sure some regressions don't get forgotten, doesn't it? FX
Re: Volunteer for bug summaries?
We already do that, and in lots of cases it doesn't work. CCing is not coercive enough, you only receive a few more mails (and some people don't even read their bugzilla mail). Coercion isn't an option that is available to us. Hum, I checked the Merriam-Webster dictionary, and clearly coercive was stronger than I thought it was :( I only mean to say: things can get fixed by *gentling* pressuring people responsible for it, while also accepting the pressure when it is applied to yourself. This implies that you think it is the patch author's job to fix the problem. I think it was the patch author's job to either (a) fix the problem or (b) identify it clearly, and hand it over to the responsible maintainer. And if the patch were incorrect, you'd have an argument. But in this case, it seems that the patch is correct, but it exposes a problem elsewhere in the compiler (one of Kenner's famous latent bugs). [...] Andrew's comment suggests that the real bug is elsewhere, and I don't get why the author of the above patch is responsible for fixing that other breakage. My first problem with your reasoning is with suggests: someone has to do the analysis so that the bug can be correctly assigned and fixed. If noone is deemed responsible for doing this, then that regression might stay for years. It sounds not unreasonable to me to ask the person who committed the patch to do this analysis. After all, if he had seen it during his regtesting (in that particular case, testing with Fortran would have probably shown the regression), I don't think the patch would have been approved, would it? Reverting the patch is an option, but that would re-open whatever problems the patch fixed. And the second issue I see is: unless the patch was actually fixing a more important regression, which is not the most common case (and not the case here), you have actually traded a bug (or sometimes, even only a missed-optimization) for a regression. FX
Re: New option: -fstatic-libgfortran
Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? GMP and MPFR are host libraries, so it is actually an independent issue. However, it might be worth having --with-static-gmp and --with-static-mpfr to request static linking of these libraries into the compiler. I think I suggested the idea (maybe even a patch, but I can't find it in the mailing-list archives) when gmp/mpfr was still only used by Fortran. In the end, some people will think it's stretching the configury too much for a specific purpose, and some people will think it's just a good option to have. (I'm in the second group.) Let's wait and see what people think of the idea. FX
Re: GCC 4.2.0 Status Report (2007-04-15)
You want more bugs fixed, it would seem a better way would be to build a better sense of community (Have bugfix-only days, etc) and encourage it through good behavior, not through negative reinforcement. I do agree with that in a general way, but I think there should also be a real effort done by the various maintainers to make sure people indeed fix the few PRs they created. Maintainers should be able to say, please think of fixing this PR before submitting a patch for that feature. That doesn't introduce administrative overhead, because maintainers should keep track of the various PRs and patches of their area. I think it works already for some areas of the compiler, but doesn't work fine for the most common areas. A few examples of that (maybe I'm always quoting the same examples, but those are the ones I know that impact my own work on GCC): -- how can bootstrap stay broken (with default configure options) on i386-linux for 3 weeks? -- how could i386-netbsd bootstrap be broken for months (PR30058), and i386-mingw still be broken after 6 months (PR30589), when the cause of failure is well known? These are not rethorical How, or finger-pointing. I think these are cases of failure we should analyze to understand what in our development model allows them to happen. FX
Re: GCC 4.2.0 Status Report (2007-04-15)
The mea culpa is to permit for long time to modify configure instead of configure.ac or configure.in that is used by autoconf and/or automake. [...] I'm sorry, but I don't understand at all what you propose, what your proposal is supposed to fix or how that is related to the mail you're answering to. FX
Re: GCC 4.2.0 Status Report (2007-04-15)
libdecnumber/aclocal.m4:# generated automatically by aclocal 1.9.5 -*- Autoconf -*- That's a problem in the last regeneration of this file. I'm CCing M. Meissner, H. J. Lu and M. Cornea, since they appear to have last changed this file, although there's no ChangeLog entry for it in their commit. PS: it appears that it has been update two days ago by bonzini, and the new version has been generated with aclocal 1.9.6. 1) To update the generated configure scripts of the tarball before than distributing it. It could be done, but there's the risk that an automated process like that might introduce problems. I'd be more in favour of a nightly tester that check the Generated by headers to see if anything has an unexpected version number. 2) Or to remove the non-updated configure scripts. That's a annoyance, because it would require the autotools to build the GCC source, which is inconvenient. FX
Re: Gcc and gfortran installation on MacBook Pro
Hi Aurélien, A few remarks: 1. you don't show us the actual compilation error message: why is make failing? 2. maybe you don't know, but there are binaries available from http://gcc.gnu.org/wiki/GFortranBinaries, if that helps. 3. you should definitely quote the system compiler and cctools version you use. FX
Re: Gcc and gfortran installation on MacBook Pro
out_make is the output of the make. In fact it is the output of the make launch a second time. (To big otherwise.) Yes, but it's missing the standard error file. Please use: make out_make 2 err_make or something similar. FX
Build a function call with variable number of arguments
Hi all, Could someone give me a pointer to doc or code about building a function decl and function call expr that take a variable number of arguments (like printf)? Thanks, FX
Bootstrap broken on i386-pc-mingw32
Hi Zack, hi all, A bootstrap of GCC mainline, rev. 123324, fails because of: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/coudert/local/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber-o build/rtl.o ../../trunk/gcc/rtl.c In file included from ../../trunk/gcc/ggc.h:40, from ../../trunk/gcc/rtl.c:35: ./gtype-desc.h:64: error: expected identifier before ',' token Line 64 of gtype-desc.h is the line with gt_ggc_e_10stmt_gr,, in the following: gt_ggc_e_18gnat_binding_level, gt_ggc_e_9elab_info, gt_ggc_e_10stmt_gr,, gt_ggc_e_20ssa_operand_memory_d, gt_ggc_e_6subvar, The ,, is clearly wrong; there's another one later in this same file: gt_ggc_e_13convert_optab, gt_ggc_e_5optab, gt_ggc_e,,, gt_ggc_e_10real_value, gt_ggc_e_10VEC_rtx_gc, I'm CCing Zack, as there was a change in that code recently (last time I did a mingw32 build was on 2007-03-22, ie before that patch, and the bootstrap was successful). I'm willing to help and provide any generated files that may help to track this one down. PS: I've launched a cross build to see if I can reproduce it there, which would of course make it easier for tracking down. FX
Re: Bootstrap broken on i386-pc-mingw32
I'm CCing Zack Away on vacation until March 31st, said the automated reply. PS: I've launched a cross build to see if I can reproduce it there, which would of course make it easier for tracking down. Works OK on the cross. So, it's probably a host problem in gengtype. It appears to exist on HPUX as well, as Steve noted. FX
Re: Bootstrap broken on i386-pc-mingw32
Yeah, it appears I was overly optimistic in hoping vsnprintf() would do what C99 says it does. I do not have access to any system that shows the problem, but I've attached a patch that should fix it (it just reverts the oprintf() changes, which were not really necessary, I was just trying to be more efficient). Thanks, that fixes it for me on i386-pc-mingw32. FX
Re: Google Summer of Code: Mentor wanted for Fortran project
I tried to apply on the SoC website, but the application form only reloaded when I hit Become a mentor, neither saying if it worked or didn't work. So, I hope it worked. Can someone check it (Ian, maybe?) Problem fixed. The Google form doesn't work if you 1) use Safari and 2) come from a country with no notion of State or Province. FX smime.p7s Description: S/MIME cryptographic signature
Re: 4.3 bootstrap broken on i386-linux
My nightly bootstrap of mainline on i386-linux failed tonight, on revision 123192. This issue is still not fixed as of now. A diff was posted to PR31344 with the mention This isn't a real patch. Is a real patch planned in the near future, or is there any other short-time plan to get i386-linux bootstrap back? FX
Re: 4.3 bootstrap broken on i386-linux
is there any other short-time plan to get i386-linux bootstrap back? Just configure gcc with --disable-decimal-float. I don't think dfp works on x86 very well. Thanks for suggesting --disable-decimal-float. Note that, in my above sentence, any other short-time plan includes disabling it by default on that arch (temporarily or forever), as long as it allows bootstrap with the configure make. FX
Find the longest float type nodes
Hi all, I'm working on implementing a correct Fortran rounding (rounding to nearest-integer, with half integer values rounded to the integer of maximum absolute value) in the Fortran front-end, following ada/trans.c (convert_with_check) and http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html The code Ada uses to do it has the following comments: /* The following calculations depend on proper rounding to even of each arithmetic operation. In order to prevent excess precision from spoiling this property, use the widest hardware floating-point type. FIXME: For maximum efficiency, this should only be done for machines and types where intermediates may have extra precision. */ calc_type = longest_float_type_node; /* FIXME: Should not have padding in the first place */ if (TREE_CODE (calc_type) == RECORD_TYPE TYPE_IS_PADDING_P (calc_type)) calc_type = TREE_TYPE (TYPE_FIELDS (calc_type)); I have the three following questions, probably best directed to middle-end experts and Ada maintainers: * How can I know the longest float type? My first patch uses the long_double_type_node unconditionally, but it surely isn't a generic solution * How can I determine if a given type may have extra precision? * What is this padding code doing, and is it necessary? Thanks, FX
Has insn-attrtab.c been growing in size recently?
Hi all, A bootstrap attempt of GCC mainline on a i386-unknown-netbsdelf2.0.2 with: Memory: 378M Act, 264M Inact, 3520K Wired, 4664K Exec, 633M File, 151M Free Swap: 129M Total, 129M Free failed due to a compilation error in stage1: cc1: out of memory allocating 138677280 bytes after a total of 31484356 bytes make: *** [insn-attrtab.o] Error 1 The system compiler is gcc version 3.3.3 (NetBSD nb3 20040520). Last time I tried on this same computer was on 2006-12-03, and it passed stage1 OK. So I wonder what recent changes could have affected insn-attrtab.c on this target, and whether there could be a way to get it down in size. Thanks, FX
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
It might be considered a backend issue, but in general it is a binutils (so OP is in the wrong list!). I beg to disagree with the in general it is a binutils issue part. One of the posters explained why the information needed for name decoration can't be determined at link-time (nor at assembly-time, from what I understood). I think it's completely a compiler issue: if there's a switch (-mrtd) to change the calling convention of the generated code, there should probably be another one to also change the naming convention accordingly. On a related note, I found in gcc/config/i386/i386.c the following comment: The attribute stdcall is equivalent to RTD on a per module basis. I think it's not true wrt to naming convention. I otherwise perfectly agree with you about not adding yet another extension to the Fortran front-end. FX
Re: Detemining the size of int_fast8_t etc. in the frontend
Hi Tobias, What is the proper way to obtain this information? I fear the answer to this question is there's no way. We already discussed that a few months ago, at the thread starting here: http:// gcc.gnu.org/ml/gcc/2006-10/msg00346.html From private discussion, with Paul Brook Joseph Myers IIRC, the conclusion is that GCC can't do that right now, but it could if target-specific files provided the information. Maybe there's a PR open for that, otherwise you can open it, and we can try to get people implement the framework for this... Christopher's original ISO_C_BINDING patch used autoconf to guess it, and I remove that (before creating the fortran-experiments branch). Currently, there's no other option than to return -2 for the corresponding ISO_C_BINDING constants. FX smime.p7s Description: S/MIME cryptographic signature
Performance regression on the 4.3 branch?
I noticed a performance regression on the following code:
$ cat a.c
#include stdint.h
#include stdio.h
void
add256 (uint64_t x[4], const uint64_t y[4])
{
unsigned char carry;
x[0] += y[0];
carry = (x[0] y[0]);
x[1] += y[1]+carry;
carry = carry ? (x[1] = y[1]) : (x[1] y[1]);
x[2] += y[2]+carry;
carry = carry ? (x[2] = y[2]) : (x[2] y[2]);
x[3] += y[3]+carry;
}
int
main (void)
{
int i;
uint64_t x[4], y[4];
x[0] = 0; x[1] = 0; x[2] = 0; x[3] = 0;
y[0] = 0x0123456789abcdefULL;
y[1] = 0xfedcba9876543210ULL;
y[2] = 0xdeadbeeff001baadULL;
y[3] = 0x001001001001ULL;
for ( i=0 ; i1 ; i++ )
add256 (x, y);
printf (%016llx%016llx%016llx%016llx\n,
(unsigned long long)x[3],
(unsigned long long)x[2],
(unsigned long long)x[1],
(unsigned long long)x[0]);
return 0;
}
$ gcc -march=pentium4 -O3 a.c time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 1.81s user 0.00s system 99% cpu 1.818 total
$ gcc-4.3 -march=pentium4 -O3 a.c time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 2.40s user 0.01s system 87% cpu 2.746 total
where gcc is gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) and gcc-4.3
is gcc version 4.3.0 20070209 (experimental). I don't have a 4.1 or
4.2 compiler at hand, so I don't know if it's a 4.2 or 4.3 regression,
or even if there's a special patch in redhat 4.1 that makes it
lightning fast. But in any case, I wondered if it was known, and if it
was worth opening a PR.
Thanks,
FX
Coldfire doc glitch
Hi Richard, I found the following in my build logs, and thought it was worth reporting to you. Although I don't speak texinfo, the lines in questions are the ones introduced by your ColdFire 9/63 patch (commited as rev. 120713): perl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/../contrib/texi2pod.pl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/doc/invoke.texi gcc.pod @table ended by @end multitable at line 10424 make[3]: [gcc.pod] Error 9 (ignored) Thanks, FX
Who should fix platforms broken by extern inline hack?
Hi all, There are two platforms on which mainline is broken: * bootstrap is broken for i386-netbsd, see PR30058 * the compiler built on i386-mingw32 is unusable, see PR30589 Both regressions were introduced by Geoffrey Keating (http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a C99 extern inline patch. Fixincludes were then created for glibc systems. In both cases, I'm ready to debug (I attached the full preprocessed source of minimal examples to both PR) and test patches, but I simply don't know whom I should ping to get bootstrap working again: Geoffrey, who introduced the change that broke so many platforms, or the maintainers for these branches? (it might be worth noting at that point that netbsd doesn't have a maintainer listed) There has been some amount of chatting recently about the development plan for GCC, and I think we can all agree that having broken bootstrap for months on some platform don't help us get more testing :) Thanks for helping me understand the workings of the GCC community, FX
Re: Who should fix platforms broken by extern inline hack?
As it turns out, I do now have access to a NetBSD system, and will look at that problem when I next get time. Thanks. When you provid a patch, I will test it. (If someone else ever wants access to a netbsd system, it's worth noting there's one on the GCC compile farm!) My understanding from 30589 is that a sufficiently recent version of mingw32 has solved the problem. The CVS version of mingw32 has the workaround, but most people aren't using the CVS mingw32 (most people aren't using the last released version anyway), so there'll be a need for a fix anyway. FX
Re: [RFC] Our release cycles are getting longer
[sorry for breaking the thread; stupid gmail doesn't want to add custom References headers] It may be that not too many people pick up 4.2.0. But, if 4.3 isn't looking very stable, there will be a point when people decide that 4.2.0 is looking very attractive. The worst outcome of trying to do a 4.2.0 release is that we'll fix some things that are also bugs in 4.3; most 4.2 bugs are also in 4.3. From the Fortran point of view, and however limited it might be, skipping the 4.2.0 release would be very unfortunate. We've been working hard on it, and especially in recent time, many bug fixes have been deemed to risky to backport to the 4.1 branch. 4.3 is still a long way down the road, and the 4.2 branch has interesting features even from the non-Fortran point of view. About the other points of the discussion, maybe getting more exposure for the mainline branch (4.3.0) could get us more feedback? People are more involved in fixing bugs when they come just after their patch commit than when the report comes one month after. (and I can thing of examples in our bugzilla that confort this view :) Now, how to get greater exposure? We (some of the gfortran maintainers) have been making available regular binaries of the compiler for common archs; most of the bug reports are made from people using these binaries, so I suppose it's a way that works for us. There are a few people that help with gfortran development, not by patching, but by testing/filing detailed bug reports/writing testcases/etc. (They even tend to get involved in gfortran patching at some point :) Can it work for GCC as a whole? Maybe not for all types of bugs and users (the Fortran users mostly have mainstream archs), but we could nonetheless use more feedback and maybe have more people testing their apps with the latest mainline state. Sorry for being so long, but maybe the gfortran experience can help here, FX
Re: libgfortran still fails to build for sh-elf
And why would you think (twice) that the best place for reporting this is neither the gfortran mailing-list, nor bugzilla? I suggest that you test the following patch and report back to us: Index: libgfortran/runtime/error.c === --- libgfortran/runtime/error.c (revision 118806) +++ libgfortran/runtime/error.c (working copy) @@ -285,7 +285,7 @@ if (!options.locus || cmp == NULL || cmp-filename == NULL) return; - st_printf (At line %d of file %s\n, cmp-line, cmp-filename); + st_printf (At line %ld of file %s\n, (long int) cmp-line, cmp-filename); }
Re: libgfortran still fails to build for sh-elf
I suggest that you test the following patch and report back to us: I got the patch wrong (it's not a real printf function we have there): Index: libgfortran/runtime/error.c === --- libgfortran/runtime/error.c (revision 118806) +++ libgfortran/runtime/error.c (working copy) @@ -285,7 +285,7 @@ if (!options.locus || cmp == NULL || cmp-filename == NULL) return; - st_printf (At line %d of file %s\n, cmp-line, cmp-filename); + st_printf (At line %d of file %s\n, (int) cmp-line, cmp-filename); }
[bugzilla] Remove libf2c component
Hi all, I'm not sure whom to write about the workings of the GCC bugzilla database, so I'm writing here and CCing Daniel Berlin, since IIRC he handles part of that work. I think it would be nice (although not high priority) to remove the libf2c component in bugzilla, since we don't ship libf2c anymore now that 3.4 branch is extinct. There are no active bugs in it, the last open bugs were closed as WONTFIX by Gabriel dos Reis. Technically, I don't know what will happen to old bugs with this component, but at least we shouldn't propose that as a component to people reporting new bugs. FX
Re: Including GMP/MPFR in GCC repository?
First, please note that having gfortran testresults for one platform
only means that some version of the compiler was able to correctly
compile GMP MPFR, not that GCC trunk is able to correctly compile
GMP MPFR. Nevertheless:
* i386-unknown-freebsd (alpha-unknown-freebsd5.4)
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01072.html
I can confirm that GMP MPFR build fine and run their testsuite
cleanly on i386-unknown-freebsd{4.7,5.4,5.11}. I know Steve Kargl uses
this on x86_64-unknown-freebsd6.1 and it works fine.
As for other BSDs, I can confirm that GMP MPFR build and run their
testsuite fine on i386-unknown-netbsd2.0.2,
i386-unknown-openbsd{3.7,3.8}.
* sparc-sun-solaris2.10
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01273.html
I can also confirm that GMP MPFR build and run fine on
i386-unknown-solaris2.9.
* ia64-unknown-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01826.html
I my experience, GMP MPFR do also work fine on ia64-hpux, but that
requires a recent GMP version (= 4.2.0, if I remember correctly;
before that, the configury didn't work well for ia64-hpux).
Also, I have had GMP MPFR building and testing fine on alpha-linux
for some time.
Finally, as S/390 GNU/Linux seems to be considered for inclusion into
this list, it is worthy to note that gfortran is built regtested on
this platform and variants regularly.
FX
Where does tree-ssa.c read the variable names for -Wuninitialized messages?
Hi,
I'm trying to understand PR 13615, where a used-uninitialized Fortran
character string induces the following diagnostic:
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is used uninitialized in this function
I see that this error message is emitted from tree-ssa.c, but I'm not
skilled enough in middle-end magic to understand whether the fault is
on the front-end not setting something correctly, or the middle-end
not understanding what this variable is. I hope someone here could,
without too much trouble, help me.
Thanks,
FX
Re: Where does tree-ssa.c read the variable names for -Wuninitialized messages?
I'd say the FE is not setting the name properly into whatever _DECL we found. var_decl 0xb7b907e8 c$1 type integer_type 0xb7b95114 char public unsigned string-flag QI size integer_cst 0xb7b851f8 constant invariant 8 unit size integer_cst 0xb7b85210 constant invariant 1 align 8 symtab 0 alias set 4 precision 8 min integer_cst 0xb7b85270 0 max integer_cst 0xb7b85288 255 pointer_to_this pointer_type 0xb7b9c1cc used unsigned QI file pr13615.f line 7 size integer_cst 0xb7b851f8 8 unit size integer_cst 0xb7b85210 1 align 8 context function_decl 0xb7be0e00 warn_character I'll try to understand why this $1 behaves so badly in the error message, and why it is set that way in the first place. FX
GCC missed optimization?
I've been doing some benchmarking of gfortran, and reducing the
testcase leads to what seems a missed optimization in the following
code:
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=5 -std=c99 -c
a.c:5: note: Alignment of access forced using peeling.
a.c:5: note: Vectorizing an unaligned access.
a.c:5: note: not vectorized: relevant stmt not supported: D.1353_14 =
__builtin_powf (D.1352_13, 2.0e+0)
a.c:5: note: vectorized 0 loops in function.
I find in fold-const.c:fold_binary, around line 9091, I found the following:
/* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
Should I file it as a missed-optimization bug in bugzilla, or is there
some clever reason for that behaviour?
FX
Re: OpenMP bug with gfortran when compile under Windows platform
[CCing the OpenMP experts] Henry, The -fopenmp option doesn't work under mingw32. Since I am the one building the Windows (mingw32) binary packages you downloaded, I'm rather interesting in getting it to work... So here are a few things we could sort out: 1. currently, using the -fopenmp options gives: $ gfortran -fopenmp a.f gfortran.exe: unrecognized option '-pthread' gfortran.exe: libgomp.spec: No such file or directory Could we have a clearer error message? (perhaps saying that openmp is not available on that platform) The current message is clearly... not clear for users! 2. I looked at pthreads win32 (http://sources.redhat.com/pthreads-win32/), an opensource thread support for win32, including mingw32. Not all POSIX functions are implemented, but a fair amount of them. I'll try to get libgomp compiling with against those, and report progress here. 3. why is libgomp building conditional on target triplet, and not on detecting a working pthread implementation? Thanks, FX
Re: OpenMP bug with gfortran when compile under Windows platform
you just port libgomp to mingw32 + pthreads-win32
and assuming pthreads-win32 is sufficiently rich and not too buggy, it will
just work.
With the attached patch, I can compile libgomp with
../gcc/configure --prefix=/mingw --disable-nls --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap
--enable-threads=posix --with-win32-nlsapi=unicode
--host=i386-pc-mingw32 --enable-languages=c,fortran --enable-libgomp
and the resulting compiler and generated executables seem to work (I
tried a few C and Fortran toy codes). The main changes are to
libgomp/config/posix/time.c, which used functions not available on
mingw32. Would they be acceptable in this form (protected with #ifdef
_WIN32)? If so, I'll do some more testing, and officially submit the
patch.
FX
Index: libgomp/configure
===
--- libgomp/configure (revision 114196)
+++ libgomp/configure (working copy)
@@ -8397,7 +8397,9 @@
# Check for functions needed.
-for ac_func in getloadavg clock_gettime
+
+
+for ac_func in getloadavg clock_gettime gettimeofday sysconf
do
as_ac_var=`echo ac_cv_func_$ac_func | $as_tr_sh`
echo $as_me:$LINENO: checking for $ac_func 5
Index: libgomp/configure.ac
===
--- libgomp/configure.ac (revision 114196)
+++ libgomp/configure.ac (working copy)
@@ -162,7 +162,7 @@
[AC_MSG_ERROR([Pthreads are required to build libgomp])])])
# Check for functions needed.
-AC_CHECK_FUNCS(getloadavg clock_gettime)
+AC_CHECK_FUNCS(getloadavg clock_gettime gettimeofday sysconf)
# Check for broken semaphore implementation on darwin.
# sem_init returns: sem_init error: Function not implemented.
Index: libgomp/config.h.in
===
--- libgomp/config.h.in (revision 114196)
+++ libgomp/config.h.in (working copy)
@@ -18,6 +18,9 @@
/* Define to 1 if you have the `getloadavg' function. */
#undef HAVE_GETLOADAVG
+/* Define to 1 if you have the `gettimeofday' function. */
+#undef HAVE_GETTIMEOFDAY
+
/* Define to 1 if you have the inttypes.h header file. */
#undef HAVE_INTTYPES_H
@@ -42,6 +45,9 @@
/* Define to 1 if the target supports __sync_*_compare_and_swap */
#undef HAVE_SYNC_BUILTINS
+/* Define to 1 if you have the `sysconf' function. */
+#undef HAVE_SYSCONF
+
/* Define to 1 if you have the sys/loadavg.h header file. */
#undef HAVE_SYS_LOADAVG_H
Index: libgomp/config/posix/time.c
===
--- libgomp/config/posix/time.c (revision 114196)
+++ libgomp/config/posix/time.c (working copy)
@@ -48,32 +48,52 @@
double
omp_get_wtime (void)
{
-#ifdef HAVE_CLOCK_GETTIME
+#ifdef HAVE_GETTIMEOFDAY
+# ifdef HAVE_CLOCK_GETTIME
struct timespec ts;
-# ifdef CLOCK_MONOTONIC
+# ifdef CLOCK_MONOTONIC
if (clock_gettime (CLOCK_MONOTONIC, ts) 0)
-# endif
+# endif
clock_gettime (CLOCK_REALTIME, ts);
return ts.tv_sec + ts.tv_nsec / 1e9;
-#else
+# else
struct timeval tv;
gettimeofday (tv, NULL);
return tv.tv_sec + tv.tv_usec / 1e6;
+# endif
+#else
+# ifdef _WIN32
+
+#include sys/timeb.h
+ struct _timeb timebuf;
+ _ftime (timebuf);
+ return (timebuf.time + (long)(timebuf.millitm) / 1e3);
+# else
+# error Either clock_gettime or gettimeofday are required
+# endif
#endif
}
double
omp_get_wtick (void)
{
-#ifdef HAVE_CLOCK_GETTIME
+#ifdef HAVE_SYSCONF
+# ifdef HAVE_CLOCK_GETTIME
struct timespec ts;
-# ifdef CLOCK_MONOTONIC
+# ifdef CLOCK_MONOTONIC
if (clock_getres (CLOCK_MONOTONIC, ts) 0)
-# endif
+# endif
clock_getres (CLOCK_REALTIME, ts);
return ts.tv_sec + ts.tv_nsec / 1e9;
+# else
+ return 1.0 / sysconf(_SC_CLK_TCK);
+# endif
#else
- return 1.0 / sysconf(_SC_CLK_TCK);
+# ifdef _WIN32
+ return 1e-3;
+# else
+# error Either clock_getres or sysconf are required
+# endif
#endif
}
Index: gcc/config/i386/mingw32.h
===
--- gcc/config/i386/mingw32.h (revision 114196)
+++ gcc/config/i386/mingw32.h (working copy)
@@ -108,3 +108,8 @@
/* Define as short unsigned for compatibility with MS runtime. */
#undef WINT_TYPE
#define WINT_TYPE short unsigned int
+
+/* The mingw32 compiler doesn't know the -pthread option, but requires
+ explicitly linking the libpthread. */
+#undef GOMP_SELF_SPECS
+#define GOMP_SELF_SPECS -lpthread
gfortran testsuite regression, gfortran.dg/entry_3.f90
Hi all, The following regression appeared between 20060504 and 20060505 on i686-linux. It is filed as PR 27443,and appears to be a consequence of a new optimization pass introduced by revision 113518. FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer -funroll-loops FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -g Regards, FX
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 Humpf. Does that mean that the patch wasn't regtested before being applied? FX
Re: Bug with SSE on mingw32
I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific, with options -march=pentium4 -mfpmath=sse -msse. Some more input... the bug appears when SSE sqrtsd is called, but only if libgfortran contrusctors have been run: cat a.s .file a.f90 .section .rdata,dr .align 8 LC0: .long 0 .long 1073741824 .text .globl _MAIN__ .def_MAIN__;.scl2; .type 32; .endef _MAIN__: pushl %ebp movl%esp, %ebp subl$16, %esp movsd LC0, %xmm0 movsd %xmm0, -8(%ebp) sqrtsd -8(%ebp), %xmm0 movsd %xmm0, -8(%ebp) leave ret $ gcc a.s -lgfortranbegin -lgfortran ./a.exe [popus up crash dialog] $ diff a.s a_nolibgfortran.s 8,10c8,10 .globl _MAIN__ .def_MAIN__;.scl2; .type 32; .endef _MAIN__: --- .globl _main .def_main; .scl2; .type 32; .endef _main: $ gcc a.s ./a.exe [works ok] The problem appears to be inside the libgfortran constructor and functions called herein. I'll try to narrow it, but I don't really know what to look for... What kind of code can be expected to generate such bad behaviour? FX
Bug with SSE on mingw32
Hi all,
I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific,
with options -march=pentium4 -mfpmath=sse -msse. I reproduce it below,
and post it here before filing it because I can't manage to create a C
testcase, and have no idea if this is something already known (though
my bugzilla searches didn't return successful results).
$ cat a.f90
real(8) :: x
x = 2._8
print *, sqrt(x)
end
$ gfortran.exe a.f90 -mfpmath=sse -msse -march=i686 -O0 a
1.41421356237310
$ gfortran.exe a.f90 -mfpmath=sse -msse -march=pentium4 -O0 a
[pops up a crash window, win32 equivalent of a segfault]
Debugging leads to an endless loop of:
gdb: do_initial_child_stuff: process 2284
gdb: kernel event for pid=2284 tid=2264 code=CREATE_PROCESS_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 2284.0x8d8
ContinueDebugEvent (cpid=2284, ctid=2264, DBG_CONTINUE);
The difference in the assembly created in both cases:
$ diff -pu a.s.working a.s.crashing
--- a.s.working Mon Apr 24 16:11:00 2006
+++ a.s.crashingMon Apr 24 16:11:12 2006
@@ -13,8 +13,8 @@ _MAIN__:
pushl %ebp
movl%esp, %ebp
subl$312, %esp
- fldlLC0
- fstpl -8(%ebp)
+ movsd LC0, %xmm0
+ movsd %xmm0, -8(%ebp)
movl$LC1, -280(%ebp)
movl$3, -276(%ebp)
movl$6, -284(%ebp)
@@ -22,9 +22,8 @@ _MAIN__:
leal-288(%ebp), %eax
movl%eax, (%esp)
call__gfortran_st_write
- fldl-8(%ebp)
- fsqrt
- fstpl -16(%ebp)
+ sqrtsd -8(%ebp), %xmm0
+ movsd %xmm0, -16(%ebp)
movl$8, 8(%esp)
leal-16(%ebp), %eax
movl%eax, 4(%esp)
I tried to make C testcases based on the generated code/original dump:
MAIN__ ()
{
real8 x;
x = 2.0e+0;
x = __builtin_sqrt (x);
}
but they all work. Does anyone have any idea why all this is happening?
Thanks,
FX
Re: Successful Build: gcc-4.1-20051230 i686-pc-mingw32
[sorry for breaking the thread, stupid gmail interface doesn't allow
adding custom headers]
i tried to compile gcc 4.1.0 (the final release) on windows, too. I'm using
msys and configured the buildprocess with --enable-threads=win32
--with-win32-nlsapi=unicode. On the msys console i type make and after a
while i get the error with the Makefile on line 1277. I make the fix and
continue, then I get the error *** No rule to make target
`/mingw/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/bin/ld.exe',
needed by `stamp-collect-ld'. Stop. in the folder gcc.
This is a known bug (PR bootstrap/24382,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382). You need to
specify a path for ld by configuring with:
${srcdir}/configure --with-ld=/path/to/ld
As an example, I usually build gcc/gfortran with:
../gcc/configure --prefix=/mingw --enable-languages=c,fortran
--with-gmp=$HOME/local --disable-nls --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap
I don't know of any attempt to fix this bug, maybe Paolo made some
progress since his comment in the PR :)
I scanned the host/target specific installation notes on gcc.gnu.org,
but found to my surprise that there is no mention of i386-mingw32
there. I guess something this could be noted there.
FX
Re: Successful Build: gcc-4.1-20051230 i686-pc-mingw32
I started again (deleted the generated files) and configured with sh ../gcc-4.1.0/configure --prefix=/home/gcc41 --enable-threads=win32 --with-ld=/mingw/bin/ld --with-win32-nlsapi=unicode and fired make bootstrap. I think this time make made more than the last time, but ejected an error again I don't know for sure but, if I remember correctly my many unsuccessful attempts at building on mingw32, using --prefix=/mingw makes these go away. I'd like to stress that there is not much testing of gcc trunk under i386-mingw32 with MSYS. The configury and build system is widely broken for that platform. FX
Re: Segmentation fault in openmp simple routine from libgomp testsuite.
I might be missing out on something but I get a segmentation fault when manualy executing omp_hello.f from libgomp testsuite (libgomp/testsuite/libgomp.fortran/omp_hello.f)... Compiled using gfortran -static -fopenmp -g omp_hello.f -o omp_hello Hum... for trunk on i686-linux, I do see the following. Dynamic linking works fine: $ gfortran -fopenmp omp_hello.f OMP_NUM_THREADS=2 ./a.out Hello World from thread =0 Number of threads =2 Hello World from thread =1 Static linking fails: $ gfortran -fopenmp omp_hello.f -static /tmp/cc697VvU.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc697VvU.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc697VvU.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc697VvU.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status The reading of the libgomp.spec lead me to give it explicitly the needed libraries (although it shouldn't be necessary, I guess). But then, it segfaults: $ gfortran -fopenmp omp_hello.f -static -lgomp -lrt OMP_NUM_THREADS=2 ./a.out zsh: segmentation fault OMP_NUM_THREADS=2 ./a.out And the backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 75 ../../../gcc/libgomp/config/posix/sem.h: No such file or directory. in ../../../gcc/libgomp/config/posix/sem.h (gdb) where #0 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 #1 0x080aff5e in __do_global_ctors_aux () #2 0x08048109 in _init () #3 0x080613ed in __libc_csu_init () #4 0x08061138 in __libc_start_main () #5 0x08048141 in _start () PS: Some details on the static linking failure: Driving: gfortran -fopenmp omp_hello.f -static -v -lgfortranbegin -lgfortran -lm Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060228/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060228/gfortran_libs Thread model: posix gcc version 4.2.0 20060228 (experimental) /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/f951 omp_hello.f -ffixed-form -quiet -dumpbase omp_hello.f -mtune=i386 -auxbase omp_hello -version -fopenmp -I /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/finclude -o /tmp/ccGKM8HT.s GNU F95 version 4.2.0 20060228 (experimental) (i386-linux) compiled by GNU C version 4.2.0 20060228 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc08jqIE.o /tmp/ccGKM8HT.s GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD version 2.15.94.0.2.2 20041220 Reading specs from /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/../../../libgomp.spec /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/collect2 -m elf_i386 -static /usr/lib/crt1.o /usr/lib/crti.o /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/crtbeginT.o -lgomp -lrt -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0 -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/../../.. /tmp/cc08jqIE.o -lgfortranbegin -lgfortran -lm --start-group -lgcc -lgcc_eh -lpthread -lc --end-group /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/crtend.o /usr/lib/crtn.o /tmp/cc08jqIE.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc08jqIE.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc08jqIE.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc08jqIE.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status -- FX
[libgomp] patch for -pthread on Tru64
Hi all,
libgomp currently doesn't configure well on Tru64 (PR
bootstrap/26161), because the configury is testing the usability of
pthread.h system headers, while on Tru64 this can only work when the
compiler is used with the -pthread option.
While this flag could be added on a per-target basis (it might be
needed on AIX too, but I can't confirm) in the configure.ac file
(configure.tgt is called to late for that), I thought about something
more general. In libgomp/configure.ac, why do we have the two
following tests:
AC_CHECK_HEADER([pthread.h],[],
[AC_MSG_ERROR([Pthreads are required to build libgomp])])
and
# Check to see if -pthread or -lpthread is needed. Prefer the former.
XPCFLAGS=
CFLAGS=$CFLAGS -pthread
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[#include pthread.h
void *g(void *d) { return NULL; }],
[pthread_t t; pthread_create(t,NULL,g,NULL);])],
[XPCFLAGS= -Wc,-pthread],
[CFLAGS=$save_CFLAGS LIBS=-lpthread $LIBS
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[#include pthread.h
void *g(void *d) { return NULL; }],
[pthread_t t; pthread_create(t,NULL,g,NULL);])],
[],
[AC_MSG_ERROR([Pthreads are required to build libgomp])])])
It looks to me that the second alone should be enough because, if
pthread.h is not available, both AC_LINK_IFELSE will fail and we will
have the AC_MSG_ERROR, which is exactly what happens during the
AC_CHECK_HEADER test.
Moreover, removing the first test makes libgomp build on targets (as
Tru64) where the -pthread option is required to include pthread.h.
Is this analysis wrong? If not, could someone OK the attached patch
(tested on alphaev68-dec-osf5.1b)?
Thanks,
FX
:ADDPATCH build:
Index: configure.ac
===
--- configure.ac(revision 10)
+++ configure.ac(working copy)
@@ -139,8 +139,6 @@
AC_STDC_HEADERS
AC_HEADER_TIME
AC_CHECK_HEADERS(unistd.h semaphore.h sys/loadavg.h sys/time.h)
-AC_CHECK_HEADER([pthread.h],[],
- [AC_MSG_ERROR([Pthreads are required to build libgomp])])
GCC_HEADER_STDINT(gstdint.h)
pr26161.ChangeLog
Description: Binary data
gfortran and -mlong-double-128
Hi all, I'm sending this mail because I'm a bit confused about the -mlong-double-128 option on (for example) ppc64-linux, and its impact on gfortran/libgfortran. When I simply bootstrap a compiler with configure --with-cpu=default32, I get a gfortran that does only have kind=4 and kind=8 reals (corresponding to C types float and double) by default. When I use this gfortran with the -mlong-double-128 option, the real(kind=16) floating point type is accepted at compile-time, but the I/O library in libgfortran doesn't know how to deal with it (since, when libgfortran was compiled, it did not detect that real(kind=16) was available), and the code fails at runtime. What should we do about that? I see a few options: 1. refuse -mlong-double-128 for Fortran code; easiest, but not exactly satisfying 2. build multiple instances of the library, as is currently done for the -m32/-m64 options 3. build only one instance of the library, but build it with -mlong-double-128 enabled, since as far as libgfortran is concerned, it only adds a new floating-point type. I may be confused about how all this is supposed to be handled, so any pointer to further reading is welcome, as well as opinion on the problem and options above. Thanks, FX
Re: gfortran and -mlong-double-128
I guess libgfortran has configury to figure out if kind=16 is available? Yes. If so then libgfortran should be built with -mlong-double-128, as this should only add extra symbols that do not conflict with kind=4 and kind=8 ones. Hum, that has to be done early in the configury (before all autodetection). Do you think it's better suited at the beginning of libgfortran/configure.ac (a special test, to see if -mlong-double-128 is available, and if it is add it to CFLAGS), or should it be done in an upper level (and here is the limit of my understanding of the build mechanism)? Am I correct that for gfortran there is no such thing as long double == double for -mlong-double-64? This is right. Fortran has a list of available floating-point modes, and they are chosen by a unique numbering scheme (the number is called a kind). FX
Re: gfortran and -mlong-double-128
Having gfortran magically know about certain ABI breaking options, and doing funny things on certain targets seems a very bad precedent to me. Then, I think we should have the front-end refuse the option. It's annoying to have a compiler accept code, and only tell you at runtime (at the end of your simulation!) that it can't work. FX
Re: Massive FORTRAN test failures
I have got massive FORFRAN test failures on Linux/ia64 and Linux/x86-64: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00730.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00729.html Most of failures look like: /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/char_result_11.f90:0: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See URL:http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1 I did see the following on my nightly regtest on x86_64-linux: FAIL: gfortran.dg/char_transpose_1.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/char_transpose_1.f90 -O3 -g compilation failed to produce executable FX
mips-irix6.5 and complex.h
Hi, I am stuck with PR libfortran/22097 because currently, the libgfortran configury isn't clever enough to get cabsl (among others) right on mips-irix6.5. config.h has #define HAVE_CABSF 1 and /* #undef HAVE_COMPLEX_H */ while the correct definition of cabsl is provided in complex.h. Can someone who knows mips-irix or has experience with such broken C99 complex implementations give some help? The problem I have is comment #9 from PR 22097. Thanks, FX
Re: Build using --with-gmp and shared libraries
Testing done on i686-linux (built with --languages=c,fortran and a shared libgmp in /foo/bar, and regtested). OK for mainline? OK for 4.0? ping**3, build machinery maintainers in Cc. This patch makes --with-gmp and --with-mpfr similar to --with-as and others, where you don't need to have the as program in your PATH if explicitly specified. FX
Re: Build using --with-gmp and shared libraries
Basic testing done on i686-linux (built with --languages=c,fortran and a shared libgmp in /foo/bar, and regtested). Extended testing (which takes ages on my computer) in progress. OK for mainline? OK for 4.0? *ping* This patch has both a toplevel part and a part in gcc/, so I don't know exactly who can approve it. ping**2 I know the ideal world solution is to have a GMP/MPFR in-tree, but nobody proposed a patch to do it and we do have a build failure with the current situation. -- FX
Re: Build using --with-gmp and shared libraries
Or did I miss the point entirely? Right now, having the GMP/MPFR libraries (later refered as GMP) in /home/gmp and typing: configure --with-gmp=/home/gmp --enable-languages=c,fortran does configure fine but running make then fails when it attempts to build libgfortran. This is PR 21547, see the audit trail for more details. The general opinion is that it is normal to have to set your LD_LIBRARY_PATH to run the installed compiler, but using --with-gmp should be enough to build it in any case. This is what the toplevel part of my patch does. Moreover, I think that running the testsuite shouldn't require setting LD_LIBRARY_PATH either, which is what the gcc/ part of the patch is about. FX
Re: Build using --with-gmp and shared libraries
Basic testing done on i686-linux (built with --languages=c,fortran and a shared libgmp in /foo/bar, and regtested). Extended testing (which takes ages on my computer) in progress. OK for mainline? OK for 4.0? *ping* This patch has both a toplevel part and a part in gcc/, so I don't know exactly who can approve it. FX
Re: toplevel Makefile.tpl hacking
You can use make check-target-libgfortran, which is what I thought you were using to test. There's no testsuite for libgfortran (the command you mentionned does not test anything). The only way I'm aware of to run the gfortran testsuite is make check-fortran inside $builddir/gcc. I think I will soon have a patch ready to fix that last problem. FX
Build using --with-gmp and shared libraries
Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran testsuite, and the fix is also
included in this patch.
Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.
OK for mainline? OK for 4.0?
:ADDPATCH build:
Index: Makefile.tpl
===
--- Makefile.tpl (revision 106019)
+++ Makefile.tpl (working copy)
@@ -157,6 +157,7 @@
OBJDUMP=$(OBJDUMP); export OBJDUMP; \
TOPLEVEL_CONFIGURE_ARGUMENTS=$(TOPLEVEL_CONFIGURE_ARGUMENTS); export TOPLEVEL_CONFIGURE_ARGUMENTS; \
GMPLIBS=$(HOST_GMPLIBS); export GMPLIBS; \
+ GMPLIBSDIR=$(HOST_GMPLIBSDIR); export GMPLIBSDIR; \
GMPINC=$(HOST_GMPINC); export GMPINC; \
@if gcc-bootstrap
$(RPATH_ENVVAR)=`echo $(TARGET_LIB_PATH)$$$(RPATH_ENVVAR) | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
@@ -216,6 +217,7 @@
# Where to find GMP
HOST_GMPLIBS = @gmplibs@
+HOST_GMPLIBSDIR = @gmplibsdir@
HOST_GMPINC = @gmpinc@
# --
@@ -615,7 +617,7 @@
# Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
@if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:$(HOST_GMPLIBSDIR):
@endif gcc
[+ FOR host_modules +][+ IF lib_path +]
Index: configure.in
===
--- configure.in (revision 106019)
+++ configure.in (working copy)
@@ -1058,6 +1058,7 @@
# Check for GMP and MPFR
gmplibs=
gmpinc=
+gmplibsdir=
have_gmp=yes
# Specify a location for mpfr
# check for this first so it ends up on the link line before gmp.
@@ -1075,6 +1076,7 @@
if test x$with_mpfr != x; then
gmplibs=-L$with_mpfr/lib $gmplibs
gmpinc=-I$with_mpfr/include
+ gmplibsdir=$with_mpfr/lib
fi
# Specify a location for gmp
@@ -1097,6 +1099,11 @@
if test x$with_gmp != x; then
gmplibs=-L$with_gmp/lib $gmplibs
gmpinc=-I$with_gmp/include $gmpinc
+ if test x$gmplibsdir != x; then
+gmplibsdir=$gmplibsdir:$with_gmp/lib
+ else
+gmplibsdir=$with_gmp/lib
+ fi
fi
saved_CFLAGS=$CFLAGS
@@ -1125,6 +1132,7 @@
# Flags needed for both GMP and/or MPFR
AC_SUBST(gmplibs)
AC_SUBST(gmpinc)
+AC_SUBST(gmplibsdir)
# By default, C is the only stage 1 language.
stage1_languages=c
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 106019)
+++ gcc/configure.ac (working copy)
@@ -3402,6 +3402,8 @@
AC_ARG_VAR(GMPLIBS,[How to link GMP])
AC_ARG_VAR(GMPINC,[How to find GMP include files])
+AC_ARG_VAR(GMPLIBSDIR,[Where to find the GMP library])
+AC_ARG_VAR(RPATH_ENVVAR,[How the systems locates libraries])
# Configure the subdirectories
# AC_CONFIG_SUBDIRS($subdirs)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 106019)
+++ gcc/Makefile.in (working copy)
@@ -294,6 +294,8 @@
# How to find GMP
GMPLIBS = @GMPLIBS@
GMPINC = @GMPINC@
+GMPLIBSDIR = @GMPLIBSDIR@
+RPATH_ENVVAR = @RPATH_ENVVAR@
CPPLIB = ../libcpp/libcpp.a
CPPINC = -I$(srcdir)/../libcpp/include
@@ -3906,6 +3908,7 @@
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
+ $(RPATH_ENVVAR)=`echo $(GMPLIBSDIR):$$$(RPATH_ENVVAR) | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'` ; export $(RPATH_ENVVAR) ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD_COMMAND}` ; \
export TCL_LIBRARY ; fi ; \
libgmp.ChangeLog
Description: Binary data
Re: Build using --with-gmp and shared libraries
The newest version of mpfr will build a shared library. In fact, we should move to using the newest version, but I think some/many people would object to having two external library dependencies. What advantages have the newest version? And (sorry for the obvious question) why isn't it kept in sync with gmp? FX
Re: toplevel Makefile.tpl hacking
- with this patch, the libgfortran is built, but the gfortran testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH for the testsuite? It should Well, it doesn't. The problem is that the gfortran testsuite is not run with the toplevel Makefile, but by going into the $builddir/gcc directory and typing make check-fortran. I'm not sure whether this is another deficiency (after all, make check-gcc and make check-g++ can be run from the toplevel makefile), and how to fix it. FX
Re: [gfortran] fortran preprocessing, round 2
PR fortran/18452 * gcc/c.opt: Add a -lang-fortran option. * gcc/c-opts.c: Add a lang_fortran flag. (c_common_init_options): Handling the -lang-fortran option. (c_common_handle_option): Add a case for Fortran options in preprocessing. Remove cases for -ffixed-form and -ffixed-line-length. Add a case for -lang-fortran. Ok. I'll commit when 4.1 unfreezes before branching. Could that apply to branch 4.0 as well? FX
Re: [fortran] ICE in fold_convert, at fold-const.c:2028
core_rel.f90:179: internal compiler error: in fold_convert, at fold-const.c:2028 This might be either PR19362 or PR20244 in bugzilla. FX
Re: A couple more subversion notes
Since there is a big brainstorming, I will sum up my opinion here (and then stop spending time on this issue). From the discussion, it looks like the switch seems the most important constraint imposed by the switch is about hardware/software requirements, and I do strongly second this point. For example, some of us have to work on machines on which they're not root. I asked my sysadmin to install subversion, and it was done a month and a half later (two weeks ago). I know will have to ask him for svk, then again a newer svn (and perhaps a updated openssh, but that surely will be refused). And I'd rather not install all that myself, cause users are on shared disks with quotas. Another example: ever tried asking the sourceforge compile farm team for an update? they're still considering updating MacOS 10.1. So yes, there are solutions for some of the issues some of us have, but they all look a bit complicated. Well, maybe gcc this discussion would be spared if gcc contributors were only people supported by their company. But that's not the case. FX
using multiple trees with subversion
Hi all, I've been playing with the svn test repo during the last few days, updating my own (few) scripts and all, and it's been going very smoothly. The only thing that's worrying me is disk usage. I do only have small involvement in gcc, preparing few patches (never more than 5 at a time) on limited areas (gcc/fortran, libgfortran and gcc/testsuite), always on mainline or 4.0 branch. The way I manage to keep mind sanity right now is to have a few complete trees (one for 4.0 and 3-4 for mainline, each one with a local changes), called gcc-newintrinsics, gcc-fpe, ... Having 5 subversion trees will need much more space (for local pristine copies), which I don't really have. Is there any way to force subversion use one pristine tree for all modified trees, or is my way of handling things completely rotten? I welcome any advice... Thanks! FX
Re: using multiple trees with subversion
Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have support for checking out repositories with compressed local copies (or no copy at all -- but I wouldn't suggest this, as you'd start to be slow in svn diff, svn stat, etc). I guess no local copy would be fine with me. diff and stat should not be much slower than in CVS, and since very rarely do a full tree diff/stat, this is quite acceptable. Is that so hard to implement that it's not done already? Or am I the only person to find that disk is expensive (or working on his own hardware, maybe)? You may want to look into svk though Thanks for the link, I'll give it a try. FX
Re: [Bug bootstrap] [4.1 regression] Build fails on Cygwin
Patches needed to build on mingw32 include http://gcc.gnu.org/ml/gcc-patches/2005-08/msg9.html and http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00097.html . The first one contains the fix to your problem, the second one is the latest version of the patch to fix dllimport. However, on mingw32, this is not enough to build (see PR 23210, for example). FX
Re: PING [4.1 regression, patch] build i686-pc-mingw32
Coming back to this topic. Nobody has answered to one of my questions: if the mingw/cygwin maintainers can't approve such a patch, who can? FX
Re: Add clog10 to builtins.def, round 2
* builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins that C99 reserve for future use. Use it to define clog10, clog10f and clog10l. Ok. Commited. Thanks, FX
Add clog10 to builtins.def, round 2
The fortran front-end needs to recognize clog10, clog10f and clog10l a proper built-ins. Attached patch tries to add them to clog10, under a new category: DEF_EXT_C99RES_BUILTIN (as suggested by jsm28). Can someone review this? Is it OK? Thanks, François-Xavier Index: gcc/builtins.def === RCS file: /cvsroot/gcc/gcc/gcc/builtins.def,v retrieving revision 1.104 diff -u -3 -p -r1.104 builtins.def --- gcc/builtins.def 25 Jun 2005 01:59:13 - 1.104 +++ gcc/builtins.def 29 Jun 2005 21:25:38 - @@ -119,6 +119,13 @@ Software Foundation, 51 Franklin Street, DEF_BUILTIN (ENUM, __builtin_ NAME, BUILT_IN_NORMAL, TYPE, TYPE, \ true, true, !flag_isoc99, ATTRS, TARGET_C99_FUNCTIONS, true) +/* Builtin that C99 reserve the name for future use. We can still recognize + the builtin in C99 mode but we can't produce it implicitly. */ +#undef DEF_EXT_C99RES_BUILTIN +#define DEF_EXT_C99RES_BUILTIN(ENUM, NAME, TYPE, ATTRS) \ + DEF_BUILTIN (ENUM, __builtin_ NAME, BUILT_IN_NORMAL, TYPE, TYPE, \ + true, true, true, ATTRS, false, true) + /* Allocate the enum and the name for a builtin, but do not actually define it here at all. */ #undef DEF_BUILTIN_STUB @@ -436,6 +443,9 @@ DEF_C99_BUILTIN(BUILT_IN_CIMAGL, DEF_C99_BUILTIN(BUILT_IN_CLOG, clog, BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_MATHFN_FPROUNDING) DEF_C99_BUILTIN(BUILT_IN_CLOGF, clogf, BT_FN_COMPLEX_FLOAT_COMPLEX_FLOAT, ATTR_MATHFN_FPROUNDING) DEF_C99_BUILTIN(BUILT_IN_CLOGL, clogl, BT_FN_COMPLEX_LONGDOUBLE_COMPLEX_LONGDOUBLE, ATTR_MATHFN_FPROUNDING) +DEF_EXT_C99RES_BUILTIN (BUILT_IN_CLOG10, clog10, BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_MATHFN_FPROUNDING) +DEF_EXT_C99RES_BUILTIN (BUILT_IN_CLOG10F, clog10f, BT_FN_COMPLEX_FLOAT_COMPLEX_FLOAT, ATTR_MATHFN_FPROUNDING) +DEF_EXT_C99RES_BUILTIN (BUILT_IN_CLOG10L, clog10l, BT_FN_COMPLEX_LONGDOUBLE_COMPLEX_LONGDOUBLE, ATTR_MATHFN_FPROUNDING) DEF_C99_BUILTIN(BUILT_IN_CONJ, conj, BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_CONST_NOTHROW_LIST) DEF_C99_BUILTIN(BUILT_IN_CONJF, conjf, BT_FN_COMPLEX_FLOAT_COMPLEX_FLOAT, ATTR_CONST_NOTHROW_LIST) DEF_C99_BUILTIN(BUILT_IN_CONJL, conjl, BT_FN_COMPLEX_LONGDOUBLE_COMPLEX_LONGDOUBLE, ATTR_CONST_NOTHROW_LIST)
Re: Cygwin build failure
Knowing that you do regular Cygwin builds of gcc, I wonder can you advise me, please? For the better part of a month, I have not succeeded in building gcc from the CVS tree under Cygwin_NT-5.1 for one reason or another. That's PR 21766 (appropriately named Bootstrap failure on i686-pc-cygwin). Opened almost a month ago. GCC mainline doesn't build on cygwin or mingw since that time. Seeing that almost no comment had been made by the maintainers on it, and no correct patch proposed, it looks like we're gonna have to live with it for a long time... :( Short-time answer: patches provided in bugzilla don't fix the problem, but they should enable you to build successfully (and then, the problem shouldn't really appear in gfortran). Long-time answer: well, I cc this mail to gcc@gcc.gnu.org and maintainers so that we can have a hint whether this is going to be fixed soon or not. FX PS: Detailled info on your problems: /usr/include/stdint.h:18: error: conflicting types for 'int8_t' ../../../gcc/libgfortran/libgfortran.h:63: error: previous declaration of 'int8_t' was here This one is because you're reconfiguring in a non-empty tree. There is a PR number for it, but I don't remember it... ../../../gcc/libgfortran/runtime/environ.c:104: error: invariant not recomputed when ADDR_EXPR changed _ctype_D.1954[1]; This one is due to the bootstrap failure (PR 21766).
