[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Tim Turner changed:
What|Removed |Added
CC||timturnerc at yahoo dot com
--- Comment #18 from Tim Turner ---
--8<---
1 size_t fwrite(const void * __restrict ptr, size_t size,
http://www-look-4.com/category/travel/
2 size_t nmemb, register FILE * __restrict stream)
3 {
4 size_t retval; https://komiya-dental.com/category/technology/
5 __STDIO_AUTO_THREADLOCK_VAR;
6 http://www.iu-bloomington.com/category/technology/
7 > __STDIO_AUTO_THREADLOCK(stream);
8
9 retval = fwrite_unlocked(ptr, size, nmemb, stream);
10 https://waytowhatsnext.com/category/technology/
11 __STDIO_AUTO_THREADUNLOCK(stream);
12 http://www.wearelondonmade.com/category/travel/
13 return retval;
14 }
-->8---
http://www.jopspeech.com/category/travel/
Here, we are at line 7. Using the "next" command leads no where. However,
setting a breakpoint on line 9 and issuing "continue" works.
http://joerg.li/category/travel/
Looking at the assembly instructions reveals that we're dealing with the
critical section entry code http://the-hunters.org/technology/meta-symbol/ [1]
that should never be interrupted, in this
case by the debugger's implicit breakpoints:
http://connstr.net/category/travel/
--8<---
... http://embermanchester.uk/category/travel/
1 add_s r0,r13,0x38
2 mov_s r3,1
3 llock r2,[r0]<-.
4 brne.nt r2,0,14 --. | http://www.slipstone.co.uk/category/travel/
5 scond r3,[r0] | |
6 bne -10 --|--'
7 brne_s r2,0,84 <-' http://www.logoarts.co.uk/category/travel/
...
-->8---
http://www.acpirateradio.co.uk/category/travel/
Lines 3 until 5 (inclusive) are supposed to be executed atomically. Therefore,
http://fishingnewsletters.co.uk/crypto/kelleci-bay/
GDB should never (implicitly) insert a breakpoint on lines 4 and 5, else the
http://www.compilatori.com/category/travel/
program will try to acquire the lock again by jumping back to line 3 and
gets stuck in an infinite loop. https://www.webb-dev.co.uk/category/technology/
The solution is to make GDB aware of these patterns so it inserts breakpoints
after the sequence -- line 6 in this example. The solution is to make GDB aware
of these patterns so it inserts breakpoints
http://www.go-mk-websites.co.uk/services/kyoto/
after the sequence -- line 6 in this example.
The solution is to make GDB aware of these patterns so it inserts breakpoints
after the sequence -- line 6 in this example.
http://www.mconstantine.co.uk/services/new-zealand/
The solution is to make GDB aware of these patterns so it inserts breakpoints
after the sequence -- line 6 in this example.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Andrew Pinski changed: What|Removed |Added CC||lhyatt at gmail dot com --- Comment #17 from Andrew Pinski --- *** Bug 58740 has been marked as a duplicate of this bug. ***
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely changed: What|Removed |Added CC||cgd at google dot com --- Comment #16 from Jonathan Wakely --- *** Bug 48078 has been marked as a duplicate of this bug. ***
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 --- Comment #15 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:29853c653245c37ed31b6abcc9799b534372e938 commit r11-6800-g29853c653245c37ed31b6abcc9799b534372e938 Author: Patrick Palka Date: Tue Jan 19 16:20:00 2021 -0500 c++: Always check access during late-parsing of members [PR58993] This patch removes a vestigial use of dk_no_check from cp_parser_late_parsing_for_member, which ideally should have been removed as part of the PR41437 patch that improved access checking inside templates. This allows us to correctly reject f1 and f2 in the testcase access34.C below (whereas before we'd only reject f3). Additional testing revealed a new access issue when late-parsing a hidden friend within a class template. In the testcase friend68.C below, we're tripping over the checking assert from friend_accessible_p(f, S::j, S, S) during lookup of j in x.j (for which type_dependent_object_expression_p returns false, which is why we're doing the lookup at parse time). The reason for the assert failure is that DECL_FRIENDLIST(S) contains f but DECL_BEFRIENDING_CLASSES(f) is empty, and so friend_accessible_p (which looks at DECL_BEFRIENDING_CLASSES) wants to return false, but is_friend (which looks at DECL_FRIENDLIST) returns true. For sake of symmetry one would expect that DECL_BEFRIENDING_CLASSES(f) contains S, but add_friend avoids updating DECL_BEFRIENDING_CLASSES when the class type (S in this case) is dependent, for some reason. This patch works around this issue by making friend_accessible_p consider the DECL_FRIEND_CONTEXT of the access scope. Thus we sidestep the DECL_BEFRIENDING_CLASSES / DECL_FRIENDLIST asymmetry issue while correctly validating the x.j access at parse time. A earlier version of this patch checked friend_accessible_p instead of protected_accessible_p in the DECL_FRIEND_CONTEXT hunk below, but this had the side effect of making us accept the ill-formed testcase friend69.C below (ill-formed because the hidden friend g is not actually a member of A, so g doesn't have access to B's members despite B befriending A). gcc/cp/ChangeLog: PR c++/41437 PR c++/58993 * search.c (friend_accessible_p): If scope is a hidden friend defined inside a dependent class, consider access from the class. * parser.c (cp_parser_late_parsing_for_member): Don't push a dk_no_check access state. gcc/testsuite/ChangeLog: PR c++/41437 PR c++/58993 * g++.dg/opt/pr87974.C: Adjust. * g++.dg/template/access34.C: New test. * g++.dg/template/friend68.C: New test. * g++.dg/template/friend69.C: New test.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 --- Comment #14 from Jonathan Wakely --- *** Bug 94644 has been marked as a duplicate of this bug. ***
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Patrick Palka --- This should be fixed for GCC 11 now.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:668ef28fbb44c1e51d9c5a35b421903c98d87b03 commit r11-1351-g668ef28fbb44c1e51d9c5a35b421903c98d87b03 Author: Patrick Palka Date: Tue Jun 16 08:21:36 2020 -0400 c++: Clean up previous change [PR41437] The previous patch mostly avoided making any changes that had no functional impact, such as adjusting now-outdated comments and performing renamings. Such changes have been consolidated to this followup patch for easier review. The main change here is that we now reuse struct deferred_access_check as the element type of the vector TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (now renamed to TI_DEFERRED_ACCESS_CHECKS, since it may contain any kind of access check). gcc/cp/ChangeLog: PR c++/41437 PR c++/47346 * cp-tree.h (qualified_typedef_usage_s): Delete. (qualified_typedef_usage_t): Delete. (deferred_access_check): Move up in file. (tree_template_info::typedefs_needing_access_checking): Delete. (tree_template_info::deferred_access_checks): New field. (TI_TYPEDEFS_NEEDING_ACCESS_CHECKING): Rename to ... (TI_DEFERRED_ACCESS_CHECKS): ... this, and adjust accordingly. * pt.c (perform_typedefs_access_check): Rename to ... (perform_instantiation_time_access_checks): ... this, and adjust accordingly. Remove unnecessary tree tests. (instantiate_class_template_1): Adjust accordingly. (instantiate_decl): Likewise. * semantics.c (enforce_access): Likewise.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 --- Comment #11 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:92bed036098928cd4659c8990e14cf7ad040e0c2 commit r11-1350-g92bed036098928cd4659c8990e14cf7ad040e0c2 Author: Patrick Palka Date: Tue Jun 16 08:21:33 2020 -0400 c++: Improve access checking inside templates [PR41437] This patch generalizes our existing functionality for deferring access checking of typedefs when parsing a function or class template to now defer all kinds of access checks until template instantiation time, including member function and member object accesses. Since all access checks eventually go through enforce_access, the main component of this patch is new handling inside enforce_access to defer the current access check if we're inside a template. The bulk of the rest of the patch consists of removing now-unneeded code pertaining to suppressing access checks inside templates or pertaining to typedef-specific access handling. Renamings and other changes with no functional impact have been split off into the followup patch. gcc/cp/ChangeLog: PR c++/41437 PR c++/47346 * call.c (enforce_access): Move to semantics.c. * cp-tree.h (enforce_access): Delete. (get_types_needing_access_check): Delete. (add_typedef_to_current_template_for_access_check): Delete. * decl.c (make_typename_type): Adjust accordingly. Use check_accessibility_of_qualified_id instead of directly using perform_or_defer_access_check. * parser.c (cp_parser_template_declaration_after_parameters): Don't push a dk_no_check access state when parsing a template. * pt.c (get_types_needing_access_check): Delete. (append_type_to_template_for_access_check_1): Delete. (perform_typedefs_access_check): Adjust. If type_decl is a FIELD_DECL, also check its DECL_CONTEXT for dependence. Use tsubst_copy instead of tsubst to substitute into type_decl so that we substitute into the DECL_CONTEXT of a FIELD_DECL. (append_type_to_template_for_access_check): Delete. * search.c (accessible_p): Remove the processing_template_decl early exit. * semantics.c (enforce_access): Moved from call.c. If we're parsing a template and the access check failed, add the check to TI_TYPEDEFS_NEEDING_ACCESS_CHECKING. (perform_or_defer_access_check): Adjust comment. (add_typedef_to_current_template_for_access_check): Delete. (check_accessibility_of_qualified_id): Adjust accordingly. Exit early if the scope is dependent. gcc/testsuite/ChangeLog: PR c++/41437 PR c++/47346 * g++.dg/cpp2a/concepts-using2.C: Adjust. * g++.dg/lto/20081219_1.C: Adjust. * g++.dg/lto/20091002-1_0.C: Adjust. * g++.dg/lto/pr65475c_0.C: Adjust. * g++.dg/opt/dump1.C: Adjust. * g++.dg/other/pr53574.C: Adjust. * g++.dg/template/access30.C: New test. * g++.dg/template/access31.C: New test. * g++.dg/wrappers/wrapper-around-type-pack-expansion.C: Adjust. libstdc++-v3/ChangeLog: PR libstdc++/94003 * testsuite/20_util/is_constructible/94003.cc: New test.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Last reconfirmed|2010-09-20 15:53:01 |2020-3-12 --- Comment #10 from Jonathan Wakely --- As Bug 94003 shows, this is also a wrong-code bug.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #9 from Martin Sebor --- I'm not sure the original test case and the one in comment #8 are the same bug. The former doesn't seem to have ever been rejected, while the latter used to until r231354 when it became accepted. r231354 | jason | 2015-12-06 23:35:14 -0500 (Sun, 06 Dec 2015) | 4 lines Fix parse/no-type-defn1.C with -std=c++1z. * parser.c (struct tentative_firewall): New. (cp_parser_template_id, cp_parser_decltype_expr): Use it. I'm also not sure bug 45775 referenced in comment #3 is a duplicate of this one. I haven't been able to find a GCC revision that accepts the test case there. Finally, bug 40843 was fixed by r190830 which was committed to resolve bug 50545 and bug 51222, so it also doesn't seem to be a duplicate of this one.
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Vlad Gheorghiu changed:
What|Removed |Added
CC||vgheorgh at gmail dot com
--- Comment #8 from Vlad Gheorghiu ---
The bug exists in gcc 6.1 as well:
class X
{
template
class A{};
};
int main()
{
X::A a; // compiles just fine
}
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment #7 from Barry Revzin ---
This bug still exists in 5.3.0. For instance:
class X {
int mem;
};
template
auto foo(T) {
return ::mem;
}
int main() {
foo(0);
}
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 64216 has been marked as a duplicate of this bug. ***
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Shane w.shane.grant at gmail dot com changed:
What|Removed |Added
CC||w.shane.grant at gmail dot com
--- Comment #5 from Shane w.shane.grant at gmail dot com ---
This bug still exists for g++ 4.8.1. Crops up regardless of where the template
function is that tries to access the protected/private member:
class Base { void snarf() {} };
struct Derived : public Base
{
template class T
void bar( T t )
{
snarf(); // this is incorrectly marked ok
}
};
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||sylvestre at debian dot org --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 16:50:25 UTC --- *** Bug 52373 has been marked as a duplicate of this bug. ***
[Bug c++/41437] No access control for classes in template functions
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.6 4.4.3 4.5.2 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-09-20 15:53:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug c++/41437] No access control for classes in template functions
--- Comment #2 from redi at gcc dot gnu dot org 2010-09-20 15:54 --- *** Bug 40843 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||sipych at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug c++/41437] No access control for classes in template functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-25 04:44 --- I think this is a duplicate of bug 40843. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
