Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via
Gcc-bugs wrote:
>
>
> ++
> From: Puneet Kumar Yatnal (QUIC)
> Sent: Monday, April 17, 2023 9:26 AM
> To: gcc-h...@gcc.gnu.org
> Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact
> on time values
First gcc-bugs@ is not the right place to report a bug report as
gcc-bugs is mainly for automated emails from bugzilla. Please use
bugzilla first.
>
> All
>
> if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for
> Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit
> ), pthread_cond_timedwait function from gthr_posix.h is calling different
> function in pthrea_cond_wait.c of glibc(due to weakref of symbol
> pthread_cond_timedwait()) which impacting the time value.
Note libstdc++ does ABI changes too which is NOT part of that ABI design.
This is where the symbol
__gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So
any changes you might do to fix __gthrw_pthread_cond_timedwait is not
really going to work without wider ABI fixes to libstdc++.
I don't know any one who is making those changes/fixes. So you should
file an bug requesting it. And maybe even have a design document ready
for it. There are many/some classes which have timespec inside them
and not just the mutex related ones.
Thanks,
Andrew
>
> From pthread.h
> extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
> pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
> __abstime) __asm__ ("" "__pthread_cond_timedwait64")
>
> From gthread_posix.h:
> static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
> __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
> (pthread_cond_timedwait)));
>
>
> __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in
> glibc instead of __pthread_cond_timedwait64 which is impacting time value
> as __pthread_cond_timedwait is converting value from 32 bit to 64 bit.
>
> normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly
> and its working fine.
>
> From: pthread_cond_wait.c
>
> #if __TIMESIZE == 64
> strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
> #else
> strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
> libc_hidden_def (__pthread_cond_timedwait64)
>
> int
> ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
> const struct timespec *abstime)
> {
> struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
>
> return __pthread_cond_timedwait64 (cond, mutex, );
> }
> #endif /* __TIMESIZE == 64 */
> versioned_symbol (libc, ___pthread_cond_timedwait,
> pthread_cond_timedwait, GLIBC_2_3_2);
> libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
> #ifndef SHARED
> strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
> #endif
>
> if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved
> but that is not correct way as it disable weakref for all symbol, please let
> me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc
> and glibc 2.34
>
> Regards
> Puneet
>
RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
++
From: Puneet Kumar Yatnal (QUIC)
Sent: Monday, April 17, 2023 9:26 AM
To: gcc-h...@gcc.gnu.org
Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact on
time values
All
if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038
fix(where all timer related variable moved to 64 bit instead of 32 bit ),
pthread_cond_timedwait function from gthr_posix.h is calling different function
in pthrea_cond_wait.c of glibc(due to weakref of symbol
pthread_cond_timedwait()) which impacting the time value.
>From pthread.h
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
>From gthread_posix.h:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
__gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in
glibc instead of __pthread_cond_timedwait64 which is impacting time value as
__pthread_cond_timedwait is converting value from 32 bit to 64 bit.
normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly
and its working fine.
From: pthread_cond_wait.c
#if __TIMESIZE == 64
strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
#else
strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
libc_hidden_def (__pthread_cond_timedwait64)
int
___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
const struct timespec *abstime)
{
struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
return __pthread_cond_timedwait64 (cond, mutex, );
}
#endif /* __TIMESIZE == 64 */
versioned_symbol (libc, ___pthread_cond_timedwait,
pthread_cond_timedwait, GLIBC_2_3_2);
libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
#ifndef SHARED
strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
#endif
if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved
but that is not correct way as it disable weakref for all symbol, please let me
know what is correct way to fix this, this i observed with gcc-9.3.0 gcc and
glibc 2.34
Regards
Puneet
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #5 from Wilhelm M --- (In reply to Andrew Pinski from comment #4) > (In reply to Wilhelm M from comment #3) > > Isn't this a case where the as-if rule kicks in? > > What rule is that? Scopped enums are different from unscopped ones here > specifically as defined in the C++ standard. Ok, I see the point as the C++ standard nails down the type to int disallowing any as-if optimization. So in general a scoped-enum inside a class (nested type) maybe always a bad idea, because it prevents optimization. And when specifying the underlying type, the -fstrict-enums can't be applied because all values of the underlying type are possible.
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #4 from Andrew Pinski --- (In reply to Wilhelm M from comment #3) > Isn't this a case where the as-if rule kicks in? What rule is that? Scopped enums are different from unscopped ones here specifically as defined in the C++ standard.
[Bug c++/109531] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531 --- Comment #4 from Andrew Pinski --- Anyways I am trying to reduce this using delta with a script which tests if it passes no options (except -Wfatal-errors to speed up the testing); that should reduce it to a valid testcase I hope.
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #3 from Wilhelm M --- (In reply to Andrew Pinski from comment #2) > (In reply to Andrew Pinski from comment #1) > > That is because a scopped enum has an underlying type of int if not > > supplied. > > > > From [dcl.enum]/5: > > For a scoped enumeration type, the underlying type is int if it is not > > explicitly specified. > > I should say this is from the C++ standard there. > -fshort-enums does not change the language, only ABI. Isn't this a case where the as-if rule kicks in?
[Bug c++/109531] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531 --- Comment #3 from Andrew Pinski --- I almost want to say there is some GC issue going on with the original testcase. When I tried to use topformflat with the source (with all the "^# " lines removed), it no longer ICEs. But then again I did get a note about -flarge-source-files which might causing a warning not to be tried which is exposing the ICE.
[Bug rtl-optimization/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > That is because a scopped enum has an underlying type of int if not supplied. > > From [dcl.enum]/5: > For a scoped enumeration type, the underlying type is int if it is not > explicitly specified. I should say this is from the C++ standard there. -fshort-enums does not change the language, only ABI.
[Bug rtl-optimization/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- That is because a scopped enum has an underlying type of int if not supplied. >From [dcl.enum]/5: For a scoped enumeration type, the underlying type is int if it is not explicitly specified.
[Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
Bug ID: 109532
Summary: -fshort-enums does not pick smallest underlying type
for scoped enum
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
In the follwoing code, the best code with 8-bit underlying for the enum-type is
only optimized for unscoped enum.
The scoped enum always produces a 16-bit enum underlying type.
Compile with: -Os -mmcu=atmega328 -fshort-enums
(note: equivalent C code (unscoped enums) produces optimal code with
-fshort-enums)
#include
#include
volatile uint8_t o;
struct FSM {
//enum class State : uint8_t {A, B, C, D};// <2> 8bit enum
//enum State {A, B, C, D};// <3> 8bit enum with
-fshort-enums
enum class State {A, B, C, D};// <1> 16bit enum with
-fshort-enums
static void f() __attribute__((noinline)) {
switch(mState) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
case State::D:
o = 13;
break;
}
}
private:
inline static State mState{State::A};
};
int main() {
while(true) {
FSM::f();
}
}
[Bug c++/109531] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531 --- Comment #2 from Andrew Pinski --- command line that in the end needed to reproduce with the original non-reduced testcase: -std=c++14 -march=znver3 -O2 -fno-strict-aliasing -Wall Note you need all of those options to get the ICE.
[Bug sanitizer/109489] [ubsan] Support -fsanitize-trap=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 --- Comment #2 from Andrew Pinski --- r13-1164-g2c7cfc7b418564
[Bug pch/91440] Precompiled headers don't work with ASLR on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440 David Fong changed: What|Removed |Added CC||davidfong19 at gmail dot com --- Comment #10 from David Fong --- Related on Stack Overflow: https://stackoverflow.com/a/76030171/11107541
[Bug sanitizer/109489] [ubsan] Support -fsanitize-trap=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109489 Fangrui Song changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- This has been implemented in https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2c7cfc7b418564a2f1f0e7a5b38dec7013ba5e18 (2022-06). Sorry that I did not check the trunk GCC. https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html says "The -fsanitize-undefined-trap-on-error option is deprecated equivalent of -fsanitize-trap=all." (as expected).
[Bug c++/109531] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531 --- Comment #1 from Sam James --- Created attachment 54873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54873=edit invalid_reduction.ii meh, the reduction cvise just finished with is invalid, but it does trigger the ICE still. I'll include it and try refine it now.
[Bug c++/109531] New: Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531 Bug ID: 109531 Summary: Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 54872 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54872=edit ArithmeticSubtermGeneralization.ii.orig.xz Hit this with vampire-4.7: ``` $ /usr/bin/x86_64-pc-linux-gnu-g++ -DCHECK_LEAKS=0 -DVDEBUG=0 -DVZ3=1 -I/var/tmp/portage/sci-mathematics/vampire-4.7-r1/work/vampire-2d02e4655e1b08d1ca9ee7c0aade40f59f046460 -O2 -march=znver3 -pipe -U_GLIBCXX_ASSERTIONS -U_FORTIFY_SOURCE -fno-strict-aliasing -std=c++14 -fdiagnostics-color=always -Wall -c /var/tmp/portage/sci-mathematics/vampire-4.7-r1/work/vampire-2d02e4655e1b08d1ca9ee7c0aade40f59f046460/Inferences/ArithmeticSubtermGeneralization.cpp hash table checking failed: equal operator returns true for a pair of values with a different hash value [... warning output ...] /var/tmp/portage/sci-mathematics/vampire-4.7-r1/work/vampire-2d02e4655e1b08d1ca9ee7c0aade40f59f046460/Lib/Metaiterators.hpp:1787:19: internal compiler error: in hashtab_chk_error, at hash-table.cc:137 1787 | Container collect() | ^~~ 0x18f8915 hashtab_chk_error() /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/hash-table.cc:137 0x67cd7a hash_table::verify(tree_node* const&, unsigned int) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/hash-table.h:1118 0x67cd7a hash_table::find_slot_with_hash(tree_node* const&, unsigned int, insert_option) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/hash-table.h:1046 0x67cd7a hash_table::find_slot(tree_node* const&, insert_option) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/hash-table.h:435 0x67cd7a canonical_type_parameter(tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:4536 0x1d69d7f tsubst(tree_node*, tree_node*, int, tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:16298 0x1e7d600 tsubst_function_type /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:15649 0x1d689e9 tsubst(tree_node*, tree_node*, int, tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:16468 0x1e7a865 tsubst_function_decl /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:14419 0x202b236 tsubst_template_decl /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:14730 0x1e5be82 tsubst_decl /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:14892 0x1e72315 instantiate_class_template(tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:12338 0x1aa8568 complete_type(tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/typeck.cc:138 0x1aa8402 complete_type_or_maybe_complain(tree_node*, tree_node*, int) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/typeck.cc:151 0x1cab4b2 require_complete_type(tree_node*, int) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/typeck.cc:94 0x1ca483e build_cxx_call(tree_node*, int, tree_node**, int, tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/call.cc:10981 0x84ef64 build_over_call /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/call.cc:10432 0x1d91d09 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/call.cc:11703 0x1df5802 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:21314 0x1e1a540 tsubst_expr(tree_node*, tree_node*, int, tree_node*) /usr/src/debug/sys-devel/gcc-13.0.1_pre20230416/gcc-13-20230416/gcc/cp/pt.cc:19888 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` 'g++-13 -O2 -Wall -c ArithmeticSubtermGeneralization.ii' is enough to reproduce. Reduction in progress.
[Bug testsuite/108809] gcc.target/powerpc/builtins-5-p9-runnable.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809 --- Comment #4 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:a1f25e04b8d10bbe5dcaf98bb7e17cdaec9f169d commit r13-7202-ga1f25e04b8d10bbe5dcaf98bb7e17cdaec9f169d Author: Jiufu Guo Date: Fri Apr 14 10:50:28 2023 +0800 testsuite: update builtins-5-p9-runnable.c for BE Hi, As PR108809 mentioned, vec_xl_len_r and vec_xst_len_r are tested in gcc.target/powerpc/builtins-5-p9-runnable.c. The vector operand of these two bifs are different from the view of v16_int8 between BE and LE, even it is same from the view of 128bits(uint128/V1TI). The test case gcc.target/powerpc/builtins-5-p9-runnable.c was written for LE environment, this patch updates it for BE. Tested on ppc64 BE and LE. Is this ok for trunk? BR, Jeff (Jiufu) gcc/testsuite/ChangeLog: PR testsuite/108809 * gcc.target/powerpc/builtins-5-p9-runnable.c: Update for BE.
[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68994 --- Comment #13 from Andrew Pinski --- (In reply to Sam James from comment #11) > Came across this because Clang has this warning for -pedantic but GCC > doesn't. GCC removed the pedwarning on purpose (between GCC 4.1 and 4.4), see PR 14331 and PR 68994. https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html is the specific one about GCC's behavior and since it is considered undefined at compile time (not a runtime one) GCC behavior is correct so is clang
[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745 --- Comment #12 from Sam James --- (In reply to Sam James from comment #11) > C99 seems to explicitly say, within Clause J.2, in the second bullet point: This seems to be in C23 still.
[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745 --- Comment #11 from Sam James --- C99 seems to explicitly say, within Clause J.2, in the second bullet point: > >1 The behavior is undefined in the following circumstances: > >[...] >A nonempty source file does not end in a new-line character which is not > >immediately preceded by a backslash character or ends in a partial > >preprocessing token or comment (5.1.1.2). Came across this because Clang has this warning for -pedantic but GCC doesn't.
[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
--- Comment #3 from Andreas Schwab ---
"\.data" is the same as ".data", you want either "\\.data" or {\.data}. But it
still doesn't lower the probability to match a filename by much.
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #11 from Wilhelm M --- Without an underlying type but with -fshort-enums the underlying type should be as small as possible. In this case this should be a uint8_t. But in this case we get a 16-bit value for mState. This is a clear violation of -fshort-enums.
[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-04-16
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from anlauf at gcc dot gnu.org ---
We should adjust the scan strings to avoid collisons with file paths:
diff --git a/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
b/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
index f96ebc499e8..e38953bd777 100644
--- a/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
+++ b/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
@@ -107,4 +107,4 @@ contains
end function bar
end program alloc_fun
-! { dg-final { scan-tree-dump-times "free" 10 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_free " 10 "original" } }
diff --git a/gcc/testsuite/gfortran.dg/reshape_8.f90
b/gcc/testsuite/gfortran.dg/reshape_8.f90
index 01799ac5c19..03861fb26df 100644
--- a/gcc/testsuite/gfortran.dg/reshape_8.f90
+++ b/gcc/testsuite/gfortran.dg/reshape_8.f90
@@ -11,4 +11,4 @@ program test
a = reshape([1,2,3,4], [2,0])
print *, a
end
-! { dg-final { scan-tree-dump-times "data" 4 "original" } }
+! { dg-final { scan-tree-dump-times "\.data" 4 "original" } }
[Bug testsuite/83904] gfortran.dg allocatable_function_1 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2023-04-16
--- Comment #1 from anlauf at gcc dot gnu.org ---
The quickest solution would indeed be:
diff --git a/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
b/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
index f96ebc499e8..e38953bd777 100644
--- a/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
+++ b/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
@@ -107,4 +107,4 @@ contains
end function bar
end program alloc_fun
-! { dg-final { scan-tree-dump-times "free" 10 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_free " 10 "original" } }
[Bug target/109280] Very significant increase in code size (gcc-avr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109280 --- Comment #3 from Georg-Johann Lay --- Could you check against avr-gcc v12.3 just to make sure you didn't hit PR90706 (which affects all versiond from v9 to v12.2).
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #9 from anlauf at gcc dot gnu.org --- The following patch rejects the code in comment#0 and regtests ok: diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc index e9843e9549c..64a54c06800 100644 --- a/gcc/fortran/interface.cc +++ b/gcc/fortran/interface.cc @@ -2195,6 +2214,8 @@ compare_allocatable (gfc_symbol *formal, gfc_expr *actual) return true; else if (!attr.allocatable) return false; + else if (actual->expr_type != EXPR_VARIABLE) + return false; } return true;
[Bug fortran/109511] incorrectly rejects set_exponent with constant negative exponent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.5 Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13, and on all open branches. Closing. Thanks for the report!
[Bug fortran/109511] incorrectly rejects set_exponent with constant negative exponent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:dd2cd1e70509aaeb3db3e7b322d8357bac817632 commit r10-11289-gdd2cd1e70509aaeb3db3e7b322d8357bac817632 Author: Harald Anlauf Date: Fri Apr 14 20:45:19 2023 +0200 Fortran: fix compile-time simplification of SET_EXPONENT [PR109511] gcc/fortran/ChangeLog: PR fortran/109511 * simplify.c (gfc_simplify_set_exponent): Fix implementation of compile-time simplification of intrinsic SET_EXPONENT for argument X < 1 and for I < 0. gcc/testsuite/ChangeLog: PR fortran/109511 * gfortran.dg/set_exponent_1.f90: New test. (cherry picked from commit fa4cb42870df60debdbd51e2ddc6d6ab9e6a)
[Bug fortran/109511] incorrectly rejects set_exponent with constant negative exponent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:dfcdb457c462b9e35eb54d3b758221a119067e24 commit r11-10625-gdfcdb457c462b9e35eb54d3b758221a119067e24 Author: Harald Anlauf Date: Fri Apr 14 20:45:19 2023 +0200 Fortran: fix compile-time simplification of SET_EXPONENT [PR109511] gcc/fortran/ChangeLog: PR fortran/109511 * simplify.c (gfc_simplify_set_exponent): Fix implementation of compile-time simplification of intrinsic SET_EXPONENT for argument X < 1 and for I < 0. gcc/testsuite/ChangeLog: PR fortran/109511 * gfortran.dg/set_exponent_1.f90: New test. (cherry picked from commit fa4cb42870df60debdbd51e2ddc6d6ab9e6a)
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 --- Comment #14 from Richard Smith --- If I understand correctly, you're looking for documentation that __builtin_operator_new(size) has the exact same semantics and permits the same optimizations as `::new T` for a trivially-constructible non-array type `T` whose size is `size` and that __builtin_operator_delete(p) has the exact same semantics and permits the same optimizations as `::delete p` for a trivially-destructible non-array type `T` whose size is `size`, with `p` of type `T*` -- and similarly for the other (aligned, nothrow) variants? That is the intent; I can look into getting Clang's documentation updated to say that more explicitly if that's useful to you.
[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 Andrew Pinski changed: What|Removed |Added Depends on||59424 --- Comment #4 from Andrew Pinski --- The patch which fixes PR 59424 also fixes this one. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59424 [Bug 59424] Optimization issue on min/max
[Bug c++/105804] coroutines: List-initialized argument in await expression is doubly freed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105804 Alfred Agrell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Alfred Agrell --- Looks like this one was fixed at some point. Probably by commit r13-6702-gea4dd8f512979db247c54d6b41377bb73699bcd7, as reported in bug 103871. Good job, GCC team.
[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 Wilhelm M changed: What|Removed |Added CC||klaus.doldinger64@googlemai ||l.com --- Comment #5 from Wilhelm M --- (In reply to Roger Sayle from comment #4) > Created attachment 54871 [details] > proposed patch > > Proposed patch, using a peephole2 in avr-dimode.md to inline calls to > __lshrdi3 that require only a single instruction or two (due to truncation). > For truncations to char, this is smaller and faster, and for truncations to > unsigned short this is the same size, but faster. The drawback is that > performing this late (in peephole2) doesn't eliminate the stack frame > prolog/epilog. Thoughts? Looks good to me. Many thanks!
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-04-16 CC||ppalka at gcc dot gnu.org
[Bug target/109508] [13 Regression] ICE: in extract_insn, at recog.cc:2791 with -mcpu=sifive-s76 on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/109508] [13 Regression] ICE: in extract_insn, at recog.cc:2791 with -mcpu=sifive-s76 on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508 --- Comment #2 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:a647198fcf7463a42c8e035a429200e7998735dc commit r13-7198-ga647198fcf7463a42c8e035a429200e7998735dc Author: Jeff Law Date: Sun Apr 16 09:55:32 2023 -0600 [committed] [PR target/109508] Adjust conditional move expansion for SFB Recently the conditional move expander's predicates were loosened for the benefit of the THEAD processors. In particular one operand that was previously "register_operand" is now "reg_or_0_operand". That's fine for THEAD, but breaks for SFB which requires a register for that operand. This results in an ICE when compiling the testcase an SFB target such as the sifive s76. This change adjusts the expansion code slightly to copy the value into a register for SFB. Bootstrapped and regression tested (c,c++,fortran only) with a toolchain configured to enable SFB by default. PR target/109508 gcc/ * config/riscv/riscv.cc (riscv_expand_conditional_move): For TARGET_SFB_ALU, force the true arm into a register. gcc/testsuite * gcc.target/riscv/pr109508.c: New test.
[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Created attachment 54871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54871=edit proposed patch Proposed patch, using a peephole2 in avr-dimode.md to inline calls to __lshrdi3 that require only a single instruction or two (due to truncation). For truncations to char, this is smaller and faster, and for truncations to unsigned short this is the same size, but faster. The drawback is that performing this late (in peephole2) doesn't eliminate the stack frame prolog/epilog. Thoughts?
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816 Roger Sayle changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Roger Sayle --- This is now fixed on mainline [but was present in GCC 12.2], and a new test case added to ensure this stays fixed.
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816 --- Comment #4 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:f006d1a5a1e136be29c78b96c8742ebd3710f4d0 commit r13-7197-gf006d1a5a1e136be29c78b96c8742ebd3710f4d0 Author: Roger Sayle Date: Sun Apr 16 13:03:10 2023 +0100 [Committed] New test case gcc.target/avr/pr54816.c PR target/54816 is now fixed on mainline. This adds a test case to check that it doesn't regress in future. Tested with a cross compiler to avr-elf. Committed as obvious. 2023-04-16 Roger Sayle gcc/testsuite/ChangeLog PR target/54816 * gcc.target/avr/pr54816.c: New test case.
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #7 from Lisp2D --- .. or int volatile && rx = static_cast < int volatile && > ( x ) ; fun(rx);
[Bug c++/101557] the value of '' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #5 from Federico Kircheis ---
Today I just found a possible workaround that involves macros and lambdas...
struct node {
const char* d;
const node& left;
};
#define LEAF(a) []()-> const node&{ constexpr static auto a = node{"a",Null};
return a; }()
#define NODE(a,b) []()-> const node&{constexpr static auto a = node{"a",b};
return a; }()
constexpr node Null = node{"",Null};
constexpr auto a = node{"a",NODE(a,LEAF(b))};
constexpr auto a2 = node{"a",node{"a", node{"a", Null}}};
constexpr int mysize(const node& n) noexcept{
return ( == ) ? 0 : 1 + mysize(n.left);
}
constexpr auto size0 = mysize(Null);
static_assert(size0 == 0, "");
constexpr auto size3 = mysize(a);
static_assert(size3 == 3, "");
"mysize(a)" compiles, while "mysize(a2)" does not, even if the two
datastructures are equivalent
Unfortunately clang does not accept it
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #6 from Lisp2D --- (In reply to Andrew Pinski from comment #4) > https://stackoverflow.com/questions/40193008/why-a-const-volatile-reference- stackoverflow offers to link an rvalue reference to a variable for this. But I think this is historical stupidity. int volatile && rx = static_cast < int volatile && > ( x ) ; int volatile const & lx = rx ; fun(lx);
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #5 from Andrew Pinski --- Basically [dcl.init.ref]/5 .
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #5 from Bálint Aradi --- I also think that by allowing for explicit EORs caused by achar(10) characters in the variable being written or by explicit new_line() calls, the standard made the formatted stream output probably more complicated then it is worth of. And the fact that apparently none of the widely used compilers handle those cases correctly, also indicates over-complication. However, I still think, that formatted stream output has its justification, as it allows you to become independent from record length limits, which are set up when a file is opened and which can not be adapted afterwards. We had been hit by run-time errors a few times, when the character variable being written turned out to be too big. (Of course, one could do unformatted stream output instead, but then one always have to think about adding the newlines manually at the end of each line...)
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #4 from Andrew Pinski --- https://stackoverflow.com/questions/40193008/why-a-const-volatile-reference-cannot-be-bound-to-an-rvalue-reference
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #3 from Lisp2D --- (In reply to Andrew Pinski from comment #2) > Since `static_cast(x)` is considered rvalue and `int I can't find a reason anywhere in the standard why the volatile property prevents conversion from `&&` to `const &`.
[Bug middle-end/109530] Warning "is used uninitialized" raised for an initialized variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530 --- Comment #2 from Andreas Schwab --- It also doesn't see that setjmp()==0 means that the block is not reached a second time.
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #12 from Oliver Rosten --- Yes, I am aware that I homebrewed gcc. What I don't understand is the extent to which this a homebrew problem and not a gcc problem. Forgive my ignorance but I would like to understand what submitting this issue to homebrew implies/achieves. I simply don't have much awareness of the broader context. On Sat, 15 Apr 2023 at 22:51, pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 > > --- Comment #11 from Andrew Pinski --- > (In reply to Oliver Rosten from comment #10) > > Can do, but I don't have sufficient understanding to understand why! Can > you > > kindly explain? > > Because that is where you got the GCC you are using from. It is listed in > the > configure line: > "--with-bugurl=https://github.com/Homebrew/homebrew-core/issues; > > -- > You are receiving this mail because: > You reported the bug.
[Bug c/109530] Warning "is used uninitialized" raised for an initialized variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530 --- Comment #1 from Andrew Pinski --- The warning is confusing but it is partly correct. Across a setjmp, you might need volatile variables. Gcc does not know that fprintf nor fclose will call longjmp.
[Bug c++/109521] [11/12/13 Regression] Checking ICE with canonical types differ for identical types ‘UBYTE [7]’ {aka ‘unsigned char [7]’} and ‘unsigned char [7]’ since r11-6508-gabb1b6058c09a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109521 --- Comment #4 from Sam James --- Note that it's also missing the 'internal compiler error' message in the output.
[Bug c/109530] New: Warning "is used uninitialized" raised for an initialized variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530
Bug ID: 109530
Summary: Warning "is used uninitialized" raised for an
initialized variable.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
For the following program:
#include
#include
jmp_buf buf;
jmp_buf buf1;
typedef struct ry_s {
struct ry_s *next;
} ry_t[1];
struct ry_s *m_global;
static inline void
ry_init(ry_t state)
{
m_global = state;
}
static inline void
ry_clear(ry_t state)
{
m_global = state->next;
}
int func2(void)
{
for(_Bool b = 1 ; b ; b = 0)
for(ry_t test1 ; b ; ry_clear(test1), b = 0 )
if (ry_init(test1), setjmp (buf) == 0)
{
FILE *f = fopen("tmp","wt");
if ((setjmp (buf1) == 0) )
{
fprintf(f, "This is a text\n");
fclose(f);
}
}
return 0;
}
When running with "-O2 -Wall -Wextra", I get the following warning:
: In function 'func2':
:31:17: warning: 'f' is used uninitialized [-Wuninitialized]
31 | FILE *f = fopen("tmp","wt");
whereas f is obviously initialized in the statement.
I am confused by this warning.
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #2 from Andrew Pinski --- Since `static_cast(x)` is considered rvalue and `int volatile const &` needs to be bound, it will not be bound to a temporary (rvalue) which is produced by the rvalue reference. In the non-volatile case, well it is a const reference which can be bound to a temporary value (rvalue) and that temp in this case will end its lifetime after the end of the statement (after the ;).
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
only const references can be bound to temporaries. const volatile references
cannot be bound to a temporary.
That is even this is invalid code:
```
int main(){
const volatile int & a = 1;
}
```
[Bug c++/109529] New: the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
Bug ID: 109529
Summary: the r-value volatile object is not accepted by the
l-value volatile constant argument.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lisp2d at rambler dot ru
Target Milestone: ---
void funy(int const &){}
void fun(int volatile const &){}
int main(){
int y ;
funy(y); // good
funy(static_cast(y)); // good
funy(static_cast(y)); // good
int volatile x ;
fun(x); // good
fun(static_cast(x)); // error
fun(static_cast(x)); // error
}
