[Bug c++/82647] New: std::tuple_size_v is missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82647
Bug ID: 82647
Summary: std::tuple_size_v is missing from and
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bitbug1985 at icloud dot com
Target Milestone: ---
x.cpp:
#include
int
main()
{
std::array arr;
auto size = std::tuple_size_v;
}
% g++ --version
g++ (MacPorts gcc7 7.2.0_0) 7.2.0
% g++ -std=c++17 -o x x.cpp
x.cpp: In function 'int main()':
x.cpp:7:22: error: 'tuple_size_v' is not a member of 'std'
auto size = std::tuple_size_v;
^~~~
x.cpp:7:22: note: suggested alternative: 'tuple_size'
auto size = std::tuple_size_v;
^~~~
tuple_size
x.cpp:7:35: error: expected primary-expression before 'decltype'
auto size = std::tuple_size_v;
^~~~
I get the same error if I replace std::array with std::pair. If I additionally
include , which should be unnecessary, this compiles. For what it's
worth, it compiles as-is in clang++.
[Bug libstdc++/82647] std::tuple_size_v is missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82647 --- Comment #1 from Andrew Pinski --- >If I additionally include , which should be unnecessary, this compiles. I don't have the final C++17 spec but the draft (dated March 21, 2017, doc N4659) says tuple_size_v is defined in tuple and no other header file.
[Bug c++/82611] Incorrect warning for redundant capture in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82611 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- The diagnostic is required by the standard. [expr.prim.lambda.capture]/2 (http://wg21.link/expr.prim.lambda.capture#2.sentence-2): If a lambda-capture includes a capture-default that is =, each simple-capture of that lambda-capture shall be of the form “& identifier”, “this”, or “* this”.
[Bug fortran/57096] Allocatable variable is not behaved as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #7) > Let's close this one. Please don't. I still see the wrong output with gfortran 7.2. Dominique, did you consider the fact that two separate files are required to trigger the bug?
[Bug c++/79994] Concepts technical specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79994
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Simplified:
template
concept bool Graph = requires (G& g) {
add(g);
};
template
void add(T& g) {
};
class Directed_Graph_impl {};
int main() {
Directed_Graph_impl t;
add(t);
}
The problem seems to be that the instantiation of `add` requires the
instantiation of `Graph` concept, but the latter, in turn, requires the former.
This leads to an infinite recursion and eventually causes segfault.
[Bug fortran/57096] Allocatable variable is not behaved as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096 --- Comment #9 from Dominique d'Humieres --- > Dominique, did you consider the fact that two separate files are required > to trigger the bug? With the original code % gfortran-fsf-4.8 -c -std=f2003 ModA.f03 % gfortran-fsf-4.8 -c -std=f2003 ModA1.f03 % gfortran-fsf-4.8 -c -std=f2003 ModA2.f03 % gfortran-fsf-4.8 -c -std=f2003 test.f03 % gfortran-fsf-4.8 ModA.f03 ModA1.f03 ModA2.f03 test.f03 Main.cc % ./a.out gA%next(): 2 gA%next(): 4 gA%next(): 6 gAp%next(): 2 gAp%next(): 4 gAp%next(): 6
[Bug c++/82611] Incorrect warning for redundant capture in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82611 --- Comment #2 from James Tanner --- In that case it seems as though the standard has overlooked this scenario, as there is no way to achieve this without incurring a warning message.
[Bug fortran/82587] [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82587 --- Comment #2 from Paul Thomas --- Author: pault Date: Sat Oct 21 09:02:17 2017 New Revision: 253970 URL: https://gcc.gnu.org/viewcvs?rev=253970&root=gcc&view=rev Log: 2017-10-21 Paul Thomas PR fortran/82586 * decl.c (gfc_get_pdt_instance): Remove the error message that the parameter does not have a corresponding component since this is now taken care of when the derived type is resolved. Go straight to error return instead. (gfc_match_formal_arglist): Make the PDT relevant errors immediate so that parsing of the derived type can continue. (gfc_match_derived_decl): Do not check the match status on return from gfc_match_formal_arglist for the same reason. * resolve.c (resolve_fl_derived0): Check that each type parameter has a corresponding component. PR fortran/82587 * resolve.c (resolve_generic_f): Check that the derived type can be used before resolving the struture constructor. PR fortran/82589 * symbol.c (check_conflict): Add the conflicts involving PDT KIND and LEN attributes. 2017-10-21 Paul Thomas PR fortran/82586 * gfortran.dg/pdt_16.f03 : New test. * gfortran.dg/pdt_4.f03 : Catch the changed messages. * gfortran.dg/pdt_8.f03 : Ditto. PR fortran/82587 * gfortran.dg/pdt_17.f03 : New test. PR fortran/82589 * gfortran.dg/pdt_18.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pdt_16.f03 trunk/gcc/testsuite/gfortran.dg/pdt_17.f03 trunk/gcc/testsuite/gfortran.dg/pdt_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_4.f03 trunk/gcc/testsuite/gfortran.dg/pdt_8.f03
[Bug fortran/82586] [PDT] ICE: write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Oct 21 09:02:17 2017 New Revision: 253970 URL: https://gcc.gnu.org/viewcvs?rev=253970&root=gcc&view=rev Log: 2017-10-21 Paul Thomas PR fortran/82586 * decl.c (gfc_get_pdt_instance): Remove the error message that the parameter does not have a corresponding component since this is now taken care of when the derived type is resolved. Go straight to error return instead. (gfc_match_formal_arglist): Make the PDT relevant errors immediate so that parsing of the derived type can continue. (gfc_match_derived_decl): Do not check the match status on return from gfc_match_formal_arglist for the same reason. * resolve.c (resolve_fl_derived0): Check that each type parameter has a corresponding component. PR fortran/82587 * resolve.c (resolve_generic_f): Check that the derived type can be used before resolving the struture constructor. PR fortran/82589 * symbol.c (check_conflict): Add the conflicts involving PDT KIND and LEN attributes. 2017-10-21 Paul Thomas PR fortran/82586 * gfortran.dg/pdt_16.f03 : New test. * gfortran.dg/pdt_4.f03 : Catch the changed messages. * gfortran.dg/pdt_8.f03 : Ditto. PR fortran/82587 * gfortran.dg/pdt_17.f03 : New test. PR fortran/82589 * gfortran.dg/pdt_18.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pdt_16.f03 trunk/gcc/testsuite/gfortran.dg/pdt_17.f03 trunk/gcc/testsuite/gfortran.dg/pdt_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_4.f03 trunk/gcc/testsuite/gfortran.dg/pdt_8.f03
[Bug fortran/82589] [PDT] ICE in gfc_get_pdt_instance, at fortran/decl.c:3278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82589 --- Comment #3 from Paul Thomas --- Author: pault Date: Sat Oct 21 09:02:17 2017 New Revision: 253970 URL: https://gcc.gnu.org/viewcvs?rev=253970&root=gcc&view=rev Log: 2017-10-21 Paul Thomas PR fortran/82586 * decl.c (gfc_get_pdt_instance): Remove the error message that the parameter does not have a corresponding component since this is now taken care of when the derived type is resolved. Go straight to error return instead. (gfc_match_formal_arglist): Make the PDT relevant errors immediate so that parsing of the derived type can continue. (gfc_match_derived_decl): Do not check the match status on return from gfc_match_formal_arglist for the same reason. * resolve.c (resolve_fl_derived0): Check that each type parameter has a corresponding component. PR fortran/82587 * resolve.c (resolve_generic_f): Check that the derived type can be used before resolving the struture constructor. PR fortran/82589 * symbol.c (check_conflict): Add the conflicts involving PDT KIND and LEN attributes. 2017-10-21 Paul Thomas PR fortran/82586 * gfortran.dg/pdt_16.f03 : New test. * gfortran.dg/pdt_4.f03 : Catch the changed messages. * gfortran.dg/pdt_8.f03 : Ditto. PR fortran/82587 * gfortran.dg/pdt_17.f03 : New test. PR fortran/82589 * gfortran.dg/pdt_18.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pdt_16.f03 trunk/gcc/testsuite/gfortran.dg/pdt_17.f03 trunk/gcc/testsuite/gfortran.dg/pdt_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_4.f03 trunk/gcc/testsuite/gfortran.dg/pdt_8.f03
[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839 --- Comment #8 from Paolo Carlini --- Hi. As you can see, the patch itself seems simple, but a while ago I noticed that quite a few testcases would need adjusting and that made me a little nervous. In particular those testcases (both C and C++) which are doing more than one check and would have to be split, because the compilation ends after the first #error. Anyway, probably that's just boring work to do, what about the other compilers? For sure some are following the current gcc behaviour, for compatibility, I suspect ICC for example. Should we also have a command line switch? Probably missing #includes just unconditionally end the compilation on most compilers, though. Well, it's also true that the so called workaround which I mentioned in Comment #1 works pretty well and we do have *very* few fatal errors in the front ends...
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 82586, which changed state. Bug 82586 Summary: [PDT] ICE: write_symbol(): bad module symbol https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/82586] [PDT] ICE: write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on 8-branch. Thanks for the report and for the effort that you put in to develop these broken bits of code. This really improved the quality of implementation. Best regards Paul
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628 --- Comment #11 from Jakub Jelinek --- Created attachment 42428 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42428&action=edit gcc8-pr82628.patch Untested patch. From the above hack, I'm afraid I have no idea how to express the SF+OF setting sbb, so I'm using UNSPEC, for the others I hope I've done those right, but would welcome verification. If you have ideas what to do for SF+OF, I'd appreciate it. And the patch doesn't deal with possible needs to rename CCGZmode to something else and describe that it only defines SF and OF flags. Or can we just use normal CCmode, when the setter is UNSPEC anyway and thus the generic code can't argue much about it?
[Bug other/82648] New: libiberty/regex.c:2364]: pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82648 Bug ID: 82648 Summary: libiberty/regex.c:2364]: pointless test ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/libiberty/regex.c:2364]: (style) Checking if unsigned variable 'size' is less than zero. Source code is if (size < 0) but size_t size; Maybe the error return value from function convert_mbs_to_wcs is zero and so the test should be if (size == 0)
[Bug gcov-profile/82633] Document GCOV and function removal (-fkeep-inline-functions, -fkeep-static-functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82633
Martin Liška changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Last reconfirmed||2017-10-21
Resolution|WONTFIX |---
Target Milestone|--- |8.0
Summary|gcov does not handle|Document GCOV and function
|removed functions |removal
||(-fkeep-inline-functions,
||-fkeep-static-functions)
Ever confirmed|0 |1
--- Comment #9 from Martin Liška ---
Thanks Andrew, works for me:
$ g++ -fkeep-inline-functions -fkeep-static-functions --coverage removed.cpp
-:1:class MyClass2
-:2:{
-:3: public:
#:4:void iterate() { a = 5; }
-:5:
-:6:int a;
-:7:};
-:8:
#:9:static int foo(int a)
-: 10:{
#: 11: return ++a;
-: 12:}
-: 13:
#: 14:int bar(int a)
-: 15:{
#: 16: return a + 2;
-: 17:}
-: 18:
1: 19:int main()
-: 20:{
-: 21: MyClass2 a;
1: 22: return 0;
-: 23:}
Let me document that, maybe useful for GCOV users.
[Bug libstdc++/82647] std::tuple_size_v is missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82647 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Andrew is correct, it's only defined by . http://en.cppreference.com/w/cpp/utility/tuple/tuple_size
[Bug c++/79994] Concepts technical specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79994 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-21 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- I *think* this is invalid, but I'm not sure.
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 82587, which changed state. Bug 82587 Summary: [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82587 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/82589] [PDT] ICE in gfc_get_pdt_instance, at fortran/decl.c:3278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82589 --- Comment #4 from Paul Thomas --- Fixed on 8-branch. Thank you for working on this and getting in these problem reports. Paul
[Bug fortran/82587] [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82587 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Paul Thomas --- Fixed on 8-branch. Thank you for working on this and getting in these problem reports. Paul
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 82589, which changed state. Bug 82589 Summary: [PDT] ICE in gfc_get_pdt_instance, at fortran/decl.c:3278 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82589 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/82589] [PDT] ICE in gfc_get_pdt_instance, at fortran/decl.c:3278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82589 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Duuuh! It helps to close the PR
[Bug bootstrap/28758] `make` fails because of bad ORIGINAL_LD_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28758 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Eric Gallager --- Closing due to no response after being left in WAITING for so long.
[Bug bootstrap/32840] bootstrap broken on ix86-linux-gnu targets with --enable-targets=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32840 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to H.J. Lu from comment #1) > > Can you verify if it is the same as PR 31868? There is a a patch for PR > > 31868. > > ...which is now closed as FIXED. So is this fixed as well? No response, so I'm assuming the answer was yes.
[Bug bootstrap/31840] race condition in makefiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31840 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Could you be more specific about how exactly bootstrap fails? What is the > error message? No response; closing.
[Bug c++/82613] Cannot access private definitions in base clause of friend class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82613 --- Comment #1 from fabian.loeschner at live dot de --- By the way: it compiles fine with Clang trunk and in Visual Studio 2017 (MSVC 19.11)
[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #21 from Thomas Koenig ---
We could do something like
program boom
implicit none
interface
subroutine mywait() bind(c)
end subroutine mywait
end interface
integer :: i,j
character(len=256):: msg
character(len=:), allocatable :: command
command='notthere'
msg='' ! seems to only be defined if exitstatus.ne.0
! ok -- these work
call execute_command_line(command , wait=.false., exitstat=i, cmdstat=j,
cmdmsg=msg)
if (j /= 0 .or. msg /= '') call abort
call execute_command_line(command , exitstat=i, cmdstat=j,
cmdmsg=msg )
if (j /= 3 .or. msg /= "Invalid command line" ) call abort
msg = ''
call execute_command_line(command , wait=.false., exitstat=i,
cmdmsg=msg )
print *,msg
if (msg /= '') call abort
call execute_command_line(command , exitstat=i, cmdstat=j
)
if (j /= 3) call abort
call execute_command_line(command , wait=.false., exitstat=i
)
call mywait()
end program boom
and
#include
#include
#include
#include
/* Wait in a busy loop for any processes that may still be around. */
void mywait()
{
errno = 0;
while (waitpid (-1, NULL, WNOHANG) >= 0)
{
n++;
if (errno != ECHILD)
break;
}
}
but I am not sure that waitpid is available on all systems;
this is more likely to break things than fix things.
What you could to to reduce the amount of noise that you see is
sleep for a second; just insert
CALL SLEEP(1)
before the END statement of the test case, locally in your tree.
This could help. I don't want to do this for everybody (test times
being long enough as they are), but for most cases, this should
be enough.
[Bug fortran/82649] New: (PDT) Invalid error for assumed parameters in ALLOCATE typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82649
Bug ID: 82649
Summary: (PDT) Invalid error for assumed parameters in ALLOCATE
typespec
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pault at gcc dot gnu.org
Target Milestone: ---
From Reinhold Bader:
module matrix_mod_assumed_02
implicit none
type :: matrix(rk, n, m)
integer, kind :: rk
integer, len :: n, m
real(rk) :: entry(n, m)
end type matrix
integer, parameter :: rk=kind(1.d0)
integer, parameter :: mm=20, nn=15
contains
subroutine factory(o_matrix)
type(matrix(rk, *, *)), allocatable :: o_matrix
allocate(matrix(rk, *, *) :: o_matrix)
end subroutine
end module
program test
use matrix_mod_assumed_02
implicit none
type(matrix(rk, nn, mm)), allocatable :: o_matrix
call factory(o_matrix)
if (o_matrix%n == nn .and. o_matrix%m == mm) then
write(*,*) 'OK'
else
write(*,*) o_matrix%n, o_matrix%m
write(*,*) 'FAIL'
end if
end program test
par_assumed_02_pos.f90:16:13:
allocate(matrix(rk, *, *) :: o_matrix)
1
Error: The type parameter spec list in the type-spec at (1) cannot contain
ASSUMED or DEFERRED parameters
This is easily fixed at match.c:4010 by eliminating the error for assumed
parameters:
Index: ../trunk/gcc/fortran/match.c
===
*** ../trunk/gcc/fortran/match.c(revision 253969)
--- ../trunk/gcc/fortran/match.c(working copy)
*** gfc_match_allocate (void)
*** 4007,4016
/* TODO understand why this error does not appear but, instead,
the derived type is caught as a variable in primary.c. */
! if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT)
{
gfc_error ("The type parameter spec list in the type-spec at "
!"%L cannot contain ASSUMED or DEFERRED parameters",
&old_locus);
goto cleanup;
}
--- 4007,4016
/* TODO understand why this error does not appear but, instead,
the derived type is caught as a variable in primary.c. */
! if (gfc_spec_list_type (type_param_spec_list, NULL) == SPEC_DEFERRED)
{
gfc_error ("The type parameter spec list in the type-spec at "
!"%L cannot contain DEFERRED parameters",
&old_locus);
goto cleanup;
}
This, however, exposes the real problem and the reason why the error was
introduced in the first place.
[pault@pc30 reinhold]$ ~/irun/bin/gfortran -static-libgfortran
par_assumed_02_pos.f90 -fdump-tree-original
par_assumed_02_pos.f90:16:0:
allocate(matrix(rk, *, *) :: o_matrix)
internal compiler error: Segmentation fault
0xcc160f crash_signal
../../trunk/gcc/toplev.c:326
0x70419d insert_parameter_exprs
../../trunk/gcc/fortran/decl.c:3154
0x7204ed gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
../../trunk/gcc/fortran/expr.c:4636
0x7cf492 structure_alloc_comps
../../trunk/gcc/fortran/trans-array.c:9041
0x7d10f0 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
../../trunk/gcc/fortran/trans-array.c:9300
0x84d2ad gfc_trans_allocate(gfc_code*)
../../trunk/gcc/fortran/trans-stmt.c:6407
0x7bacf7 trans_code
../../trunk/gcc/fortran/trans.c:1976
0x7ee087 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6422
0x7bfc91 gfc_generate_module_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:2202
0x7725cb translate_all_program_units
../../trunk/gcc/fortran/parse.c:6075
0x7725cb gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6291
0x7b70ff gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
As far as I can see at the moment, this can only be fixed by the introduction
of a PDT descriptor for allocatable and pointer objects.
I have been walking around this problem trying to come up with an alternative
but have been unable to do so. I have a week away in a cottage in Cornwall
soon. If I haven't come up with anything by then, I will bite the bullet and
will implement the descriptor.
Cheers
Paul
[Bug fortran/82649] (PDT) Invalid error for assumed parameters in ALLOCATE typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82649 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-21 Blocks||82173 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- I'll take it :-) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug c++/82650] New: -fdump-go-spec Segmentation fault on enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82650
Bug ID: 82650
Summary: -fdump-go-spec Segmentation fault on enums
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: avshash at hotmail dot com
Target Milestone: ---
Using the '-fdump-go-spec' flag causes Segmentation fault when program has any
enum definition on c++ files.
Example:
---
enum dummy_t
{
DUMMY_ENUM
};
int main ()
{
return 0
}
command line - g++ main.cc -fdump-go-spec=dummy.go
reason is the difference in enum tree between C and C++
Patch in 'godump.c', function 'go_output_typedef'
(correct fix should be a proper function)
-
ADD:
tree integer_cst = TREE_VALUE (element);
if (TREE_CODE (integer_cst) == CONST_DECL) {
integer_cst = DECL_INITIAL (integer_cst);
}
if (TREE_CODE (integer_cst) != INTEGER_CST) {
internal_error ("...");
}
CHANGE:
if (tree_fits_shwi_p (integer_cst)) {
// CHANGE ^^^
snprintf (buf, sizeof (buf), HOST_WIDE_INT_PRINT_DEC,
tree_to_shwi (integer_cst));
// CHANGE ^^^
}
else if (tree_fits_uhwi_p (integer_cst)) {
// CHANGE ^^^
snprintf (buf, sizeof (buf), HOST_WIDE_INT_PRINT_UNSIGNED,
tree_to_uhwi (integer_cst));
// CHANGE ^^^
}
else {
print_hex (wi::to_wide (integer_cst, buf));
// CHANGE ^^^
// the last one is also a bug in the C branch,
// where there is a 'TREE_VALUE' missing
// but unreachable code on my machine.
}
[Bug fortran/57096] Allocatable variable is not behaved as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096 --- Comment #10 from janus at gcc dot gnu.org --- If I take the tarball from comment 0, unpack it, run "make" and then "./test", I get: gA%next(): 0 gA%next(): 0 gA%next(): 0 gAp%next(): 2 gAp%next(): 4 gAp%next(): 6
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628 --- Comment #12 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #11) > Created attachment 42428 [details] > gcc8-pr82628.patch > > Untested patch. From the above hack, I'm afraid I have no idea how to > express the SF+OF setting sbb, so I'm using UNSPEC, for the others I hope > I've done those right, but would welcome verification. If you have ideas > what to do for SF+OF, I'd appreciate it. And the patch doesn't deal with > possible needs to rename CCGZmode to something else and describe that it > only defines SF and OF flags. Or can we just use normal CCmode, when the > setter is UNSPEC anyway and thus the generic code can't argue much about it? Unfortunately it doesn't bootstrap. The problem is sub3_carry_ccc pattern which allows CONST_INT operands[2], but has zero_extend around it, which is invalid RTL. I think we'd need two patterns then, one with nonimmediate_operandand "rm" constraint (or even what it is in the patch, just have GET_MODE (operands[2]) != VOIDmode in the condition), and another pattern that would accept the valid const_int_operand (!TARGET_64BIT) or const_scalar_int_operand (TARGET_64BIT). The rule for -m32 is that it is CONST_INT with UINTVAL (operands[2]) <= 0xUL, for -m64 it is that either it is a CONST_INT with UINTVAL (operands[2]) <= 0x7fffUL, or it is a CONST_WIDE_INT >= 0x8000ULL and <= 0xULL (i.e. constant integer x86_64_immediate_operand (op, DImode) zero extended from DImode to TImode).
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #13 from Paul Thomas --- (In reply to Thomas Koenig from comment #12) > And with r241439, the test fails. > > Andre, any ideas? This is sufficiently similar to PR82312 that I applied the patch for it to 7-branch (which I had to do anyway) and tried this code. Unfortunately, it doesn't fix this problem. The fix for PR82312 reverted some of the code in revision 241439 and so this is certainly the right path to follow. I have to leave this for a while. It is a pity that the failing code is indeed very difficult to reduce. Cheers Paul
[Bug c++/52202] [C++11][DR 1376] Should not extend lifetime of temporary wrapped in static_cast to reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52202 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #2 from ensadc at mailnesia dot com --- Superseded by issue 1299? See http://wg21.link/p0727.
[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360 Hunter L. Allen changed: What|Removed |Added CC||hunter at openrobotics dot org --- Comment #5 from Hunter L. Allen --- I'm also affected.
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #14 from Paul Thomas ---
The chunk of offending code:
val_p=>NULL(); cep=>NULL()
cep=>this%element(offset,errc)
if(errc.eq.GFC_SUCCESS.and.associated(cep)) then
val_p=>cep%get_value(errc)
is translated to:
val_p._vptr = (struct __vtype__STAR * {ref-all}) &__vtab__STAR;
val_p._len = 0;
val_p._data = 0B;
cep._vptr = (struct __vtype_gfc_base_Gfc_cont_elem_t * {ref-all})
&__vtab_gfc_base_Gfc_cont_elem_t;
cep._data = 0B;
{
struct __class_gfc_base_Gfc_cont_elem_t_p rhs.69;
rhs.69 = this->_vptr->element ((struct __class_gfc_vector_Vector_iter_t_t
*) this, (integer(kind=8) *) offset, &errc);
cep._vptr = rhs.69._vptr;
cep._data = rhs.69._data;
}
if ((logical(kind=4)) (errc == 0 && cep._data != 0B))
{
{
struct __class_gfc_base_Gfc_cont_elem_t_t this.70;
struct __class__STAR_p rhs.71;
this.70 = VIEW_CONVERT_EXPR(cep);
rhs.71 = cep._vptr->get_value (&this.70, &errc);
val_p._vptr = rhs.71._vptr;
val_p._len = 0;
val_p._data = rhs.71._data;
}
}
Now if I change class(gfc_cont_elem_t), pointer:: cep
to type(gfc_cont_elem_t), pointer:: cep
The code runs correctly - well, all the tests pass and there is no segfault :-)
From the NULLing of cep, the code becomes:
cep = 0B;
{
struct __class_gfc_base_Gfc_cont_elem_t_p D.4458;
D.4458 = this->_vptr->element ((struct __class_gfc_vector_Vector_iter_t_t
*) this, (integer(kind=8) *) offset, &errc);
cep = D.4458._data;
}
if ((logical(kind=4)) (errc == 0 && cep != 0B))
{
{
struct __class_gfc_base_Gfc_cont_elem_t_t class.69;
struct __class__STAR_p rhs.70;
class.69._vptr = (struct __vtype_gfc_base_Gfc_cont_elem_t * {ref-all})
&__vtab_gfc_base_Gfc_cont_elem_t;
class.69._data = cep;
rhs.70 = contelemgetvalue (&class.69, &errc);
val_p._vptr = rhs.70._vptr;
val_p._len = 0;
val_p._data = rhs.70._data;
}
This corresponds to trans_class_vptr_len_assignment NOT being called. I am
rather sure that there is some failure of logic in it.
Paul
[Bug bootstrap/82651] New: After -r 253879 GCC 8.0 can't build cross compiler for mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82651 Bug ID: 82651 Summary: After -r 253879 GCC 8.0 can't build cross compiler for mingw32 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mateuszb at poczta dot onet.pl Target Milestone: --- -r 253878 works OK (for mingw32), -r 253879 breaks build cross compiler with error: g++ -fno-PIE -c -pipe -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/ma/m/source/gcc-8/gcc -I/home/ma/m/source/gcc-8/gcc/. -I/home/ma/m/source/gcc-8/gcc/../include -I/home/ma/m/source/gcc-8/gcc/../libcpp/include -I/home/ma/m/build/for_cross/include -I/home/ma/m/build/for_cross/include -I/home/ma/m/build/for_cross/include -I/home/ma/m/source/gcc-8/gcc/../libdecnumber -I/home/ma/m/source/gcc-8/gcc/../libdecnumber/bid -I../libdecnumber -I/home/ma/m/source/gcc-8/gcc/../libbacktrace -I/home/ma/m/build/for_cross/include -o gimplify.o -MT gimplify.o -MMD -MP -MF ./.deps/gimplify.TPo /home/ma/m/source/gcc-8/gcc/gimplify.c In file included from ./tm.h:20:0, from /home/ma/m/source/gcc-8/gcc/backend.h:28, from /home/ma/m/source/gcc-8/gcc/gimplify.c:26: /home/ma/m/source/gcc-8/gcc/gimplify.c: In function ‘gimplify_status gimplify_decl_expr(tree_node**, gimple**)’: /home/ma/m/source/gcc-8/gcc/config/i386/i386.h:609:61: error: ‘ix86_cfun_abi’ was not declared in this scope #define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI) ^ /home/ma/m/source/gcc-8/gcc/config/i386/cygming.h:35:22: note: in expansion of macro ‘TARGET_64BIT_MS_ABI’ #define TARGET_SEH (TARGET_64BIT_MS_ABI && flag_unwind_tables) ^ /home/ma/m/source/gcc-8/gcc/config/i386/cygming.h:40:31: note: in expansion of macro ‘TARGET_SEH’ #define MAX_STACK_ALIGNMENT (TARGET_SEH ? 128 : MAX_OFILE_ALIGNMENT) ^ /home/ma/m/source/gcc-8/gcc/defaults.h:1142:39: note: in expansion of macro ‘MAX_STACK_ALIGNMENT’ #define MAX_SUPPORTED_STACK_ALIGNMENT MAX_STACK_ALIGNMENT ^ /home/ma/m/source/gcc-8/gcc/gimplify.c:1659:28: note: in expansion of macro ‘MAX_SUPPORTED_STACK_ALIGNMENT’ && DECL_ALIGN (decl) <= MAX_SUPPORTED_STACK_ALIGNMENT ^ /home/ma/m/source/gcc-8/gcc/gimplify.c: In function ‘gimplify_status gimplify_target_expr(tree_node**, gimple**, gimple**)’: /home/ma/m/source/gcc-8/gcc/config/i386/i386.h:609:61: error: ‘ix86_cfun_abi’ was not declared in this scope #define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI) ^ /home/ma/m/source/gcc-8/gcc/config/i386/cygming.h:35:22: note: in expansion of macro ‘TARGET_64BIT_MS_ABI’ #define TARGET_SEH (TARGET_64BIT_MS_ABI && flag_unwind_tables) ^ /home/ma/m/source/gcc-8/gcc/config/i386/cygming.h:40:31: note: in expansion of macro ‘TARGET_SEH’ #define MAX_STACK_ALIGNMENT (TARGET_SEH ? 128 : MAX_OFILE_ALIGNMENT) ^ /home/ma/m/source/gcc-8/gcc/defaults.h:1142:39: note: in expansion of macro ‘MAX_STACK_ALIGNMENT’ #define MAX_SUPPORTED_STACK_ALIGNMENT MAX_STACK_ALIGNMENT ^ /home/ma/m/source/gcc-8/gcc/gimplify.c:6510:32: note: in expansion of macro ‘MAX_SUPPORTED_STACK_ALIGNMENT’ && DECL_ALIGN (temp) <= MAX_SUPPORTED_STACK_ALIGNMENT ^ Makefile:1104: recipe for target 'gimplify.o' failed make[1]: *** [gimplify.o] Error 1 make[1]: Leaving directory '/home/ma/m/build/bc_gcc/gcc' Makefile:4285: recipe for target 'all-gcc' failed make: *** [all-gcc] Error 2
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #14 from Steven Noonan ---
"testcase.i" can be reduced a lot (thanks creduce!). Literally just this:
---
__attribute__((target_clones("arch=sandybridge", "default"))) static _saxpy() {
#pragma omp parallel
;
}
saxpy() {}
---
is sufficient to demonstrate the link issue (compile with/without -fopemp)
[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #12 from Thomas Koenig --- The best thing to do would be to only have the version with index_type, and then convert the result if necessary.
[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #13 from Thomas Koenig --- Created attachment 42429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42429&action=edit Patch which works for maxloc except for some cases This patch works, sort of, but it fails with a segfault for program main real, dimension(3) :: a call random_number(a) print *, maxloc(a) end program main Let's try some more things here...
[Bug fortran/82312] [7/8 Regression] [OOP] Pointer assignment to component of class variable results wrong vptr for the variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82312 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Oct 21 17:09:43 2017 New Revision: 253976 URL: https://gcc.gnu.org/viewcvs?rev=253976&root=gcc&view=rev Log: 2017-10-21 Paul Thomas PR fortran/82312 * resolve.c (gfc_resolve_code): Simplify condition for class pointer assignments becoming regular assignments by asserting that only class valued targets are permitted. * trans-expr.c (trans_class_pointer_fcn): New function using a block of code from gfc_trans_pointer_assignment. (gfc_trans_pointer_assignment): Call the new function. Tidy up a minor whitespace issue. 2017-10-21 Paul Thomas PR fortran/82312 * gfortran.dg/typebound_proc_36.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/typebound_proc_36.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/82312] [7/8 Regression] [OOP] Pointer assignment to component of class variable results wrong vptr for the variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82312 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on 7- and 8-branches. Paul
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 Frank Denis changed: What|Removed |Added CC||gnu at pureftpd dot org --- Comment #12 from Frank Denis --- Any update on this?
[Bug fortran/57096] Allocatable variable is not behaved as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096 --- Comment #11 from Jerry DeLisle --- (In reply to janus from comment #8) > (In reply to Jerry DeLisle from comment #7) > > Let's close this one. > > Please don't. I still see the wrong output with gfortran 7.2. > > Dominique, did you consider the fact that two separate files are required to > trigger the bug? Sure, what is the status of your draft patch?
[Bug fortran/82312] [7/8 Regression] [OOP] Pointer assignment to component of class variable results wrong vptr for the variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82312 Paul Thomas changed: What|Removed |Added CC||jdhughes at usgs dot gov --- Comment #6 from Paul Thomas --- *** Bug 81898 has been marked as a duplicate of this bug. ***
[Bug fortran/81898] [7/8 Regression] [OOP] Issue with polymorphic container class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81898 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #5 from Paul Thomas --- Hi Joe, Many thanks for your report. As it happens, this is a duplicate and so you won't get to achieve fame and fortune as the contributor of a testcase - sorry about that. Please keep on supporting us with bug reports. Paul *** This bug has been marked as a duplicate of bug 82312 ***
[Bug middle-end/82652] New: missing -Wstringop-overflow on strncpy with -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82652
Bug ID: 82652
Summary: missing -Wstringop-overflow on strncpy with
-fcheck-pointer-bounds
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When compiling without -fcheck-pointer-bounds the buffer overflow in all of the
calls below are diagnosed. But when using -fcheck-pointer-bounds -mmpx none of
them is.
$ cat a.c && gcc -O2 -S -Wall -fcheck-pointer-bounds -mmpx a.c
extern char* stpncpy (char*, const char*, __SIZE_TYPE__);
extern char* strncpy (char*, const char*, __SIZE_TYPE__);
#define S "01234567"
char a[4];
char* f0 (void)
{
return strncpy (a, S, sizeof S); // missing -Wstringop-overflow
}
char* f1 (void)
{
char b[sizeof S];
__builtin_strcpy (b, S);
return strncpy (a, b, sizeof b); // missing -Wstringop-overflow
}
char* g0 (void)
{
return stpncpy (a, S, sizeof S); // missing -Wstringop-overflow
}
char* g1 (void)
{
char b[sizeof S];
__builtin_strcpy (b, S);
return stpncpy (a, b, sizeof b); // missing -Wstringop-overflow
}
The expected output is something like this (from the trunk of GCC 8.0; GCC 7.2
only diagnoses f0 and f1):
a.c: In function ‘f0’:
a.c:10:10: warning: ‘__builtin_memcpy’ writing 9 bytes into a region of size 4
overflows the destination [-Wstringop-overflow=]
return strncpy (a, S, sizeof S);
^~~~
a.c: In function ‘f1’:
a.c:18:10: warning: ‘strncpy’ writing 9 bytes into a region of size 4 overflows
the destination [-Wstringop-overflow=]
return strncpy (a, b, sizeof b);
^~~~
a.c: In function ‘g0’:
a.c:23:10: warning: ‘stpncpy’ writing 9 bytes into a region of size 4 overflows
the destination [-Wstringop-overflow=]
return stpncpy (a, S, sizeof S);
^~~~
a.c: In function ‘g1’:
a.c:31:10: warning: ‘stpncpy’ writing 9 bytes into a region of size 4 overflows
the destination [-Wstringop-overflow=]
return stpncpy (a, b, sizeof b);
^~~~
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628 Jakub Jelinek changed: What|Removed |Added Attachment #42428|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek --- Created attachment 42430 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42430&action=edit gcc8-pr82628.patch Updated patch. While this passes bootstrap, it still ICEs on a couple of tests, e.g. -std=c11 -pedantic-errors -O1 c11-atomic-exec-2.c. LRA doesn't like the new constraint or something.
[Bug fortran/82653] New: Parameters assigned with functions (instead of literals) cannot be used in other modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82653 Bug ID: 82653 Summary: Parameters assigned with functions (instead of literals) cannot be used in other modules Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gebeele at hotmail dot com Target Milestone: --- Error message: f951.exe: internal compiler error: in unquote_string, at fortran/module.c:1802 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. f951.exe: internal compiler error: Aborted I think I was able to isolate the bug in a few lines in two files. The used module (parameters.f90) is compiled. It contains parameters that have been assigned not with literals, but with intrinsic functions. However, the module that uses the parameters.f90 module is not compiled. for this one it works > gfortran -c parameters.f90 this does not work >gfortran -c check_use_parameters.f90 parameters.f90 module parameters ! parameters defined using a function ! this module is compiled by GNU-Fortran character(len=1), parameter :: NL=CHAR(10) ! Unix end of line character(len=1), parameter :: CR=CHAR(13) ! DOS carriage-return end module check_use_parameters.f90 module check_use_parameters use parameters ! if inside the used module parameters where defined with a function ! GNU-Fortran CANNOT compile this module real :: x ! this is just to write some other source code end module
[Bug middle-end/82652] missing -Wstringop-overflow on strncpy with -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82652
--- Comment #1 from Martin Sebor ---
The problem is that there are no BUILT_IN_{STPNCPY,STRNCAT,STRNCPY}_CHKP macros
so these built-ins, even though their built-in function codes exist, are
handled just like ordinary functions. To get the benefit of the compile-time
overflow checking the corresponding BUILT_IN_XXX_CHKP macros need to be added
along with handlers for them.
The following is the set of the built-ins for which the corresponding _CHKP
macros are defined.
$ find gcc -name "*.def" ! -path "*/testsuite/*" | xargs grep _CHKP | sed -n
"s/.*(\(BUILT_IN_[^, ]*\), *.*/\1/p" | sort -u
BUILT_IN_CHKP_BNDCL
BUILT_IN_CHKP_BNDCU
BUILT_IN_CHKP_BNDLDX
BUILT_IN_CHKP_BNDMK
BUILT_IN_CHKP_BNDRET
BUILT_IN_CHKP_BNDSTX
BUILT_IN_CHKP_CHECK_PTR_BOUNDS
BUILT_IN_CHKP_CHECK_PTR_LBOUNDS
BUILT_IN_CHKP_CHECK_PTR_UBOUNDS
BUILT_IN_CHKP_COPY_PTR_BOUNDS
BUILT_IN_CHKP_EXTRACT_LOWER
BUILT_IN_CHKP_EXTRACT_UPPER
BUILT_IN_CHKP_GET_PTR_LBOUND
BUILT_IN_CHKP_GET_PTR_UBOUND
BUILT_IN_CHKP_INIT_PTR_BOUNDS
BUILT_IN_CHKP_INTERSECT
BUILT_IN_CHKP_MEMCPY_NOBND
BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK
BUILT_IN_CHKP_MEMCPY_NOCHK
BUILT_IN_CHKP_MEMMOVE_NOBND
BUILT_IN_CHKP_MEMMOVE_NOBND_NOCHK
BUILT_IN_CHKP_MEMMOVE_NOCHK
BUILT_IN_CHKP_MEMPCPY_NOBND
BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK
BUILT_IN_CHKP_MEMPCPY_NOCHK
BUILT_IN_CHKP_MEMSET_NOBND
BUILT_IN_CHKP_MEMSET_NOBND_NOCHK
BUILT_IN_CHKP_MEMSET_NOCHK
BUILT_IN_CHKP_NARROW
BUILT_IN_CHKP_NARROW_PTR_BOUNDS
BUILT_IN_CHKP_NULL_PTR_BOUNDS
BUILT_IN_CHKP_SET_PTR_BOUNDS
BUILT_IN_CHKP_SIZEOF
BUILT_IN_CHKP_STORE_PTR_BOUNDS
BUILT_IN_MEMCPY
BUILT_IN_MEMCPY_CHK
BUILT_IN_MEMMOVE
BUILT_IN_MEMMOVE_CHK
BUILT_IN_MEMPCPY
BUILT_IN_MEMPCPY_CHK
BUILT_IN_MEMSET
BUILT_IN_MEMSET_CHK
BUILT_IN_STPCPY
BUILT_IN_STPCPY_CHK
BUILT_IN_STRCAT
BUILT_IN_STRCAT_CHK
BUILT_IN_STRCHR
BUILT_IN_STRCPY
BUILT_IN_STRCPY_CHK
BUILT_IN_STRLEN
[Bug c/82654] New: i386_cfun_abi() not defined at point of use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82654 Bug ID: 82654 Summary: i386_cfun_abi() not defined at point of use Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at intelretiree dot com Target Milestone: --- trunk build fails, apparently this function is not visible at point of use, target x86_64-pc-cygwin
[Bug bootstrap/82651] After r253879 GCC 8.0 can't build cross compiler for mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82651 Andrew Pinski changed: What|Removed |Added CC||tprince at intelretiree dot com --- Comment #1 from Andrew Pinski --- *** Bug 82654 has been marked as a duplicate of this bug. ***
[Bug c/82654] i386_cfun_abi() not defined at point of use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82654 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 82651 ***
[Bug middle-end/82655] New: missing -Walloc-size-larget-than with -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82655
Bug ID: 82655
Summary: missing -Walloc-size-larget-than with
-fcheck-pointer-bounds
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Without the -fcheck-pointer-bounds and -mmpx options, GCC issues a
-Walloc-size-larger-than warning for the following test case as expected. But
with the two options it fails to do the same.
$ cat y.c && gcc -O2 -S -Wall -Walloc-size-larger-than=1023
-fcheck-pointer-bounds -mmpx y.c
void* f (void *p, unsigned n)
{
if (n < 1024)
n = 1024;
return __builtin_realloc (p, n);
}
The expected output is:
y.c:6:10: warning: argument 2 range [1024, 4294967295] exceeds maximum object
size 1023 [-Walloc-size-larger-than=]
return __builtin_realloc (p, n);
^~~~
y.c:6:10: note: in a call to built-in allocation function ‘__builtin_realloc’
The problem is that that the maybe_warn_alloc_args_overflow() function in
calls.c fails to take into the account the difference between __builtin_realloc
signature when compiled with the option and without. When
-fcheck-pointer-bounds is used, __builtin_realloc is declared like so:
__builtin_realloc (void *ptr, bitsizetype ptrbounds, size_t n)
with bitsizetype being a 128 bit type. Ptrbounds is then (mistakenly) used in
get_size_range() called from maybe_warn_alloc_args_overflow() to try to
determine the range of the size of the allocation, which fails.
It seems to me that having -fcheck-pointer-bounds change the signature of
standard builtins wasn't the best idea, especially not changing the types of
existing arguments. If the new arguments had instead been added after the
existing arguments this kind of mixup would not have been possible.
[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 Andreas Tobler changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |andreast at gcc dot gnu.org --- Comment #11 from Andreas Tobler --- For the record, in gcc5 this one went in: md_unwind_header=i386/freebsd-unwind.h Before we had no MD_FALLBACK_FRAME_STATE_FOR. Will investigate.
[Bug tree-optimization/82656] New: memset buffer overflow not detected after realloc with -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82656
Bug ID: 82656
Summary: memset buffer overflow not detected after realloc with
-fcheck-pointer-bounds
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When the buggy program below is compiled without -fcheck-pointer-bounds it
triggers a -Wstringop-overflow warning due to the buffer overflow. Running the
program then aborts as the buffer overflow is detected.
But when the same program is compiled with -fcheck-pointer-bounds -mmpx there
is no warning at compile time and the program then runs with the buffer
overflow undetected. Since the entire purpose of the -fcheck-pointer-bounds
option is to detect invalid pointer accesses this seems like a severe bug
(hence the severity of major).
I suspect the root cause is the same as that of bug 82655: the signature of
__builtin_realloc is different with -fcheck-pointer-bounds than without (the
second argument is the pointer bounds in the former case and the allocation
size in the latter), but the function attributes are the same between both
built-ins. That includes the alloc_size attribute which specifies the argument
number of the allocation size.
Output without -fcheck-pointer-bounds:
$ cat y.c && gcc -O2 -Wall -D_FORTIFY_SOURCE=2 y.c && ./a.out
#include
void* __attribute__ ((noclone, noinline))
f (void *p)
{
void *q = __builtin_realloc (p, 32);
if (!q)
return 0;
memset (q, 0, 123);
return q;
}
int main (void)
{
f (__builtin_malloc (1));
}
In file included from /usr/include/string.h:635:0,
from y.c:1:
In function ‘memset’,
inlined from ‘f’ at y.c:10:3:
/usr/include/bits/string3.h:90:10: warning: ‘__builtin___memset_chk’ writing
123 bytes into a region of size 32 overflows the destination
[-Wstringop-overflow=]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
*** buffer overflow detected ***: ./a.out terminated
Contrast that to compiling and running with -fcheck-pointer-bounds:
$ gcc -O2 -Wall -D_FORTIFY_SOURCE=2 -fcheck-pointer-bounds -mmpx y.c && ./a.out
$
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628 Jakub Jelinek changed: What|Removed |Added Attachment #42430|0 |1 is obsolete|| --- Comment #14 from Jakub Jelinek --- Created attachment 42431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42431&action=edit gcc8-pr82628.patch Oh, when it is a constraint, it is called with VOIDmode, so the predicate has to check !TARGET_64BIT rather than mode == DImode. With this, the results are better, still have to look at x86_64 +FAIL: gcc.target/i386/pr67317-2.c scan-assembler-not addb +FAIL: gcc.target/i386/pr67317-4.c scan-assembler-not addb and i686: +FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) +FAIL: gcc.target/i386/pr67317-1.c scan-assembler-not addb +FAIL: gcc.target/i386/pr67317-3.c scan-assembler-not addb
[Bug tree-optimization/54027] [4.8 Regression] possible mis-optimization of signed left shift in c89 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54027 Tristan changed: What|Removed |Added CC||info at learnthreejs dot com --- Comment #7 from Tristan --- Still having an issue with the VRP shift. New here, where can I check out this patch? Might need a refresh! https://www.learnthreejs.com/beginners-tutorial/ Above is a resource I tested it on (my site). Still experiencing difficulties.
[Bug bootstrap/69725] LTO/PGO bootstrap fails with in-tree gmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #18 from Romain Geissler --- Hi, This looks like this is a know problem when trying to build GMP with LTO. Applying the attachment 9 from here: https://gmplib.org/list-archives/gmp-bugs/2015-June/003691.html will fix the issue. In acinclude.m4, gmp tries to detect the endianness of doubles, by analyzing a raw .o file with awk directly. Obviously an object file with slim LTO won't look like any normal object file with real assembly, so the test fails during the second stage ---> the configure script disable the double support. This seems it was already reported several times on the GMP mailing list, for example here as well: https://gmplib.org/list-archives/gmp-bugs/2013-August/003118.html but it seems to still not be fixed upstream. Cheers, Romain
[Bug fortran/82653] Parameters assigned with functions (instead of literals) cannot be used in other modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82653 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME from 4.8 up to trunk (8.0), with the following test module check_use_parameters use parameters ! if inside the used module parameters where defined with a function ! GNU-Fortran CANNOT compile this module real :: x ! this is just to write some other source code end module use check_use_parameters print *, ichar(NL), ichar(CR) end I get the expected answer 10 13 at run time. Note that gcc-5 is no longer supported.
