Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On Sat, Jan 21, 2023, 18:59 Jerry D via Fortran wrote: > > Proposed ChangeLog entry using git gcc-commit-mklog: > > Author: Jerry DeLisle > Date: Sat Jan 21 15:47:19 2023 -0800 > > Revise the line end tests to pass on certain windows test environments > which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). > Just to be clear, all simulators inject the spurious r's. I replicated the problem on Linux.
Re: [Patch] install.texi: Bump newlib version for nvptx + gcn
On Sat, 21 Jan 2023, Tobias Burnus wrote: > On the technical side, the newer newlib version is not yet required. But > it looks as if it soon makes a lot of sense to have it: : > As nvptx/amdgcn is (mostly) about offloading code, newlib is compiled > usually alongside GCC (e.g. in SUSE, Debian/Ubuntu, ...); additionally, > there is static linking such that mixing old vs. new libraries is less > likely. Hence, requiring the newest version of newlib together with the > newest compiler shouldn't be a problem in my opinion. That sounds like a convincing argument. >> And, this predates your patch, in one instance we refer to Newlib >> (upper case9, in the other to newlib (lower case). Would it make >> sense to converge to one? > Maybe, but the question is what to use? The project's webpage has on the > first page: "patch submissions to Newlib" and "automate the testing of > newlib". I also dug into the newlib web page and other sources and - while my personal preference slightly leans towards Newlib - believe newlib is more established overall. For the web pages, it's clearer than for our *.texi ones you dug into: ~/src/wwwdocs/htdocs> grep -r newlib . | wc -l 15 ~/src/wwwdocs/htdocs> grep -r Newlib . | wc -l 3 > Thoughts? Let's go for newlib (lowercase) I'd say; if you agree I can take care of wwwdocs Cheers, Gerald
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On 1/20/23 6:13 PM, Jerry DeLisle via Fortran wrote: Hi all, The attached patch modifies the following tests to check for line endings. Some test environments inject superfluous /r characters at ends of lines. The expression matching in dg-output tests are changed from: (\n|\r\n|\r) to (\r*\n+) This allows these tests to pass. The failing tests tend to mask the real bugs in these systems. The changes were provided by Nightstrike who has tested on the troublesome environment. I ran the tests successfully on Linux. I do not know if anyone has tested on Mac or some of the other system that use odd line endings. OK for trunk? What about for 12? Regards, Jerry modified: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90 modified: gcc/testsuite/gfortran.dg/array_temporaries_2.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-1.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-4.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 modified: gcc/testsuite/gfortran.dg/fmt_error_4.f90 modified: gcc/testsuite/gfortran.dg/fmt_error_5.f90 modified: gcc/testsuite/gfortran.dg/fmt_float.f90 modified: gcc/testsuite/gfortran.dg/fmt_l.f90 modified: gcc/testsuite/gfortran.dg/fmt_nonchar_2.f90 modified: gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 modified: gcc/testsuite/gfortran.dg/g77/f77-edit-apostrophe-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-colon-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-h-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-i-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-s-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-slash-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-t-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f modified: gcc/testsuite/gfortran.dg/namelist_40.f90 modified: gcc/testsuite/gfortran.dg/namelist_47.f90 modified: gcc/testsuite/gfortran.dg/namelist_print_1.f modified: gcc/testsuite/gfortran.dg/parameter_array_dummy.f90 Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. * gfortran.dg/array_temporaries_2.f90: As noted above. * gfortran.dg/bind-c-contiguous-1.f90: As noted above. * gfortran.dg/bind-c-contiguous-4.f90: As noted above. * gfortran.dg/bind-c-contiguous-5.f90: As noted above. * gfortran.dg/fmt_error_4.f90: As noted above. * gfortran.dg/fmt_error_5.f90: As noted above. * gfortran.dg/fmt_float.f90: As noted above. * gfortran.dg/fmt_l.f90: As noted above. * gfortran.dg/fmt_nonchar_2.f90: As noted above. * gfortran.dg/fmt_zero_precision.f90: As noted above. * gfortran.dg/g77/f77-edit-apostrophe-out.f: As noted above. * gfortran.dg/g77/f77-edit-colon-out.f: As noted above. * gfortran.dg/g77/f77-edit-h-out.f: As noted above. * gfortran.dg/g77/f77-edit-i-out.f: As noted above. * gfortran.dg/g77/f77-edit-s-out.f: As noted above. * gfortran.dg/g77/f77-edit-slash-out.f: As noted above. * gfortran.dg/g77/f77-edit-t-out.f: As noted above. * gfortran.dg/g77/f77-edit-x-out.f: As noted above. * gfortran.dg/namelist_40.f90: As noted above. * gfortran.dg/namelist_47.f90: As noted above. * gfortran.dg/namelist_print_1.f: As noted above. * gfortran.dg/parameter_array_dummy.f90: As noted above.
Re: [PATCH] tree-optimization/108449 - keep maybe_special_function_p behavior
> When we have a static declaration without definition we diagnose
> that and turn it into an extern declaration. That can alter
> the outcome of maybe_special_function_p here and there's really
> no point in doing that, so don't.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> PR tree-optimization/108449
> * cgraphunit.cc (check_global_declaration): Do not turn
> undefined statics into externs.
Looks OK to me. I got kind of suprrised we still have
maybe_special_function_p and we do chane of public flag.
I wonder if we can run into similar problem when promoting declaration
at LTO time?
Honza
>
> * gcc.dg/pr108449.c: New testcase.
> ---
> gcc/cgraphunit.cc | 2 --
> gcc/testsuite/gcc.dg/pr108449.c | 5 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/pr108449.c
>
> diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
> index 59ce2708b7b..832818d651f 100644
> --- a/gcc/cgraphunit.cc
> +++ b/gcc/cgraphunit.cc
> @@ -1087,8 +1087,6 @@ check_global_declaration (symtab_node *snode)
>else
> warning (OPT_Wunused_function, "%q+F declared % but never "
> "defined", decl);
> - /* This symbol is effectively an "extern" declaration now. */
> - TREE_PUBLIC (decl) = 1;
> }
>
>/* Warn about static fns or vars defined but not used. */
> diff --git a/gcc/testsuite/gcc.dg/pr108449.c b/gcc/testsuite/gcc.dg/pr108449.c
> new file mode 100644
> index 000..4a3ae5b3ed4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr108449.c
> @@ -0,0 +1,5 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O" } */
> +
> +static int vfork(); /* { dg-warning "used but never defined" } */
> +void f() { vfork(); }
> --
> 2.35.3
Re: Fix wrong code issues with ipa-sra
Hello,
Coverity flagged a real issue in this patch:
On Mon, 16 Jan 2023, Jan Hubicka via Gcc-patches wrote:
> --- a/gcc/ipa-utils.cc
> +++ b/gcc/ipa-utils.cc
[...]
> +bitmap
> +find_always_executed_bbs (function *fun, bool assume_return_or_eh)
> +{
> + auto_vec stack;
> + auto_vec terminating_bbs;
> + hash_set visited;
> + edge e;
> + edge_iterator ei;
> +
> + /* First walk all BBs reachable from entry stopping on statements that may
> + terminate execution. Everything past this statement is not going to be
> executed
> + each invocation. */
> + stack.safe_push (ENTRY_BLOCK_PTR_FOR_FN (fun));
> + while (!stack.is_empty ())
> +{
> + basic_block bb = stack.pop ();
> + bool found = false, found_exit = false;
> + if (!assume_return_or_eh
> + && (EDGE_COUNT (bb->succs) == 0 || (bb->flags & BB_IRREDUCIBLE_LOOP)))
> + found = true;
> + FOR_EACH_EDGE (e, ei, bb->succs)
> + {
> + if (e->dest == EXIT_BLOCK_PTR_FOR_FN (fun))
> + {
> + found_exit = true;
> + break;
> + }
> + /* Watch for infinite loops. */
> + if (!found && (assume_return_or_eh & EDGE_DFS_BACK)
^^^
This bitwise 'and' always evaluates to zero, making the entire clause
always-false.
Alexander
Re: [wwwdocs][Patch] Add OpenMP by-GCC-version implementation status
On Tue, 17 May 2022, Tobias Burnus wrote: > Done so: https://gcc.gnu.org/projects/gomp/ Nice! > Thanks again for all the comments! Always welcome! One detailed I noticed only now: The GOMP project consists of implementation of OpenMP and OpenACC to permit annotating the source code to permit running it concurrently ^^ ^^ with thread parallelization and on offloading devices Do you have a good idea how to reword that to avoid two instances of "permit" in the same sentence, so close to each other? Gerald
Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
Hi Jerry, Am 21.01.23 um 19:27 schrieb Jerry D via Gcc-patches: On 1/20/23 9:16 PM, Jerry D wrote: On 1/20/23 5:46 PM, Jerry D wrote: A PARAMETER value is not allowed in a DATA statement, similar to an EQUIVALENCE. The check for this was in gfc_assign_data_value() in data.cc which turns out to be too late when trying to assign a zero sized array. Correction, the chunk in data.cc must remain for one test case. I spotted this after rerunning check-fortran for several variations. Attached patch is revised to include a new test case and adjustment of an existing test case. It also adds in a return MATCH_ERROR I accidentally left of the first submit when I was cleaning some things up. Ok for Mainline? the patch looks good to me, so ok for mainline. But please provide a commit message next time. Thanks, Harald Jeyy
Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
On 1/20/23 9:16 PM, Jerry D wrote:
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which
turns out to be too late when trying to assign a zero sized array.
Correction, the chunk in data.cc must remain for one test case. I
spotted this after rerunning check-fortran for several variations.
Attached patch is revised to include a new test case and adjustment of
an existing test case. It also adds in a return MATCH_ERROR I
accidentally left of the first submit when I was cleaning some things up.
Ok for Mainline?
Jeyy
diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
"array-element nor a scalar-structure-component";
symbol = lvalue->symtree->n.sym;
- if (symbol->attr.flavor == FL_PARAMETER)
-{
- gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
- symbol->name, >where);
- return false;
-}
-
init = symbol->value;
last_ts = >ts;
last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..28ce5fea865 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,8 +4076,14 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
gfc_error ("Named constant at %C in an EQUIVALENCE");
return MATCH_ERROR;
}
- /* Otherwise this is checked for and an error given in the
- variable definition context checks. */
+ if (gfc_in_match_data())
+ {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %C",
+ sym->name);
+ return MATCH_ERROR;
+ }
+ /* Otherwise this is checked for an error given in the
+ variable definition context checks. */
break;
case FL_PROCEDURE:
diff --git a/gcc/testsuite/gfortran.dg/parameter_data0.f90 b/gcc/testsuite/gfortran.dg/parameter_data0.f90
new file mode 100644
index 000..4f1da9ea42e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/parameter_data0.f90
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! PR fortran/102595 Similar to 88048 with a zero sized array
+program p
+ complex, parameter:: x(0) = 2
+ data x%im /3.0/ ! { dg-error "shall not appear in a DATA statement" }
+end
diff --git a/gcc/testsuite/gfortran.dg/pr88048.f90 b/gcc/testsuite/gfortran.dg/pr88048.f90
index 11293934330..ad82d45881c 100644
--- a/gcc/testsuite/gfortran.dg/pr88048.f90
+++ b/gcc/testsuite/gfortran.dg/pr88048.f90
@@ -2,6 +2,6 @@
! PR fortran/88048
program p
integer, parameter :: a(2) = 1
- data a(2) /a(1)/ ! { dg-error "definable entity" }
+ data a(2) /a(1)/ ! { dg-error "shall not appear in a DATA statement" }
print *, a
end
[pushed] wwwdocs: gcc-5: Adjust www.open-std.org links to https
Business as usual. Gerald --- htdocs/gcc-5/changes.html| 2 +- htdocs/gcc-5/porting_to.html | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/htdocs/gcc-5/changes.html b/htdocs/gcc-5/changes.html index f6742fb0..893e35de 100644 --- a/htdocs/gcc-5/changes.html +++ b/htdocs/gcc-5/changes.html @@ -417,7 +417,7 @@ void operator delete[] wwwdocs: (void *, std::size_t) noexcept; These warnings can be used at compile time, but they are more useful in combination with link-time optimization. G++ no longer supports - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html;>N3639 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html;>N3639 variable length arrays, as they were removed from the C++14 working paper prior to ratification. GNU VLAs are still supported, so VLA support is now the same in C++14 mode as in C++98 and C++11 modes. diff --git a/htdocs/gcc-5/porting_to.html b/htdocs/gcc-5/porting_to.html index b8942aa8..f2a831c4 100644 --- a/htdocs/gcc-5/porting_to.html +++ b/htdocs/gcc-5/porting_to.html @@ -380,7 +380,7 @@ For instance: Converting std::nullptr_t to bool in C++11 mode now requires direct-initialization. This has been changed in -http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423;>DR 1423. +https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423;>DR 1423. As a consequence, the following is invalid: @@ -400,7 +400,7 @@ converting nullptr to bool. Return by converting move constructor GCC 5 implements -http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579;>DR 1579 +https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579;>DR 1579 which means that when compiling a function like: -- 2.39.0
[PATCH] Darwin, fixincludes: Handle Apple Blocks in objc/runtime.h.
tested on i686-darwin9, x86_64-darwin19,20,21 x86_64-linux-gnu,
pushed to trunk, thanks
Iain
--- 8< ---
The macOS 13 SDK has unguarded Apple Blocks use in objc/runtime.h which
causes most of the objective-c tests to fail.
Signed-off-by: Iain Sandoe
fixincludes/ChangeLog:
* fixincl.x: Regenerate.
* inclhack.def (darwin_objc_runtime_1): New hack.
* tests/base/objc/runtime.h: New file.
---
fixincludes/fixincl.x | 63 ---
fixincludes/inclhack.def | 35 +++
fixincludes/tests/base/objc/runtime.h | 24 ++
3 files changed, 117 insertions(+), 5 deletions(-)
create mode 100644 fixincludes/tests/base/objc/runtime.h
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index ea879b73bad..b02dd8e0575 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1491,6 +1491,41 @@ fix = {
test_text = "typedef void (^os_trace_payload_t)(xpc_object_t xdict);";
};
+/*
+ * macOSX 13.0 SDK objc/runtime.h uses Apple Blocks extension without a guard.
+ */
+
+fix = {
+ hackname = darwin_objc_runtime_1;
+ mach = "*-*-darwin2*";
+ files = objc/runtime.h;
+ select= <<- _EOSelect_
+ OBJC_EXPORT void.*
+ objc_enumerateClasses.*
+ .*
+ .*
+ .*
+ .*void \(\^ _Nonnull block.*
+ .*
+ .*
+ .*OBJC_REFINED_FOR_SWIFT.*
+ _EOSelect_;
+ c_fix = format;
+ c_fix_arg = "#if __BLOCKS__\n%0\n#endif";
+ test_text = <<- _OBJC_RUNTIME_1
+OBJC_EXPORT void
+objc_enumerateClasses(const void * _Nullable image,
+ const char * _Nullable namePrefix,
+ Protocol * _Nullable conformingTo,
+ Class _Nullable subclassing,
+ void (^ _Nonnull block)(Class _Nonnull aClass, BOOL *
_Nonnull stop)
+ OBJC_NOESCAPE)
+OBJC_AVAILABLE(13.0, 16.0, 16.0, 9.0, 7.0)
+OBJC_REFINED_FOR_SWIFT;
+_OBJC_RUNTIME_1;
+};
+
+
/*
* In Mac OS X 10.1[012] , need to guard users of
* os_trace_payload_t typedef, too.
diff --git a/fixincludes/tests/base/objc/runtime.h
b/fixincludes/tests/base/objc/runtime.h
new file mode 100644
index 000..8b4855bb8ab
--- /dev/null
+++ b/fixincludes/tests/base/objc/runtime.h
@@ -0,0 +1,24 @@
+/* DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+ "fixinc/tests/inc/objc/runtime.h"
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file. */
+
+
+
+#if defined( DARWIN_OBJC_RUNTIME_1_CHECK )
+#if __BLOCKS__
+OBJC_EXPORT void
+objc_enumerateClasses(const void * _Nullable image,
+ const char * _Nullable namePrefix,
+ Protocol * _Nullable conformingTo,
+ Class _Nullable subclassing,
+ void (^ _Nonnull block)(Class _Nonnull aClass, BOOL *
_Nonnull stop)
+ OBJC_NOESCAPE)
+OBJC_AVAILABLE(13.0, 16.0, 16.0, 9.0, 7.0)
+OBJC_REFINED_FOR_SWIFT;
+#endif
+#endif /* DARWIN_OBJC_RUNTIME_1_CHECK */
--
2.37.1 (Apple Git-137.1)
[pushed] Darwin, fixincludes: Handle MacOS13 SDK Apple-specific deprecations [PR107586].
tested on i688-darwin9, x86_64-darwin20,21 and x86_64-linux-gnu.
pushed to trunk, thanks
Iain
--- 8< ---
The SDK for MacOS13 includes Apple-specific deprecations of some functions that
are not deprecated in Posix, C or C++ and widely used in GCC.
The fix makes the deprecation conditional on __APPLE_LOCAL_DEPRECATIONS so that
end users may still observe them but they are hidden from normal compilations.
Signed-off-by: Iain Sandoe
PR target/107568
fixincludes/ChangeLog:
* fixincl.x: Regenerate.
* inclhack.def: Add a fix for MacOS13 SDK function deprecations
in stdio.h.
* tests/base/stdio.h (__deprecated_msg): New test.
---
fixincludes/fixincl.x | 56 +++---
fixincludes/inclhack.def | 12
fixincludes/tests/base/stdio.h | 7 +
3 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index 20867548e24..35167dc82a8 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 September 29, 2022 at 10:22:55 PM by AutoGen 5.18.16
+ * It has been AutoGen-ed January 18, 2023 at 07:54:50 PM by AutoGen 5.18.7
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Sep 29 22:22:55 CEST 2022
+/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Jan 18 19:54:50 GMT 2023
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -15,7 +15,7 @@
* certain ANSI-incompatible system header files which are fixed to work
* correctly with ANSI C and placed in a directory that GNU C will search.
*
- * This file contains 272 fixup descriptions.
+ * This file contains 273 fixup descriptions.
*
* See README for more information.
*
@@ -2608,6 +2608,46 @@ static const char* apzBsd_Stdio_Attrs_ConflictPatch[] = {
int vfscanf(FILE *, const char *, __builtin_va_list) __asm__
(_BSD_STRING(__USER_LABEL_PREFIX__) \"__svfscanf\");",
(char*)NULL };
+/* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
+ * Description of Apple_Local_Stdio_Fn_Deprecation fix
+ */
+tSCC zApple_Local_Stdio_Fn_DeprecationName[] =
+ "apple_local_stdio_fn_deprecation";
+
+/*
+ * File name selection pattern
+ */
+tSCC zApple_Local_Stdio_Fn_DeprecationList[] =
+ "stdio.h\0";
+/*
+ * Machine/OS name selection pattern
+ */
+tSCC* apzApple_Local_Stdio_Fn_DeprecationMachs[] = {
+"*-*-*darwin2*",
+(const char*)NULL };
+
+/*
+ * content selection pattern - do fix if pattern found
+ */
+tSCC zApple_Local_Stdio_Fn_DeprecationSelect0[] =
+ "__deprecated_msg([^\n\
+]*)$";
+
+#defineAPPLE_LOCAL_STDIO_FN_DEPRECATION_TEST_CT 1
+static tTestDesc aApple_Local_Stdio_Fn_DeprecationTests[] = {
+ { TT_EGREP,zApple_Local_Stdio_Fn_DeprecationSelect0, (regex_t*)NULL }, };
+
+/*
+ * Fix Command Arguments for Apple_Local_Stdio_Fn_Deprecation
+ */
+static const char* apzApple_Local_Stdio_Fn_DeprecationPatch[] = {
+"format",
+"#if defined(__APPLE_LOCAL_DEPRECATIONS)\n\
+%0\n\
+#endif",
+(char*)NULL };
+
/* * * * * * * * * * * * * * * * * * * * * * * * * *
*
* Description of Ctrl_Quotes_Def fix
@@ -11075,9 +5,9 @@ static const char* apzX11_SprintfPatch[] = {
*
* List of all fixes
*/
-#define REGEX_COUNT 310
+#define REGEX_COUNT 311
#define MACH_LIST_SIZE_LIMIT 187
-#define FIX_COUNT272
+#define FIX_COUNT273
/*
* Enumerate the fixes
@@ -11144,6 +11184,7 @@ typedef enum {
BROKEN_CABS_FIXIDX,
BROKEN_NAN_FIXIDX,
BSD_STDIO_ATTRS_CONFLICT_FIXIDX,
+APPLE_LOCAL_STDIO_FN_DEPRECATION_FIXIDX,
CTRL_QUOTES_DEF_FIXIDX,
CTRL_QUOTES_USE_FIXIDX,
CXX_UNREADY_FIXIDX,
@@ -11663,6 +11704,11 @@ tFixDesc fixDescList[ FIX_COUNT ] = {
BSD_STDIO_ATTRS_CONFLICT_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
aBsd_Stdio_Attrs_ConflictTests, apzBsd_Stdio_Attrs_ConflictPatch, 0 },
+ { zApple_Local_Stdio_Fn_DeprecationName,
zApple_Local_Stdio_Fn_DeprecationList,
+ apzApple_Local_Stdio_Fn_DeprecationMachs,
+ APPLE_LOCAL_STDIO_FN_DEPRECATION_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
+ aApple_Local_Stdio_Fn_DeprecationTests,
apzApple_Local_Stdio_Fn_DeprecationPatch, 0 },
+
{ zCtrl_Quotes_DefName,zCtrl_Quotes_DefList,
apzCtrl_Quotes_DefMachs,
CTRL_QUOTES_DEF_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index d4637470d7a..ea879b73bad 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1269,6 +1269,18 @@ fix = {
test_text = '#define vfscanf __svfscanf';
};
+fix = {
+hackname = apple_local_stdio_fn_deprecation;
+mach = "*-*-*darwin2*";
+files = stdio.h;
+select= "__deprecated_msg([^\n]*)$";
+c_fix = format;
+c_fix_arg = "#if defined(__APPLE_LOCAL_DEPRECATIONS)\n"
Re: libquadmath fix for 94756 and 87204
hello Jakub, The above looks way too complicated for what it does. If all you want to change mp_limb* to be long long for mingw 64-bit, then just do: done. Why? could you explain which of the nine lines are you talking about? As for the rest, it would help if you could list the exact glibc commits which you've ported to libquadmath and indicate if it is solely those and nothing else. I'm sorry but it was not my intention to remember exactly which commits I was looking at... I didn't think about it. The patch needs a ChangeLog entry too. done. the patch in attachments. From 1d096d1c002533a1685599fd7f8b1ef506aae674 Mon Sep 17 00:00:00 2001 From: niXman Date: Sat, 21 Jan 2023 18:15:23 +0200 Subject: [PATCH] used type for MinGW target for x86_64 & the overflow described on BugZilla 94756 was fixed --- libquadmath/printf/gmp-impl.h | 25 + libquadmath/strtod/strtod_l.c | 29 + 2 files changed, 34 insertions(+), 20 deletions(-) diff --git a/libquadmath/printf/gmp-impl.h b/libquadmath/printf/gmp-impl.h index 94d88efc57f..b7f8e70f5b1 100644 --- a/libquadmath/printf/gmp-impl.h +++ b/libquadmath/printf/gmp-impl.h @@ -33,15 +33,24 @@ MA 02111-1307, USA. */ #define MAX(h,i) ((h) > (i) ? (h) : (i)) #endif -#define BITS_PER_MP_LIMB (__SIZEOF_LONG__ * __CHAR_BIT__) -#define BYTES_PER_MP_LIMB (BITS_PER_MP_LIMB / __CHAR_BIT__) -typedef unsigned long int mp_limb_t; -typedef long int mp_limb_signed_t; +#ifdef __MINGW32__ && defined(__x86_64__) + /* for MinGW targets the Microsoft ABI requires that `long` + type will always have 32 bit, because of that we will use + `long long` for MinGW on 64-bit builds */ + typedef long long int mp_limb_signed_t; + typedef unsigned long long int mp_limb_t; +# define BITS_PER_MP_LIMB (__SIZEOF_LONG_LONG__ * __CHAR_BIT__) +#else // !__MINGW32__ + typedef long int mp_limb_signed_t; + typedef unsigned long int mp_limb_t; +# define BITS_PER_MP_LIMB (__SIZEOF_LONG__ * __CHAR_BIT__) +#endif // __MINGW32__ -typedef mp_limb_t * mp_ptr; -typedef const mp_limb_t * mp_srcptr; -typedef long intmp_size_t; -typedef long intmp_exp_t; +#define BYTES_PER_MP_LIMB (BITS_PER_MP_LIMB / __CHAR_BIT__) +typedef mp_limb_t*mp_ptr; +typedef const mp_limb_t *mp_srcptr; +typedef long int mp_size_t; +typedef long int mp_exp_t; /* Define stuff for longlong.h. */ typedef unsigned int UQItype __attribute__ ((mode (QI))); diff --git a/libquadmath/strtod/strtod_l.c b/libquadmath/strtod/strtod_l.c index 0b0e85a3cf7..6790124e6fc 100644 --- a/libquadmath/strtod/strtod_l.c +++ b/libquadmath/strtod/strtod_l.c @@ -200,7 +200,7 @@ round_and_return (mp_limb_t *retval, intmax_t exponent, int negative, round_limb = retval[RETURN_LIMB_SIZE - 1]; round_bit = (MANT_DIG - 1) % BITS_PER_MP_LIMB; - for (i = 0; i < RETURN_LIMB_SIZE; ++i) + for (i = 0; i < RETURN_LIMB_SIZE - 1; ++i) more_bits |= retval[i] != 0; MPN_ZERO (retval, RETURN_LIMB_SIZE); } @@ -215,9 +215,14 @@ round_and_return (mp_limb_t *retval, intmax_t exponent, int negative, more_bits |= ((round_limb & mp_limb_t) 1) << round_bit) - 1)) != 0); - (void) mpn_rshift (retval, [shift / BITS_PER_MP_LIMB], - RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB), - shift % BITS_PER_MP_LIMB); +/* mpn_rshift requires 0 < shift < BITS_PER_MP_LIMB. */ +if ((shift % BITS_PER_MP_LIMB) != 0) + (void) mpn_rshift (retval, [shift / BITS_PER_MP_LIMB], + RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB), + shift % BITS_PER_MP_LIMB); +else + for (i = 0; i < RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB); i++) +retval[i] = retval[i + (shift / BITS_PER_MP_LIMB)]; MPN_ZERO ([RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB)], shift / BITS_PER_MP_LIMB); } @@ -276,7 +281,7 @@ round_and_return (mp_limb_t *retval, intmax_t exponent, int negative, } } - if (exponent > MAX_EXP) + if (exponent >= MAX_EXP) goto overflow; #ifdef HAVE_FENV_H @@ -308,7 +313,7 @@ round_and_return (mp_limb_t *retval, intmax_t exponent, int negative, } #endif - if (exponent > MAX_EXP) + if (exponent >= MAX_EXP) overflow: return overflow_value (negative); @@ -688,7 +693,7 @@ STRTOF_INTERNAL (nptr, endptr, group) if (endptr != NULL) *endptr = (STRING_TYPE *) cp; - return retval; + return negative ? -retval : retval; } /* It is really a text we do not recognize. */ @@ -1193,7 +1198,7 @@ STRTOF_INTERNAL (nptr, endptr, group) if (__builtin_expect (exponent > MAX_10_EXP + 1 - (intmax_t) int_no, 0)) return overflow_value (negative); - if (__builtin_expect (exponent < MIN_10_EXP - (DIG + 1), 0)) + if (__builtin_expect (exponent < MIN_10_EXP - (DIG + 2), 0)) return underflow_value (negative);
Re: [Patch] install.texi: Bump newlib version for nvptx + gcn
Hi Gerald,
On 21.01.23 12:58, Gerald Pfeifer wrote:
Is it maybe a little tough to bump the minimal requirement to something
only released yesterday? Or is this not an issue looking at the use cases?
(Genuine question. Maybe nothing to worry at all.)
On the technical side, the newer newlib version is not yet required. But
it looks as if it soon makes a lot of sense to have it:
For the AMGCN stack builtins, they currently expand to the same registers
and offset calculations as hard-coded in newlib (older version or if the
builtin is not available). – If the stack allocation is changed to
non-threadprivate, this will change the location. With the builtins, just
recompiling newlib (+libgomp) will work (API preserved but not ABI).
[Andrew to provide the stack patch; then me for the 2-line patch to enable
OpenMP's reverse offload.]
(Hen-egg problem in terms of compilation as newlib is compiled by GCC.
Probably only detectable by running it on the offload device and checking
whether it fails - not practical for a cross-compiler build.)
For AMDGCN's vectorization functions: Those can lead to a significant
performance
advantage. I know that newlib only used some builtins if they are available.
I think AMDGCN will emit code using the new libm functions, which in turn
newlib only generates if GCC supports certain new builtins. (hen-egg problem,
if my assumptions are correct.)
[I think Kwok will provide this patch - he did implement the funcs in newlib.]
nvptx: Thomas' patch for libgfortran(*) effectively requires the newer newlib -
albeit one could imaging that there could be a configure check.
[(*) "nvptx, libgfortran: Switch out of "minimal" mode",
approved but awaiting approval of another patch)]
Thus:
As nvptx/amdgcn is (mostly) about offloading code, newlib is compiled usually
alongside
GCC (e.g. in SUSE, Debian/Ubuntu, ...); additionally, there is static linking
such that
mixing old vs. new libraries is less likely. Hence, requiring the newest
version of newlib
together with the newest compiler shouldn't be a problem in my opinion.
And the if documented now, it cannot be forgotten by the time the pending
patches get
committed... ;-)
And, this predates your patch, in one instance we refer to Newlib (upper
case9, in the other to newlib (lower case). Would it make sense to
converge to one?
Maybe, but the question is what to use? The project's webpage has on the first
page:
"patch submissions to Newlib" and "automate the testing of newlib".
As uppercase, we have:
gcc/d/implement-d.texi:@code{CRuntime_Newlib} is set when Newlib is the default
C library.
gcc/doc/install.texi:Use Newlib (4.3.0 or newer).
gcc/doc/invoke.texi:This option requires Newlib Nano IO, so GCC must be
configured with
gcc/doc/invoke.texi:Newlib.
gcc/doc/invoke.texi:Specify the PRU MCU variant to use. Check Newlib for the
exact list of
gcc/doc/sourcebuild.texi:Target supports Newlib.
gcc/doc/sourcebuild.texi:the code size of Newlib formatted I/O functions.
gcc/po/gcc.pot:"Newlib Nano IO."
(Add a missing "Requires " to complete the sentence.)
and as lowercase:
gcc/doc/install.texi:Specifies that @samp{newlib} is
gcc/doc/install.texi:@samp{newlib}.
gcc/doc/install.texi:RTEMS configurations, which currently use newlib. The
option is
denotes a configure argument.)
gcc/doc/invoke.texi:newlib board library linking. The default is
@code{or1ksim}.
gcc/doc/invoke.texi:select linker and preprocessor options for use with newlib.
gcc/doc/sourcebuild.texi:@item newlib
(Side remark: While some @sample{newlib} in install.texi refer to a value to
a configure argument, in the quote above it refers to the library itself.)
gcc/po/gcc.pot:msgid "Configure the newlib board specific runtime. The default is
or1ksim."
gcc/po/gcc.pot:"This used to select linker and preprocessor options for use with
newlib."
libstdc++-v3/doc/xml/manual/configure.xml: vintage (2.3 and newer), 'gnu'
is automatically selected. On newlib-based
libstdc++-v3/doc/xml/manual/configure.xml: systems
('--with_newlib=yes') and OpenBSD, 'newlib' is
libstdc++-v3/doc/xml/manual/evolution.xml:A new clocale model for newlib is
available.
Thoughts?
Thanks for the comments!
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Re: [committed] wwwdocs: readings: www.cmass.com is gone, remove
Hi Gaius, On Mon, 11 Apr 2022, Gaius Mulley wrote: >> Gaius, if you want to make changes to that section of readings.html, >> absolutely be free doing so (and I'll be happy help, too). > looks fine - sure how about adding: > > Modula 3 information > >http://www.modula3.org;>http://www.modula3.org > > > Modula 2 information > > href="https://freepages.modula2.org/intro.html#Modula2;>Information >https://www.nongnu.org/gm2/12/dialect.html;>Modula-2 > dialects > I noticed you have not pushed this. If you consider it useful, definitely go ahead. Gerald
Re: [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
On 21.01.23 13:48, Gerald Pfeifer wrote: Just one question: Does "all clauses are now accepted" refer to - all (as in 100% of possible clauses), or - all (as in a special kind of clause)? The former – besides the listed 'unified_shared_memory', 'unified_address' and 'reverse_offload' clauses, there are 'dynamic_allocators' and 'atomic_default_mem_order' which are handled in the compiler front end (by being ignored (always fulfilled) and by used its argument as default value, respectively). Thanks for the review. (I will commit/update the patch later.) Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
On Wed, 18 Jan 2023, Tobias Burnus wrote: > How about the following? I put the other change into its own bullet > point to be less confusing, completely rewording the remaining item and > mention reverse offload support. Thank you, Tobias, for the explanation and the updated patch. As Jakub said, this looks good to go (modulo his one note). Just one question: Does "all clauses are now accepted" refer to - all (as in 100% of possible clauses), or - all (as in a special kind of clause)? (Asking due to the wording in the original version of the patch which felt like the latter.) Gerald
Re: [Patch] install.texi: Bump newlib version for nvptx + gcn
On Sat, 21 Jan 2023, Tobias Burnus wrote: > A new newlib version has been realized yesterday: newlib-4.3.0 (yearly > snapshot) : > Comments? Suggestions? – If there are none, I intent to commit the patch > as obvious. Is it maybe a little tough to bump the minimal requirement to something only released yesterday? Or is this not an issue looking at the use cases? (Genuine question. Maybe nothing to worry at all.) And, this predates your patch, in one instance we refer to Newlib (upper case9, in the other to newlib (lower case). Would it make sense to converge to one? Not an objection to the patch - you are the expert - just two (naive) questions. Gerald
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
> Date: Sat, 21 Jan 2023 11:47:42 +0100 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Gabriel Ravier > > > On 1/21/23 05:05, Eli Zaretskii wrote: > >> Date: Fri, 20 Jan 2023 21:39:56 +0100 > >> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > >> From: Gabriel Ravier > >> > - using wide APIs with Windows is generally considered to be a best > practice, even when not strictly needed (and in this case I can't see > any problem with doing so, unless maybe we want to code to work with > Windows 95 or something like that...) > >>> There's no reason to forcibly break GDB on platforms where wide APIs > >>> are not available. > >> Are there even any platforms that have GetModuleHandleA but not > >> GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003 > >> are the first versions to support both of the APIs, so if this is > >> supposed to work on Windows 98, for instance, whether we're using > >> GetModuleHandleA or GetModuleHandleW won't matter. > > I'm not sure I follow the logic. A program that calls > > GetModuleHandleW will refuse to start on Windows that doesn't have > > that API. So any version before XP is automatically excluded the > > moment you use code which calls that API directly (i.e. not through a > > function pointer or somesuch). > A program that calls GetModuleHandleA will also refuse to start on > Windows if it doesn't have that API. The set of Windows versions that do > not have GetModuleHandleA is, according to MSDN, the same as the set of > Windows versions that do not have GetModuleHandleW. MSDN lies (because it wants to pretend that older versions don't exist). Try this much more useful site: http://winapi.freetechsecrets.com/win32/WIN32GetModuleHandle.htm
[pushed] wwwdocs: *: Consistent formatting around environment
Consistency in how things are formatted makes automated processing easier in case of future mass changes. Pushed. Gerald --- htdocs/benchmarks/index.html | 1 + htdocs/egcs-1.0/index.html | 2 ++ htdocs/egcs-1.1/index.html | 2 ++ 3 files changed, 5 insertions(+) diff --git a/htdocs/benchmarks/index.html b/htdocs/benchmarks/index.html index 6973dffc..6ccee355 100644 --- a/htdocs/benchmarks/index.html +++ b/htdocs/benchmarks/index.html @@ -1,5 +1,6 @@ + Benchmarking GCC diff --git a/htdocs/egcs-1.0/index.html b/htdocs/egcs-1.0/index.html index 7fd8dbbb..4e674440 100644 --- a/htdocs/egcs-1.0/index.html +++ b/htdocs/egcs-1.0/index.html @@ -1,10 +1,12 @@ + EGCS 1.0 https://gcc.gnu.org/gcc.css;> + EGCS 1.0 diff --git a/htdocs/egcs-1.1/index.html b/htdocs/egcs-1.1/index.html index 08674824..adeffd37 100644 --- a/htdocs/egcs-1.1/index.html +++ b/htdocs/egcs-1.1/index.html @@ -1,10 +1,12 @@ + EGCS 1.1 https://gcc.gnu.org/gcc.css;> + EGCS 1.1 -- 2.39.0
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
On 1/21/23 05:05, Eli Zaretskii wrote: Date: Fri, 20 Jan 2023 21:39:56 +0100 Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org From: Gabriel Ravier - using wide APIs with Windows is generally considered to be a best practice, even when not strictly needed (and in this case I can't see any problem with doing so, unless maybe we want to code to work with Windows 95 or something like that...) There's no reason to forcibly break GDB on platforms where wide APIs are not available. Are there even any platforms that have GetModuleHandleA but not GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003 are the first versions to support both of the APIs, so if this is supposed to work on Windows 98, for instance, whether we're using GetModuleHandleA or GetModuleHandleW won't matter. I'm not sure I follow the logic. A program that calls GetModuleHandleW will refuse to start on Windows that doesn't have that API. So any version before XP is automatically excluded the moment you use code which calls that API directly (i.e. not through a function pointer or somesuch). A program that calls GetModuleHandleA will also refuse to start on Windows if it doesn't have that API. The set of Windows versions that do not have GetModuleHandleA is, according to MSDN, the same as the set of Windows versions that do not have GetModuleHandleW.
[PATCH] c++: Handle structured bindings like anon unions in initializers [PR108474]
Hi!
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in static initializers.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
2023-01-21 Jakub Jelinek
PR c++/108474
* cp-gimplify.cc (cp_fold_r): Handle structured bindings
vars like anon union artificial vars.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
--- gcc/cp/cp-gimplify.cc.jj2023-01-19 23:27:27.998400866 +0100
+++ gcc/cp/cp-gimplify.cc 2023-01-20 11:00:06.093446737 +0100
@@ -1012,8 +1012,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtr
case VAR_DECL:
/* In initializers replace anon union artificial VAR_DECLs
-with their DECL_VALUE_EXPRs, as nothing will do it later. */
- if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize)
+with their DECL_VALUE_EXPRs, as nothing will do it later.
+Ditto for structured bindings. */
+ if (!data->genericize
+ && DECL_HAS_VALUE_EXPR_P (stmt)
+ && (DECL_ANON_UNION_VAR_P (stmt)
+ || (DECL_DECOMPOSITION_P (stmt) && DECL_DECOMP_BASE (stmt
{
*stmt_p = stmt = unshare_expr (DECL_VALUE_EXPR (stmt));
break;
--- gcc/testsuite/g++.dg/cpp1z/decomp57.C.jj2023-01-20 11:02:08.547656638
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp57.C 2023-01-20 10:53:01.781649565
+0100
@@ -0,0 +1,27 @@
+// PR c++/108474
+// { dg-do link { target c++17 } }
+
+struct T { int i, j; };
+T h;
+auto [i, j] = h;
+int = i;
+int s = i;
+int *t =
+
+void
+foo (int **p, int *q)
+{
+ static int = i;
+ static int v = i;
+ static int *w =
+ int = i;
+ int y = i;
+ int *z =
+ *p =
+ *q = i;
+}
+
+int
+main ()
+{
+}
--- gcc/testsuite/g++.dg/cpp1z/decomp58.C.jj2023-01-20 11:02:12.314601575
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp58.C 2023-01-20 10:54:02.117767542
+0100
@@ -0,0 +1,39 @@
+// PR c++/108474
+// { dg-do link { target c++17 } }
+
+namespace std {
+ template struct tuple_size;
+ template struct tuple_element;
+}
+
+struct A {
+ int i;
+ template int& get() { return i; }
+};
+
+template <> struct std::tuple_size { static const int value = 2; };
+template struct std::tuple_element { using type = int; };
+
+struct A a;
+auto [i, j] = a;
+int = i;
+int s = i;
+int *t =
+
+void
+foo (int **p, int *q)
+{
+ static int = i;
+ static int v = i;
+ static int *w =
+ int = i;
+ int y = i;
+ int *z =
+ *p =
+ *q = i;
+}
+
+int
+main ()
+{
+}
Jakub
[Patch] install.texi: Bump newlib version for nvptx + gcn
A new newlib version has been realized yesterday: newlib-4.3.0 (yearly snapshot)
https://sourceware.org/pipermail/newlib/2023/020141.html
https://sourceware.org/ftp/newlib/index.html → 2023-01-20:
newlib-4.3.0.20230120.tar.gz (8.8 MB)
For both nvptx and GCN, the new version is recommended - mostly because of
upcoming changes
and not because GCC mainline already needs them currently. But soon it will,
hence:
The attached patch bumps the minimal version instead of keeping the old version
and only
recommending the newer one.
Comments? Suggestions? – If there are none, I intent to commit the patch as
obvious.
Tobias
PS: For AMDGCN, the newlib uses (if available) some new builtins: one provided
by GCC 13
but having the currently same value as the hard coded registers that get used
if the builtin
s not available - to permit a change to non-private stack variables (required
for reverse offload;
will require recompilation of newlib).
And to support vectorized math functions. (The gcn builtins still have to be
added to GCC 13;
if the builtins aren't available, newlib won't use them - hence, also will
later require a
rebuild with the newer newlib).
For nvptx, newlib added some features to permit building a non-minimal version
of libgfortran,
which also permits I/O. The libgfortran changes have been approved but the GCC
nvptx patches
still have to be reviewed (and would also require a pending nvptx-tools pull
request).
BTW: The gcn vect math and the nvptx changes went into newlib in the last few
days. Thus, if
you have use the 'git' version it won't have the changes, unless you updated at
least yesterday.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
install.texi: Bump newlib version for nvptx + gcn
Before, newlib 3.2 was required for amdgcn and 3.1 for nvptx.
Now recommended is 4.3.0 which was just released on 2023-01-20.
While currently the old versions would work fine, upcoming GCC
changes depend on a newer newlib. Thus, the minimal version is
bumped instead of just recommending the new version.
For GCN, the bump is in preparation for permitting non-threadlocal
stack variables and vectorized math functions - both scheduled for
GCC 13 and added to newlib in 4.3.0.
For nvptx, this includes an emulated clock (commit 6bb96d13a),
a calloc fix (5fca4e0f1) and changes to permit libgfortran to be
compiled with I/O support instead of only in minimal mode.
(Patch approved for GCC 13 but pending on a nvtpx patch.)
gcc/ChangeLog:
* doc/install.texi (amdgcn, nvptx): Require newlib 4.3.0.
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index ccc8d15fd08..b1861a6a437 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3855,7 +3855,7 @@ Instead of GNU Binutils, you will need to install LLVM 13.0.1, or later, and cop
@file{bin/llvm-ar} to both @file{bin/amdgcn-amdhsa-ar} and
@file{bin/amdgcn-amdhsa-ranlib}.
-Use Newlib (3.2.0, or newer).
+Use Newlib (4.3.0 or newer).
To run the binaries, install the HSA Runtime from the
@uref{https://rocm.github.io,,ROCm Platform}, and use
@@ -4672,7 +4672,7 @@ Instead of GNU binutils, you will need to install
Tell GCC where to find it:
@option{--with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin}.
-You will need newlib 3.1.0 or later. It can be
+You will need newlib 4.3.0 or later. It can be
automatically built together with GCC@. For this, add a symbolic link
to nvptx-newlib's @file{newlib} directory to the directory containing
the GCC sources.
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
> Date: Sat, 21 Jan 2023 17:18:14 +0800 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: LIU Hao > > 在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道: > > I'm not sure I follow the logic. A program that calls > > GetModuleHandleW will refuse to start on Windows that doesn't have > > that API. So any version before XP is automatically excluded the > > moment you use code which calls that API directly (i.e. not through a > > function pointer or somesuch). > > Are _you_ still willing to maintain backward compatibility with Windows 9x? > Even mingw-w64 has been > defaulting to Windows Server 2003 since 2007. Why would anyone build a modern > compiler for such old > operating systems? I'm only saying that we should not deliberately break those old platforms unless we have a good reason. And I see no such good reason in this case: GetModuleHandleA will do the job exactly like GetModuleHandleW will. > With any Windows that is modern enough, wide APIs should always be preferred > to ANSI ones, > especially when the argument is constant. Almost all ANSI APIs (the only > exception I know of is > `OutputDebugStringA` which does the inverse) translate their ANSI string > arguments to wide strings > and delegate to wide ones, so by calling wide APIs explicitly, such overhead > can be avoided. The overhead is only relevant in code that is run in performance critical places. I don't think this is such a place.
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道: I'm not sure I follow the logic. A program that calls GetModuleHandleW will refuse to start on Windows that doesn't have that API. So any version before XP is automatically excluded the moment you use code which calls that API directly (i.e. not through a function pointer or somesuch). Are _you_ still willing to maintain backward compatibility with Windows 9x? Even mingw-w64 has been defaulting to Windows Server 2003 since 2007. Why would anyone build a modern compiler for such old operating systems? With any Windows that is modern enough, wide APIs should always be preferred to ANSI ones, especially when the argument is constant. Almost all ANSI APIs (the only exception I know of is `OutputDebugStringA` which does the inverse) translate their ANSI string arguments to wide strings and delegate to wide ones, so by calling wide APIs explicitly, such overhead can be avoided. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
