[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > Why do you think it should work? > > R863 implicit-stmt is IMPLICIT implicit-spec-list > or IMPLICIT NONE [ ( [ implicit-none-spec-list ] ) ] > > R864 implicit-spec is declaration-type-spec ( letter-spec-list ) > > R865 letter-spec is letter [- letter ] > > R866 implicit-none-spec is EXTERNAL > or TYPE > > My reading of the EBNF is that TYPE can only following NONE. > Your code lacks NONE. Replying to self. In fact, the syntax requires (TYPE) not TYPE. More importantly TYPE does not take a declaration-type-spec.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Why do you think it should work? R863 implicit-stmt is IMPLICIT implicit-spec-list or IMPLICIT NONE [ ( [ implicit-none-spec-list ] ) ] R864 implicit-spec is declaration-type-spec ( letter-spec-list ) R865 letter-spec is letter [- letter ] R866 implicit-none-spec is EXTERNAL or TYPE My reading of the EBNF is that TYPE can only following NONE. Your code lacks NONE.
[Bug c++/43144] Possible ADL bug in GCC 4.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144 --- Comment #2 from Alisdair Meredith --- gcc 4.5 and later correctly report errors, as the language specification for rvalue and forwarding references changed between 4.4 and 4.5. I'm not sure what ADL bug I thought I was hitting, but with the evolving standards and lack of other reports, I suggest we just close this now as invalid.
[Bug target/105325] power10: Error: operand out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325 Michael Meissner changed: What|Removed |Added Assignee|acsawdey at gcc dot gnu.org|meissner at gcc dot gnu.org Status|NEW |ASSIGNED CC||meissner at gcc dot gnu.org --- Comment #13 from Michael Meissner --- Aaron is not working on GCC any longer, so I'm taking over this bug.
[Bug fortran/109226] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226 urbanjost at comcast dot net changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from urbanjost at comcast dot net --- browser glitch created literal duplicate. delting *** This bug has been marked as a duplicate of bug 109223 ***
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #1 from urbanjost at comcast dot net --- *** Bug 109226 has been marked as a duplicate of this bug. ***
[Bug fortran/109226] New: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226 Bug ID: 109226 Summary: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- This fails on the IMPLICIT statement program testit use, intrinsic :: iso_fortran_env, only : qp=>real128 implicit type(real(kind=qp)) (a-z) ! this should work but fails ! surprising (to me) this works, which I thought broke the syntax rules ! implicit real(kind=qp) (a-z) type(real(kind=QP)) :: quad print '(*(g0))', "kind(long) = ", kind(long), & & "; expected is ", kind(quad) end program testit The expected output is kind(long) = 16; expected is 16 The "Fortran Standard" implies type parameters are standard: 8.7 IMPLICIT statement 1 In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all implicitly typed data entities whose names begin with one of the letters specified in the statement. An IMPLICIT NONE statement can indicate that no implicit typing rules are to apply in a particular scoping unit, or that external and dummy procedures need to be explicitly given the EXTERNAL attribute.
[Bug analyzer/109225] -Wanalyzer-null-dereference false negative with *c = 404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109225 bagel ming changed: What|Removed |Added CC||bagelming at outlook dot com --- Comment #1 from bagel ming --- 'when considering the path a calls b'..sorry, I write it backwards here, it's 'b calls a'.
[Bug analyzer/109225] New: -Wanalyzer-null-dereference false negative with *c = 404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109225
Bug ID: 109225
Summary: -Wanalyzer-null-dereference false negative with *c =
404
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bagelming at outlook dot com
Target Milestone: ---
```c
extern void __analyzer_eval();
extern void __analyzer_dump_path();
int a()
{
int d;
for (d = -1; d; ++d)
{
;
}
__analyzer_dump_path();
return d;
}
int b()
{
int t = a();
int *c = (void *)t;
__analyzer_eval(c == 0);
*c = 404;
}
int main() { b(); }
```
See it live: https://godbolt.org/z/oEcW5bP9v
In func b, `return d`, d is 0, and the pointer c in func a is a null pointer
when considering the path a calls b. However, `analyzer_eval(c == 0)` is
unknown and analyzer doesn't generate a null pointer dereference warning for
`*c = 404`.
Thanks a lot!
[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758 Andrew Pinski changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 109222 has been marked as a duplicate of this bug. ***
[Bug c++/109222] Confusing error for declaring an enum class with unknown type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109222 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Duplicate of bug 64758 in the end. *** This bug has been marked as a duplicate of bug 64758 ***
[Bug c++/109222] Confusing error for declaring an enum class with unknown type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109222
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-03-21
Keywords||diagnostic
--- Comment #1 from Andrew Pinski ---
Confirmed.
clang does a decent job here:
:1:16: error: unknown type name 'i32'
enum class E : i32 { red, green, blue };
^
Though clang error messages for:
```
struct E
{
enum i32 : int;
};
enum E : i32 { red, green, blue };
```
Seems off ...
[Bug middle-end/109224] New: Wmismatched-new-delete false positive with corotuines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224
Bug ID: 109224
Summary: Wmismatched-new-delete false positive with corotuines
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
#include
struct Task {
struct promise_type {
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() { throw; }
Task get_return_object() { return {}; }
void return_void() {}
template
void* operator new(std::size_t sz, I);
void operator delete(void* ptr, std::size_t);
};
};
Task f(int) {
co_return;
}
int main() {
f(42);
}
g++ -std=c++20 -Wall produces (https://gcc.godbolt.org/z/vjvrPr6dc):
: In function 'Task f(int)':
:20:1: warning: 'static void Task::promise_type::operator delete(void*,
std::size_t)' called on pointer returned from a mismatched allocation function
[-Wmismatched-new-delete]
20 | }
| ^
:20:1: note: returned from 'static void* Task::promise_type::operator
new(std::size_t, I) [with I = int]'
20 | }
| ^
This is basically how coroutine frame allocation works (the promise type's
operator new can optionally view the coroutine's parameters, while operator
delete doesn't). Notably C++23 std::generator does something like this and the
reference implementation triggers the same warning.
Oddly enough, if operator new is not a template, i.e., operator new(size_t,
int), there's no warning.
[Bug fortran/109223] New: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 Bug ID: 109223 Summary: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- This fails on the IMPLICIT statement program testit use, intrinsic :: iso_fortran_env, only : qp=>real128 implicit type(real(kind=qp)) (a-z) ! this should work but fails ! surprising (to me) this works, which I thought broke the syntax rules ! implicit real(kind=qp) (a-z) type(real(kind=QP)) :: quad print '(*(g0))', "kind(long) = ", kind(long), & & "; expected is ", kind(quad) end program testit The expected output is kind(long) = 16; expected is 16 The "Fortran Standard" implies type parameters are standard: 8.7 IMPLICIT statement 1 In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all implicitly typed data entities whose names begin with one of the letters specified in the statement. An IMPLICIT NONE statement can indicate that no implicit typing rules are to apply in a particular scoping unit, or that external and dummy procedures need to be explicitly given the EXTERNAL attribute.
[Bug c++/109222] New: Confusing error for declaring an enum class with unknown type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109222
Bug ID: 109222
Summary: Confusing error for declaring an enum class with
unknown type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This program fails to compile (as it should, since the first line is commented
out):
// using i32 = int;
enum class E : i32 { red, green, blue };
But the error is...
:2:6: warning: elaborated-type-specifier for a scoped enum must not use
the 'class' keyword
2 | enum class E : i32 { red, green, blue };
| ^
| -
:2:14: error: found ':' in nested-name-specifier, expected '::'
2 | enum class E : i32 { red, green, blue };
| ^
| ::
:2:12: error: 'E' has not been declared
2 | enum class E : i32 { red, green, blue };
|^
:2:20: error: expected unqualified-id before '{' token
2 | enum class E : i32 { red, green, blue };
|^
In this case I was missing an include for the typedef, but boy did that take me
a while to figure out.
[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221 --- Comment #4 from Andrew Pinski --- With -ffast-math -mfpmath=387,sse (or -mavx512f instead of -mfpmath=387 as there is a avx512f instruction too) added, ldexp gets inlined.
[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Andrew Pinski ---
Even for C/C++, GCC does not inline:
float f(float a, int b)
{
return __builtin_ldexpf(a,b);
}
So ...
[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221 --- Comment #2 from Witold Baryluk --- Interesting enough, GDC 10.2 does inline `poly` instantiation with all the constants.
[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221 --- Comment #1 from Witold Baryluk --- PS. LDC 1.23.0 - 1.32.0 produce optimal code. LDC 1.22.0 a bit worse (due to use of x87 codegen), and 1.21 and older fail to inline `ldexp`, but still inline `poly` and `floor` perfectly.
[Bug d/109221] New: std.math.floor, core.math.ldexp, std.math.poly poor inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
Bug ID: 109221
Summary: std.math.floor, core.math.ldexp, std.math.poly poor
inlining
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: witold.baryluk+gcc at gmail dot com
Target Milestone: ---
Example:
static float sRGB_case4(float x) {
// import std.math : exp;
return 1.055f * expImpl(x) - 0.055f; // expImpl not inlined by default
// (inlined when using pragma(inline, true), but that fails to inline in
DMD)
}
// pragma(inline, true)
// This is borrowed from phobos/exponential.d to help gcc inline it fully.
// Only T == float case is here (as some traits are private to phobos).
// Also isNaN and range checks are removed, as sRGB performs own checks.
static private T expImpl(T)(T x) @safe pure nothrow @nogc
{
//import std.math : floatTraits, RealFormat;
//import std.math.traits : isNaN;
//import std.math.rounding : floor;
//import std.math.algebraic : poly;
//import std.math.constants : LOG2E;
import std.math;
import core.math;
static immutable T[6] P = [
5.001201E-1,
1.665459E-1,
4.1665795894E-2,
8.3334519073E-3,
1.3981999507E-3,
1.9875691500E-4,
];
enum T C1 = 0.693359375;
enum T C2 = -2.12194440e-4;
// Overflow and Underflow limits.
enum T OF = 88.72283905206835;
enum T UF = -103.278929903431851103; // ln(2^-149)
// Special cases.
//if (isNaN(x))
//return x;
//if (x > OF)
//return real.infinity;
//if (x < UF)
//return 0.0;
// Express: e^^x = e^^g * 2^^n
// = e^^g * e^^(n * LOG2E)
// = e^^(g + n * LOG2E)
T xx = floor((cast(T) LOG2E) * x + cast(T) 0.5); // NOT INLINED!
const int n = cast(int) xx;
x -= xx * C1;
x -= xx * C2;
xx = x * x;
x = poly(x, P) * xx + x + 1.0f; // poly is generated optimally, but
not inlined
// Scale by power of 2.
x = core.math.ldexp(x, n);// NOT INLINED
return x;
}
gdc gdc
(Compiler-Explorer-Build-gcc-454a4d5041f53cd1f7d902f6c0017b7ce95b36df-binutils-2.38)
13.0.1 20230318 (experimental)
gdc -O3 -march=znver2 -frelease -fbounds-check=off
pure nothrow @nogc @safe float std.math.algebraic.poly!(float, float,
6).poly(float, ref const(float[6])):
vmovss xmm1, DWORD PTR [rdi+20]
vfmadd213ss xmm1, xmm0, DWORD PTR [rdi+16]
vfmadd213ss xmm1, xmm0, DWORD PTR [rdi+12]
vfmadd213ss xmm1, xmm0, DWORD PTR [rdi+8]
vfmadd213ss xmm1, xmm0, DWORD PTR [rdi+4]
vfmadd213ss xmm0, xmm1, DWORD PTR [rdi]
ret
pure nothrow @nogc @safe float example.expImpl!(float).expImpl(float):
pushrbx
vmovaps xmm1, xmm0
sub rsp, 16
vmovss xmm0, DWORD PTR .LC0[rip]
vfmadd213ss xmm0, xmm1, DWORD PTR .LC1[rip]
vmovss DWORD PTR [rsp+8], xmm1
callpure nothrow @nogc @trusted float
std.math.rounding.floor(float)
vmovss xmm1, DWORD PTR [rsp+8]
mov edi, OFFSET FLAT:immutable(float[6])
example.expImpl!(float).expImpl(float).P
vfnmadd231ssxmm1, xmm0, DWORD PTR .LC2[rip]
vmovss DWORD PTR [rsp+12], xmm0
vfnmadd231ssxmm1, xmm0, DWORD PTR .LC3[rip]
vmulss xmm3, xmm1, xmm1
vmovaps xmm0, xmm1
vmovss DWORD PTR [rsp+8], xmm1
vmovd ebx, xmm3
callpure nothrow @nogc @safe float std.math.algebraic.poly!(float,
float, 6).poly(float, ref const(float[6]))
vmovss xmm1, DWORD PTR [rsp+8]
vmovd xmm4, ebx
vmovss xmm2, DWORD PTR [rsp+12]
vfmadd132ss xmm0, xmm1, xmm4
vaddss xmm0, xmm0, DWORD PTR .LC4[rip]
add rsp, 16
pop rbx
vcvttss2si edi, xmm2
jmp ldexpf
float example.sRGB_case4(float):
sub rsp, 8
callpure nothrow @nogc @safe float
example.expImpl!(float).expImpl(float)
vmovss xmm1, DWORD PTR .LC6[rip]
vfmadd132ss xmm0, xmm1, DWORD PTR .LC5[rip]
add rsp, 8
ret
https://godbolt.org/z/YMoMPdjn5
Additionally
std.math.exp itself, is never inlined by gcc. This is important, as some early
checks (isNaN, OF, UF checks) in exp could be removed by proper inlining.
[Bug preprocessor/50387] Doesn't process "_Pragma" when expanding a token sequence for #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50387
--- Comment #2 from Andrew Pinski ---
Simplified testcase:
```
#define GET(H) _Pragma("")
#include GET(stdio.h)
```
Both MSVC and clang are able to handle this.
ICC rejects it for the same reason as GCC.
[Bug bootstrap/44173] configure -disable-fixincludes doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44173 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed finally by r13-2319-gbe9dd80f933480 .
[Bug libstdc++/109205] vector.resize( v.size() + 100 ) does unnecessary comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
--- Comment #3 from Jonathan Wakely ---
Huh, but that causes a test to FAIL with -D_GLIBCXX_DEBUG
FAIL: 23_containers/vector/59829.cc (test for excess errors)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:989:
error: no match for 'operator<' in '((const std::__cxx1998::vector >*)this)->std::__cxx1998::vector
>::.std::__cxx1998::_Vector_base
>::_M_impl.std::__cxx1998::_Vector_base
>::_Vector_impl::.std::__cxx1998::_Vector_base
>::_Vector_impl_data::_M_finish < ((const std::__cxx1998::vector >*)this)->std::__cxx1998::vector
>::.std::__cxx1998::_Vector_base
>::_M_impl.std::__cxx1998::_Vector_base
>::_Vector_impl::.std::__cxx1998::_Vector_base
>::_Vector_impl_data::_M_start' (operand types are 'const
std::__cxx1998::_Vector_base >::pointer' {aka 'const
std::allocator_traits >::pointer'} and 'const
std::__cxx1998::_Vector_base >::pointer' {aka 'const
std::allocator_traits >::pointer'})
[Bug bootstrap/44881] toplevel configure assumes that mpc is fine when gmp is a toplevel directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44881 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2010-07-24 18:53:22 |2023-3-20 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- I am going to try to clean up the configure for GCC 14.
[Bug testsuite/44176] dg-cmp-results.sh contains several unportabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44176 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-03-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/42161] use __cxa_vec_dtor instead of loop to reduce code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42161 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2009-12-01 19:47:50 |2023-3-20 --- Comment #4 from Andrew Pinski --- Most likely this optimization should only be done for -Os and maybe when the deconstructor does not have a definition in the TU (for inlining).
[Bug c++/43144] Possible ADL bug in GCC 4.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144 --- Comment #1 from Andrew Pinski --- Starting GCC 4.5.x we get the following error message first: : In function 'typename std::remove_reference<_Tp>::type&& std0x::move(T&&) [with T = int&, typename std::remove_reference<_Tp>::type = int]': :36:22: instantiated from 'void std0x::swap(T&, T&) [with T = int]' :174:23: instantiated from here :30:36: error: invalid initialization of reference of type 'std::remove_reference::type&&' from expression of type 'int' Note clang also gets that error message. I have no idea if this is valid code or not.
[Bug libstdc++/109203] sort(zip(v1, v2)) fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109203 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #6 from Jiang An --- libstdc++ has (unfortunately?) implemented the tuple-or-pair strategy in P2321. The strategy is dropped by P2165. It seems that if std::tuple is unconditionally used, this issue will be resolved. This issue will also be resolved once LWG3865 gets implemented.
[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274 --- Comment #6 from Andrew Pinski --- Note if you want to detect more buffer overruns you should try -fsanitize=address . Valgrind will also detect more too. BUT note none of these are 100% either because they only have a limited redzone and valgrind also will detect less due to if two buffers are on the stack there is no zone inbetween the buffers.
[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- -fstack-protector (-all) does not detect all buffer overflows and is not designed that way (or even documented that way). It only adds one space at the end of the stack to detect if there was a buffer overflow but it is also aligned so it might be further out than just one location too.
[Bug c++/109181] requires expression type requirement rejects valid type when it is a nested member template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
--- Comment #4 from Andrew Pinski ---
(In reply to Patrick Palka from comment #3)
> A workaround is to just remove the unneeded 'template' after the :: in this
> case. Or is there an example where the template keyword is needed that we
> incorrectly reject?
I could not find an example.
I did find an example where the template is removed clang rejects it but gcc
does not:
struct A {
template
using B = int;
};
template
T C();
template
bool go = requires{typename decltype(C())::template B;};
bool a = go;
[Bug c++/109181] requires expression type requirement rejects valid type when it is a nested member template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- A workaround is to just remove the unneeded 'template' after the :: in this case. Or is there an example where the template keyword is needed that we incorrectly reject?
[Bug target/31787] bfin: Dreg expected for CLI. Input text was P0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787 --- Comment #5 from Andrew Pinski --- Fixed in RTEMS by https://devel.rtems.org/changeset/008171099d817f4745ab55a68121d5dba7b66181/rtems .
[Bug target/31787] bfin: Dreg expected for CLI. Input text was P0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (define_register_constraint "d" "DREGS" "A Rn register.") Yes this is a bug in the inline-asm. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Machine-Constraints.html#Machine-Constraints
[Bug target/31787] bfin: Dreg expected for CLI. Input text was P0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
--- Comment #3 from Andrew Pinski ---
do { { asm volatile ("cli %0 \n" : "=r" (level) ); }; asm volatile("" :::
"memory"); } while (0);
Hmm, this might not be a GCC bug ...
[Bug driver/31089] gccspec.c doesn't handle -x options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2007-03-19 09:14:51 |2023-3-20 --- Comment #2 from Andrew Pinski --- The file is now c/gccspec.cc but the check there is still the same for .m/.mi and does not check for -x or -ObjC
[Bug analyzer/109220] New: analyzer doesn't complain about unrecognized state machines with -fanalyzer-checker=NAME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109220 Bug ID: 109220 Summary: analyzer doesn't complain about unrecognized state machines with -fanalyzer-checker=NAME Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/pipermail/gcc/2023-March/240928.html reports: > there is no error or warning when I mistyped it as -fanalyzer-checker=tai8nt
[Bug other/7088] host-x-host builds install broken limits.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7088 Andrew Pinski changed: What|Removed |Added Assignee|neroden at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.0.0 --- Comment #6 from Andrew Pinski --- This was fully fixed with r13-2319-gbe9dd80f933480 . Though it was partly fixed with r0-49126-g7a615b25793c22 (for sysroots) and then changed again with r0-63126-gde253ca48a960d and then fixed for building fixincludes for the host by r0-63200-g53c7ffe7dd1c28. So this was basically fixed for GCC 4.0.0 with only a recent improvement for GCC 13 by allowing --disable-fixincludes .
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #16 from Jürgen Reuter --- (In reply to Paul Thomas from comment #14) > For the record, the fix is: > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc > index 1d973d12ff1..1a03e458d99 100644 > --- a/gcc/fortran/resolve.cc > +++ b/gcc/fortran/resolve.cc > @@ -11760,6 +11760,7 @@ generate_component_assignments (gfc_code **code, > gfc_namespace *ns) > of all kinds and allocatable components. */ >if (!gfc_bt_struct (comp1->ts.type) > || comp1->attr.pointer > + || comp1->attr.allocatable > || comp1->attr.proc_pointer_comp > || comp1->attr.class_pointer > || comp1->attr.proc_pointer) I confirm that all of our code compiles again with this fix, and all our tests pass. Thanks for the quick action, Paul, and also for the stamina to tackle the finalization!
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-March/6 ||14288.html Status|ASSIGNED|WAITING --- Comment #15 from David Malcolm --- The patch needed a little tweaking to avoid regressing gcc.dg-selftests/dg-final.exp; I've posted it here for review: [PATCH] testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959] https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614288.html
[Bug libstdc++/109205] vector.resize( v.size() + 100 ) does unnecessary comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-03-20
Status|UNCONFIRMED |NEW
--- Comment #2 from Jonathan Wakely ---
I guess we might as well do it for capacity too:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -985,7 +985,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
size_type
size() const _GLIBCXX_NOEXCEPT
- { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
+ {
+ if (this->_M_impl._M_finish < this->_M_impl._M_start)
+ __builtin_unreachable();
+ return size_type(this->_M_impl._M_finish - this->_M_impl._M_start);
+ }
/** Returns the size() of the largest possible %vector. */
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
@@ -1071,8 +1075,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
size_type
capacity() const _GLIBCXX_NOEXCEPT
- { return size_type(this->_M_impl._M_end_of_storage
-- this->_M_impl._M_start); }
+ {
+ if (this->_M_impl._M_end_of_storage < this->_M_impl._M_start)
+ __builtin_unreachable();
+ return size_type(this->_M_impl._M_end_of_storage
+- this->_M_impl._M_start);
+ }
/**
* Returns true if the %vector is empty. (Thus begin() would
[Bug fortran/109216] Wrong behaviour explained in -fno-underscoring documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109216 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6c2b28e43205b7b0cef9ac8504621c4cd0ccbde7 commit r13-6766-g6c2b28e43205b7b0cef9ac8504621c4cd0ccbde7 Author: Harald Anlauf Date: Mon Mar 20 20:55:00 2023 +0100 Fortran: fix documentation of -fno-underscoring [PR109216] gcc/fortran/ChangeLog: PR fortran/109216 * invoke.texi: Correct documentation of how underscores are appended to external names.
[Bug target/109217] failure statically linking shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217 --- Comment #2 from Jonathan Wakely --- So a dup of Bug 7516 then?
[Bug analyzer/109199] GCC Static Analyzer evaluates `__analyzer_eval((((c) + 1) == (([0]) + 1)))` to be FALSE with the fact `c == [0]`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109199 David Malcolm changed: What|Removed |Added Summary|GCC Static Analyzer |GCC Static Analyzer |evaluates |evaluates |`__analyzer_evalc) + 1) |`__analyzer_evalc) + 1) |== (([0]) + 1)))` to be |== (([0]) + 1)))` to be |FLASE with the fact `c == |FALSE with the fact `c == |[0]` |[0]` Ever confirmed|0 |1 Last reconfirmed||2023-03-20 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Confirmed. The analyzer is comparing: (gdb) call rhs1_sval->dump(true) (gdb) call rhs2_sval->dump(true) [(int)0] and not treating these two pointers as identical.
[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-March/059104.html
[Bug c++/109159] [10/11/12 Regression] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159 Marek Polacek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |explicit constructor is |explicit constructor is |used in copy-initialization |used in copy-initialization --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug analyzer/109191] GCC static analyzer does not warning `*b = 1` where `b` is 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191 --- Comment #2 from David Malcolm --- It is valid in the embedded space to do things like *(SOME_CONSTANT_ADDRESS) = SOME_VALUE;
[Bug c++/109159] [10/11/12/13 Regression] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:a226590fefb35ed66adf73d85cefe49048a78ab8
commit r13-6765-ga226590fefb35ed66adf73d85cefe49048a78ab8
Author: Marek Polacek
Date: Fri Mar 17 18:25:13 2023 -0400
c++: explicit ctor and list-initialization [PR109159]
When I implemented explicit(bool) in r9-3735, I added this code to
add_template_candidate_real:
+ /* Now the explicit specifier might have been deduced; check if this
+ declaration is explicit. If it is and we're ignoring non-converting
+ constructors, don't add this function to the set of candidates. */
+ if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+return NULL;
but as this test demonstrates, that's incorrect when we're initializing
from a {}: for list-initialization we consider explicit constructors and
complain if one is chosen.
PR c++/109159
gcc/cp/ChangeLog:
* call.cc (add_template_candidate_real): Add explicit decls to the
set of candidates when the initializer is a braced-init-list.
libstdc++-v3/ChangeLog:
* testsuite/20_util/pair/cons/explicit_construct.cc: Adjust
dg-error.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
* testsuite/23_containers/span/explicit.cc: Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/explicit16.C: New test.
[Bug analyzer/109197] Analyzer gets confused about conditionals involving bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109197
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer does|Analyzer gets confused
|not kown `c || b.d` is |about conditionals
|false with the fact that|involving bitfields
|`c=0` and `b.d=0` |
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-03-20
--- Comment #1 from David Malcolm ---
Thanks for filing this.
Simpler reproducer:
https://godbolt.org/z/qe5cEY9Kh
struct a
{
int d : 10;
} b;
void e()
{
b.d = 0;
if (b.d)
{
__analyzer_eval (b.d);
__analyzer_dump_path ();
}
}
[skipping -Wimplicit-function-declaration warnings]
:11:9: warning: FALSE
11 | __analyzer_eval (b.d);
| ^
:12:9: note: path
12 | __analyzer_dump_path ();
| ^~~
'e': events 1-3
|
|9 | if (b.d)
| |^
| ||
| |(1) following 'true' branch...
| 10 | {
| 11 | __analyzer_eval (b.d);
| | ~~~
| | |
| | (2) ...to here
| 12 | __analyzer_dump_path ();
| | ~~~
| | |
| | (3) here
|
where it's erronesously considering the case where b.d is 0, but then b.d is
somehow true.
[Bug analyzer/109196] GSA evaluates `__analyzer_eval(((a())<(0))||((a())==(0)));` to be TRUE, but function `a()` is a unknown function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109196 David Malcolm changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Simpler reproducer: https://godbolt.org/z/h3WcPP9q8 Looking at the gimple dump, I see: : iftmp.0_14 = 1; goto ; [INV] : iftmp.0_13 = 0; : # iftmp.0_4 = PHI __analyzer_eval (iftmp.0_4); i.e. that __analyzer_eval is being called with either 0 or 1. What you're seeing here is a result of how the analyzer is merging state along different paths. Adding -fno-analyzer-state-merge: https://godbolt.org/z/7Tn5xqo4x converts the output to: : In function 'b': :9:9: warning: TRUE 9 | __analyzer_eval(((a())<(0))||((a())==(0))); | ^~ :9:9: warning: FALSE i.e. the result of ||-ing the conditions could be true, and it could be false. __analyzer_eval is intended as a feature for debugging the analyzer, rather than being end-user-facing, so I'm going to mark this as WONTFIX. Hope this makes sense.
[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #9 from anlauf at gcc dot gnu.org ---
Even simpler tentative patch:
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index c8f0bb83c2c..b29f491fe1f 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -9998,6 +9998,7 @@ gfc_match_modproc (void)
if ((gfc_state_stack->state != COMP_INTERFACE
&& gfc_state_stack->state != COMP_CONTAINS)
|| gfc_state_stack->previous == NULL
+ || !current_interface.type
|| current_interface.type == INTERFACE_NAMELESS
|| current_interface.type == INTERFACE_ABSTRACT)
{
This keeps the original error message without effort and regtests ok.
[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||volker.weissmann at gmx dot de --- Comment #8 from anlauf at gcc dot gnu.org --- *** Bug 109211 has been marked as a duplicate of this bug. ***
[Bug fortran/109211] f951: internal compiler error: in gfc_current_interface_head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109211 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- Actually a duplicate of pr99036. *** This bug has been marked as a duplicate of bug 99036 ***
[Bug analyzer/109195] GCC Static Analyzer does not know "a+0 <= b+1" in the true branch of if (a <= b), but knows "a+0 < b+1".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109195 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from David Malcolm --- As per bug 109194, much of these aren't actually true; consider when b == INT_MAX. Then b + 1 is undefined, but we may want to treat it as INT_MIN. So (a <= b) doesn't necessarily imply much about a + M <= b + N As also noted in bug 109193 and bug 109194, the constraint_manager has some heuristics to try to handle common cases, but ultimately we're probably going to want to hand this off to an SMT solver (PR 104940) *** This bug has been marked as a duplicate of bug 104940 ***
[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 --- Comment #3 from David Malcolm --- *** Bug 109195 has been marked as a duplicate of this bug. ***
[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 --- Comment #2 from David Malcolm --- *** Bug 109194 has been marked as a duplicate of this bug. ***
[Bug analyzer/109194] GCC Static Analyzer does not know "a+3 > b+1" in the true branch of "if (a > b) ", but it knows "a+2 > b+1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from David Malcolm --- As also noted in bug 109193, the constraint_manager has some heuristics to try to handle common cases, but ultimately we're probably going to want to hand this off to an SMT solver (PR 104940) *** This bug has been marked as a duplicate of bug 104940 ***
[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 David Malcolm changed: What|Removed |Added CC||geoffreydgr at icloud dot com --- Comment #1 from David Malcolm --- *** Bug 109193 has been marked as a duplicate of this bug. ***
[Bug analyzer/109193] GCC Static Analyzer does not know "1-a > 0-b" in the true branch of "if (a < b && 0 < a) "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109193 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from David Malcolm --- As per bug 109194, I'm not convinced all of these definitely hold e.g. when a or b are INT_MAX or INT_MIN. The constraint_manager has some heuristics to try to handle common cases, but ultimately we're probably going to want to hand this off to an SMT solver (PR 104940) *** This bug has been marked as a duplicate of bug 104940 ***
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-03-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3 Known to fail||12.2.0 Known to work||11.3.0, 12.1.0 Summary|csmith: ice in |[12/13 Regression] csmith: |vect_slp_analyze_node_opera |ice in |tions_1, at |vect_slp_analyze_node_opera |tree-vect-slp.cc:5954 |tions_1, at ||tree-vect-slp.cc:5954
[Bug analyzer/109194] GCC Static Analyzer does not know "a+3 > b+1" in the true branch of "if (a > b) ", but it knows "a+2 > b+1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194 --- Comment #1 from David Malcolm --- Well, strictly speaking not all of these are true; consider a == INT_MAX b == INT_MAX - 1 Then a > b, but: * a + 1 is, I believe, undefined, but we may want to treat it as INT_MIN * b + 1 is INT_MAX * with those semantics, a + 1 > b + 1 is INT_MIN > INT_MAX which is false ...and you can pick other values for b e.g. INT_MAX - 2 to get other results. The constraint manager code is playing rather fast-and-loose in places. I've been experimenting with adding an SMT solver (PR 104940) which would support figuring out such cases precisely based on bit-vectors.
[Bug c/109219] New: csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219
Bug ID: 109219
Summary: csmith: ice in vect_slp_analyze_node_operations_1, at
tree-vect-slp.cc:5954
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
safe_lshift_func_int32_t_s_s_left, safe_lshift_func_int32_t_s_s_right,
safe_sub_func_uint64_t_u_u_ui2, safe_mul_func_uint64_t_u_u_ui2, g_79_2,
g_97_l_439;
g_97() {
unsigned short __trans_tmp_16;
long __trans_tmp_15;
int __trans_tmp_14, __trans_tmp_7;
int *l_437 = g_97;
for (; g_97_l_439; g_97_l_439 += 1) {
char l_502 = 0;
for (; l_502 < 4; l_502++) {
__trans_tmp_14 = safe_lshift_func_int32_t_s_s_right >= 2 ||
safe_lshift_func_int32_t_s_s_left
?: safe_lshift_func_int32_t_s_s_right;
__trans_tmp_15 = __trans_tmp_14 * safe_mul_func_uint64_t_u_u_ui2;
__trans_tmp_16 = -__trans_tmp_15;
__trans_tmp_7 =
(__trans_tmp_16 ^ 65535UL) - safe_sub_func_uint64_t_u_u_ui2;
*l_437 ^= (short)(__trans_tmp_7 ^ g_79_2);
}
}
}
main() {}
when compiled by recent gcc trunk and compiler flag -O3, does this:
$ ~/gcc/results/bin/gcc -c -w -O3 bug900.c
during GIMPLE pass: vect
bug900.c: In function ‘g_97’:
bug900.c:4:1: internal compiler error: in vect_slp_analyze_node_operations_1,
at tree-vect-slp.cc:5954
4 | g_97() {
| ^~~~
0x7d6a29 vect_slp_analyze_node_operations_1
../../trunk.year/gcc/tree-vect-slp.cc:5954
0x7d6a29 vect_slp_analyze_node_operations
../../trunk.year/gcc/tree-vect-slp.cc:6147
0x119b14f vect_slp_analyze_node_operations
../../trunk.year/gcc/tree-vect-slp.cc:6126
0x119b14f vect_slp_analyze_node_operations
../../trunk.year/gcc/tree-vect-slp.cc:6126
It is fine at -O2:
$ ~/gcc/results/bin/gcc -c -w -O2 bug900.c
$
The bug has existed since sometime before 20220403.
[Bug analyzer/109191] GCC static analyzer does not warning `*b = 1` where `b` is 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191 --- Comment #1 from David Malcolm --- GCC does emit a -Wint-to-pointer-cast warning on this code, for the int to void * conversion. Is this reduced from a real-world example, or just synthesized by hand? I suppose in theory the analyzer could: (a) figure out that it reads all zeroes from the array and complain about the null pointer deref, and/or (b) complain that we're accessing beyond the end of an array
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 --- Comment #7 from Andrew Macleod --- Created attachment 54716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54716=edit proposed patch This is due to the latter part of the specified patch. We normally terminate outgoing range calculations once the LHS has reverted to VARYING as we won't learn anything new. The original patch modified this such that if there was a relation present, we continued calculating as the relation may provide new information, as per the original PR. The problem exposed in this PR is that the presence of a relation doesn't mean that relation can actually affect the range. This PR shows many relations, none of which are relevant, and with the quadratic nature of the path query, it makes things quite bad. The attached patch is in testing. It adds a check to determine if the relation can affect the outgoing range or not by checking if the operands are used in the calculation or not. If they are not in the definition chain, they can have no impact, and we stop the attempt.
[Bug analyzer/99669] RFE: detect division by zero in analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99669 David Malcolm changed: What|Removed |Added CC||geoffreydgr at icloud dot com --- Comment #3 from David Malcolm --- *** Bug 109201 has been marked as a duplicate of this bug. ***
[Bug analyzer/109201] GCC Static Analyzer does not generate a div-by-zero warning for the `if ((d.b = 1) / f)` where `f` is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201 David Malcolm changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from David Malcolm --- We already have PR 99669 as an RFE for this; marking as a dup. *** This bug has been marked as a duplicate of bug 99669 ***
[Bug analyzer/109200] GCC Static Analyzer does not generate a div-by-zero warning for the `0 <= (f = 0) % e.b` where `e.b == 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109200 David Malcolm changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- As per PR 109201, the existing warning you're seeing isn't from the analyzer. *** This bug has been marked as a duplicate of bug 109201 ***
[Bug analyzer/109201] GCC Static Analyzer does not generate a div-by-zero warning for the `if ((d.b = 1) / f)` where `f` is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201 --- Comment #2 from David Malcolm --- *** Bug 109200 has been marked as a duplicate of this bug. ***
[Bug analyzer/109201] GCC Static Analyzer does not generate a div-by-zero warning for the `if ((d.b = 1) / f)` where `f` is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201 --- Comment #1 from David Malcolm --- The division by zero warning on: if ((d.b = 1) / 0) is from -Wdiv-by-zero, which isn't from the analyzer ( https://godbolt.org/z/433PhKhvM ) The analyzer currently only implements -Wanalyzer-tainted-divisor for attacker-controlled values used in division; it doesn't check for zero itself. So this seems like more of an RFE: it sounds like you'd want the analyzer to complain about known zero values reaching a division, as a souped-up kind implementation of the existing -Wdiv-by-zero.
[Bug tree-optimization/109170] [13 Regression] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Summary|New glibc warning: |[13 Regression] New glibc |open_catalog.c:86:16: |warning: |error: pointer ‘old_buf’|open_catalog.c:86:16: |may be used after ‘realloc’ |error: pointer ‘old_buf’ |[-Werror=use-after-free]|may be used after ‘realloc’ |since |[-Werror=use-after-free] |r13-6707-g0a07bfad12530bca |since ||r13-6707-g0a07bfad12530bca
[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175
--- Comment #4 from Andrew Pinski ---
auto in = AllocateAligned(padded);
The pointer returned here could be a nullptr
The warning is due to jump threading though.
AllocateAligned calls AllocateAlignedItems
Which could return nullptr:
if (check != items) {
return nullptr;
}
That is checking to make sure there was no wrap around for items*size really.
[Bug fortran/109216] Wrong behaviour explained in -fno-underscoring documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109216
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-03-20
Keywords||documentation
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
Patch:
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5679e2f2650..cbe7f377507 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1573,7 +1573,7 @@ Do not transform names of entities specified in the
Fortran
source file by appending underscores to them.
With @option{-funderscoring} in effect, GNU Fortran appends one
-underscore to external names with no underscores. This is done to ensure
+underscore to external names. This is done to ensure
compatibility with code produced by many UNIX Fortran compilers.
@emph{Caution}: The default behavior of GNU Fortran is
@@ -1596,7 +1596,7 @@ I = J() + MAX_COUNT (MY_VAR, LVAR)
@noindent
is implemented as something akin to:
@smallexample
-i = j_() + max_count__(_var__, );
+i = j_() + max_count_(_var, );
@end smallexample
With @option{-fno-underscoring}, the same statement is implemented as:
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0a846340b99675d57fc2f2923a0412134eed09d3 commit r13-6764-g0a846340b99675d57fc2f2923a0412134eed09d3 Author: Jakub Jelinek Date: Mon Mar 20 20:29:47 2023 +0100 c++: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164] The following two testcases are miscompiled, because we keep TREE_READONLY on the vars even when they are (possibly) dynamically initialized by a TLS wrapper function. Normally cp_finish_decl drops TREE_READONLY from vars which need dynamic initialization, but for TLS we do this kind of initialization upon every access to those variables. Keeping them TREE_READONLY means e.g. PRE can hoist loads from those before loops which contain the TLS wrapper calls, so we can access the TLS variables before they are initialized. 2023-03-20 Jakub Jelinek PR c++/109164 * cp-tree.h (var_needs_tls_wrapper): Declare. * decl2.cc (var_needs_tls_wrapper): No longer static. * decl.cc (cp_finish_decl): Clear TREE_READONLY on TLS variables for which a TLS wrapper will be needed. * g++.dg/tls/thread_local13.C: New test. * g++.dg/tls/thread_local13-aux.cc: New file. * g++.dg/tls/thread_local14.C: New test. * g++.dg/tls/thread_local14-aux.cc: New file.
[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 54715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54715=edit gcc13-pr109215.patch Untested fix.
[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067 --- Comment #2 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:c67f312d20e15e5aa18c587693b4ab7e131596c1 commit r13-6763-gc67f312d20e15e5aa18c587693b4ab7e131596c1 Author: Michael Meissner Date: Mon Mar 20 14:48:06 2023 -0400 Rework 128-bit complex multiply and divide. This patch reworks how the complex multiply and divide built-in functions are done. Previously GCC created built-in declarations for doing long double complex multiply and divide when long double is IEEE 128-bit. However, it did not support __ibm128 complex multiply and divide if long double is IEEE 128-bit. This code does not create the built-in declaration with the changed name. Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name before it is written out to the assembler file like it now does for all of the other long double built-in functions. 2023-03-20 Michael Meissner gcc/ PR target/109067 * config/rs6000/rs6000.cc (create_complex_muldiv): Delete. (init_float128_ieee): Delete code to switch complex multiply and divide for long double. (complex_multiply_builtin_code): New helper function. (complex_divide_builtin_code): Likewise. (rs6000_mangle_decl_assembler_name): Add support for mangling the name of complex 128-bit multiply and divide built-in functions. gcc/testsuite/ PR target/109067 * gcc.target/powerpc/divic3-1.c: New test. * gcc.target/powerpc/divic3-2.c: Likewise. * gcc.target/powerpc/mulic3-1.c: Likewise. * gcc.target/powerpc/mulic3-2.c: Likewise.
[Bug fortran/109211] f951: internal compiler error: in gfc_current_interface_head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109211 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-03-20 Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/109205] vector.resize( v.size() + 100 ) does unnecessary comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/109205] vector.resize( v.size() + 100 ) does unnecessary comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205 --- Comment #1 from Andrew Pinski --- So the IR looks like: _4 = MEM[(const struct vector *)v_3(D)].D.25711._M_impl.D.25018._M_finish; _6 = MEM[(const struct vector *)v_3(D)].D.25711._M_impl.D.25018._M_start; _7 = _4 - _6; _8 = (long unsigned int) _7; _1 = _8 + 100; GCC does not know this statement holds true: if (v.end() < v.begin()) __builtin_unreachable(); If you add that, then it will optimize away the comparison.
[Bug c/109208] gcc doesn't detect when sizes are booleans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109208 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #15 from anlauf at gcc dot gnu.org --- JFTR: Nvidia also doesn't like the reproducer: NVFORTRAN-S-1056-MODULE prefix is only allowed for subprograms that were declared as separate module procedures (pr109209.f90: 63) 0 inform, 0 warnings, 1 severes, 0 fatal for t3_set_expand Removing the "module" prefix makes the code compile, same with Intel. OTOH Crayftn 14.0 seems to be happy. @Paul: I agree with your proposal.
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213 --- Comment #4 from Andrew Pinski --- If you force m to be always_inline, we are back to GCC 12 code generation. I don't think there is anything GCC can do with differently; the heurstics are not tuned for these small "benchmark" functions either.
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #14 from Paul Thomas --- For the record, the fix is: diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 1d973d12ff1..1a03e458d99 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -11760,6 +11760,7 @@ generate_component_assignments (gfc_code **code, gfc_namespace *ns) of all kinds and allocatable components. */ if (!gfc_bt_struct (comp1->ts.type) || comp1->attr.pointer + || comp1->attr.allocatable || comp1->attr.proc_pointer_comp || comp1->attr.class_pointer || comp1->attr.proc_pointer)
[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4410a08b80cc40342eeaa5b6af824cd4352b218c commit r13-6762-g4410a08b80cc40342eeaa5b6af824cd4352b218c Author: Harald Anlauf Date: Sun Mar 19 21:29:46 2023 +0100 Fortran: simplification of NEAREST for large argument [PR109186] gcc/fortran/ChangeLog: PR fortran/109186 * simplify.cc (gfc_simplify_nearest): Fix off-by-one error in setting up real kind-specific maximum exponent for mpfr. gcc/testsuite/ChangeLog: PR fortran/109186 * gfortran.dg/nearest_6.f90: New test.
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #13 from Paul Thomas --- (In reply to Tobias Burnus from comment #12) > I bet that's due to the finalization > commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee > but I have not verified. > ...snip... See my reply above. In trying to fix all the finalization issues, I found myself following 10.2.1.3 "Interpretation of intrinsic assignments" closely; in particular paragraph 13, points (1) and (2) which define what to do with allocatable components. Reverting the one line in my patch that effects this cures this problem and has no effect on the finalization testcases. I suggest that I do the reversion and that we worry about intrinsic assignment of derived types another time, especially since the other brands compile the code without complaint. > > > Actually, the 'module subroutine' here needs to be just 'subroutine'. > > gfortran accepts this, nagfor doesn't. > > I filed PR 109218 for this issue. Thanks, Tobias Regards Paul
[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215
--- Comment #5 from Jakub Jelinek ---
This is complete mess.
/* Describes a "special" array member for a COMPONENT_REF. */
enum struct special_array_member
{
none, /* Not a special array member. */
int_0, /* Interior array member with size zero. */
trail_0,/* Trailing array member with size zero. */
trail_1,/* Trailing array member with one element. */
trail_n,/* Trailing array member with two or more elements. */
int_n /* Interior array member with one or more elements. */
};
Why is this defined differently for _0 and _1? Because what is interior
array with zero sized elements with 3 members? Both int_0 because the member
has zero size, and int_n because it has one or more elements.
I think we should make int_0/trail_0 mean with zero elements, anything else is
inconsistent.
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #3 from Andrew Pinski ---
In fact if you change main to:
int main() {
int p[10];
m();
if (!i()) {
int *q = [0];
for (; g;)
b(e == q);
}
}
GCC 12 also does not do the inlining.
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213 --- Comment #2 from Andrew Pinski --- Basically just unluckness ...
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #1 from Andrew Pinski ---
The difference is due to inlining of m into main.
The reason for the difference of inlining is due to removal of:
p = {};
statement from main in dse which changes the overall cost of the TU ...
[Bug target/109217] failure statically linking shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217 --- Comment #1 from Stas Sergeev --- So as #7516 suggests, it is now indeed rejected. :( And at the same time clang has no problem with that combination of options. Please make that a valid option combination again.
[Bug fortran/109218] "MODULE SUBROUTINE" wrongly accepted where MODULE prefix is not permitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109218 --- Comment #1 from Tobias Burnus --- >From Paul Thomas from bug 109208 comment #11: > NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115 > Error: pr109209.f90, line 63: Type-bound procedure T3_SET_EXPAND must be a > module procedure or external procedure with an explicit interface >detected at T3_SET_EXPAND@( ... > [pault@pc30 pr37336]$ rm ./a.out;ifort pr109209.f90 -g;./a.out > pr109209.f90(63): error #6115: A separate interface body must have been > declared in the program unit or an ancestor of the program unit for the > separate module procedure. [T3_SET_EXPAND] > module subroutine t3_set_expand (res_set) ... > both compile it just fine if you > s/module subroutine t3_set_expand/subroutine t3_set_expand/
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #12 from Tobias Burnus --- I bet that's due to the finalization commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee but I have not verified. (In reply to Jürgen Reuter from comment #10) > Thanks for checking, Tobias. Are you saying that the code violates the > standard, or the code generation after parsing by gcc/gfortran has generated > code violating the standard? I think the code is OK as the constraint is not violated by the user code but only by the code generated by the compiler internally from the user code. However, I have only very narrowly looked at the gcc/fortran/*.cc code and not tried to understand the Fortran code and what makes sense. [TODO ↑] The following fixes it, but ... [TODO ↓] ... I have not come to a conclusion whether the generated tree code (-fdump-tree-original) is correct with regards to (re)allocation on assignment or memory freeing. diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index 9bab2c40ead..8d4e276d8a3 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2567,0 +2568,3 @@ typedef struct gfc_expr + /* Set if the component assignment was generated by the compiler. */ + unsigned int generated : 1; + diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 1d973d12ff1..df3979ca8f4 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -5456 +5456,2 @@ gfc_resolve_ref (gfc_expr *expr) - if (current_part_dimension || seen_part_dimension) + if ((current_part_dimension || seen_part_dimension) + && !expr->generated) @@ -5518 +5519,2 @@ gfc_resolve_ref (gfc_expr *expr) - && seen_part_dimension) + && seen_part_dimension + && !expr->generated) @@ -11370,0 +11373,2 @@ build_assignment (gfc_exec_op op, gfc_expr *expr1, gfc_expr *expr2, + this_code->expr1->generated = true; + this_code->expr2->generated = true; * * * > > module subroutine t3_set_expand (res_set) > Actually, the 'module subroutine' here needs to be just 'subroutine'. > gfortran accepts this, nagfor doesn't. I filed PR 109218 for this issue.
[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215
--- Comment #4 from Jakub Jelinek ---
Slightly simplified -O2 -Wall:
struct S {};
struct T { struct S s[3]; struct S t; };
void bar (struct S *);
void
foo (struct T *t)
{
for (int i = 0; i < 3; i++)
bar (>s[i]);
}
On:
void
baz (struct T *t)
{
for (int i = 0; i < 4; i++)
bar (>s[i]);
}
we on the other side don't warn iN GCC 12 even when we probably should:
fre3 in that case replaces:
_10 = _5(D)->s[0];
bar (_10);
_15 = _5(D)->s[1];
bar (_15);
_20 = _5(D)->s[2];
bar (_20);
_25 = _5(D)->s[3];
bar (_25);
with
_10 = _5(D)->s[0];
bar (_10);
bar (_10);
bar (_10);
bar (_10);
and the warning is only in vrp1.
void
qux (struct T *t)
{
bar (>s[2]);
}
void
corge (struct T *t)
{
bar (>s[3]);
}
are then even simpler cases. r13-4521 and later warns for all those, GCC 12
for none of those.
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-03-20 --- Comment #11 from Paul Thomas --- > Thanks for checking, Tobias. Are you saying that the code violates the > standard, or the code generation after parsing by gcc/gfortran has generated > code violating the standard? Hi Jürgen, Its' the latter - see the end of this reply. Other brands don't like your reproducer: [pault@pc30 pr37336]$ rm ./a.out;nagfor pr109209.f90 -g;./a.out rm: cannot remove './a.out': No such file or directory NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115 Error: pr109209.f90, line 63: Type-bound procedure T3_SET_EXPAND must be a module procedure or external procedure with an explicit interface detected at T3_SET_EXPAND@( Error: pr109209.f90, line 73: Undefined type-bound procedure T3_SET_EXPAND [NAG Fortran Compiler pass 1 error termination, 2 errors] [pault@pc30 pr37336]$ rm ./a.out;ifort pr109209.f90 -g;./a.out rm: cannot remove './a.out': No such file or directory pr109209.f90(63): error #6115: A separate interface body must have been declared in the program unit or an ancestor of the program unit for the separate module procedure. [T3_SET_EXPAND] module subroutine t3_set_expand (res_set) ^ pr109209.f90(64): error #6451: A dummy argument name is required in this context. [RES_SET] class(t3_set_t), intent(inout) :: res_set --^ pr109209.f90(38): error #8169: The specified interface is not declared. [T3_SET_EXPAND] procedure, private :: expand => t3_set_expand -^ compilation aborted for pr109209.f90 (code 1) both compile it just fine if you s/module subroutine t3_set_expand/subroutine t3_set_expand/ Removing Harald's commit, commit 901edd99b44976b3c2b13a7d525d9e315540186a, doesn't do the job. However, removing my patch for pr37336 does indeed allow the code to compile as before. Everybody is happy with subroutine t3_set_expand (res_set) class(t3_set_t), intent(inout) :: res_set type(t3_t), dimension(:), allocatable :: history_new integer :: s, i s = size (res_set%history) allocate (history_new (2 * s)) do i = 1,s history_new(i) = res_set%history(i) end do call move_alloc (history_new, res_set%history) end subroutine t3_set_expand Actually, I think that I have indeed introduced a bug since t3_t has a defined assignment. Give me 30 minutes:-) Paul
[Bug fortran/109218] New: "MODULE SUBROUTINE" wrongly accepted where MODULE prefix is not permitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109218 Bug ID: 109218 Summary: "MODULE SUBROUTINE" wrongly accepted where MODULE prefix is not permitted. Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: juergen.reuter at desy dot de Target Milestone: --- Reported at bug 109209 comment 9: > (In reply to Jürgen Reuter from bug 109209 comment #4) module resonances ... contains ... > > module subroutine t3_set_expand (res_set) ... > > Actually, the 'module subroutine' here needs to be just 'subroutine'. > gfortran accepts this, nagfor doesn't. * * * This probably violates one of the 'prefix' constraints of Fortran 2018, C1547 to C1551. I think it violates: C1548 (R1526) If MODULE appears in the prefix of a module subprogram, it shall have been declared to be a separate module procedure in the containing program unit or an ancestor of that program unit. * * * Testcase: bug 109209 comment 4
[Bug libgcc/109217] New: failure statically linking shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217
Bug ID: 109217
Summary: failure statically linking shared lib
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Use any dummy source like this:
void foo(void) {}
Then:
$ cc -Wall -o libmain.so -shared main.c -static
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/crtbeginT.o: relocation
R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a
shared object
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #10 from Jürgen Reuter --- (In reply to Tobias Burnus from comment #8) > The debugger shows for the example in comment 4 for the line > >69 | history_new(1:s) = res_set%history(1:s) > > the following expression: > > (gdb) p gfc_debug_expr(expr) > t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) % > resonances(FULL) > > That's F03:C614 - or in F2018: > > C919 (R911) There shall not be more than one part-ref with nonzero rank. A > part-name to the right of a part-ref with nonzero rank shall not have the > ALLOCATABLE or POINTER attribute. > > For the 'expr' shown in the debugger, that's violated as 'resonances' is > allocatable. > > > The 'expr' shown above is generated via >generate_component_assignments -> gfc_resolve_expr > -> resolve_variable -> gfc_resolve_ref > where generate_component_assignments's gfc_debug_code(*code) is > ASSIGN > t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) > t3_set_expand:res_set % history(1:__convert_i4_i8[[((t3_set_expand:s))]]) > which matches the user code and looks fine. > > (BTW: We should also check whether there is now an issue with generating > redundant (re)allocate on assignment code in trans*.cc.) Thanks for checking, Tobias. Are you saying that the code violates the standard, or the code generation after parsing by gcc/gfortran has generated code violating the standard?
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #9 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #4) > > module subroutine t3_set_expand (res_set) > class(t3_set_t), intent(inout) :: res_set > type(t3_t), dimension(:), allocatable :: history_new > integer :: s > s = size (res_set%history) > allocate (history_new (2 * s)) > history_new(1:s) = res_set%history(1:s) > call move_alloc (history_new, res_set%history) > end subroutine t3_set_expand > > end module resonances Actually, the 'module subroutine' here needs to be just 'subroutine'. gfortran accepts this, nagfor doesn't.
[Bug libfortran/109207] Uninitialised static variables in unit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109207 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-03-20 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- >Initially unit_cache[0..2] is not NULL. Yes they are by definition. That is: ``` #define CACHE_SIZE 3 static gfc_unit *unit_cache[CACHE_SIZE]; ... gfc_unit *unit_root; ``` Since they are not in the auto scope, they are static scope and initialized to 0 by default. Your fix does not change anything really.
