[Bug c++/55128] New: auto changes storage from .data to .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55128
Bug #: 55128
Summary: auto changes storage from .data to .rodata
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ricil...@gmail.com
This is probably related to #49673 (as in, it's probably a case which was not
fixed by the fix to that bug.) I noticed it while mucking about with
compile-time array generation.
In this little extract, a and b are identical, except that b is automatically
typed. I can't see any reason why the type wouldn't be exactly the same as a's,
and the DWARF debugging information shows them as having the same type.
However, a ends up in .rodata (expected) and b in .data (unexpected). I have a
stronger expectation which is that both would be in the same section, but I'm
pretty sure that .rodata is correct.
code:
#include
constexpr std::array makearray(double d) {
return std::array{{d}};
}
extern const std::array a = makearray(1);
extern const auto b = makearray(1);
General ASM with -O3 -S:
.file "auto1.cc"
.globl b
.data
.align 8
.type b, @object
.size b, 8
b:
.long 0
.long 1072693248
.globl a
.section.rodata
.align 8
.type a, @object
.size a, 8
a:
.long 0
.long 1072693248
.ident "GCC: (Ubuntu/Linaro 4.7.2-4precise1) 4.7.2"
.section.note.GNU-stack,"",@progbits
[Bug c++/56037] New: Spurious syntax error triggered before ambiguity resolution of type-id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56037 Bug #: 56037 Summary: Spurious syntax error triggered before ambiguity resolution of type-id Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ricil...@gmail.com A spurious syntax error is produced by the following: static const int zero = 0; std::cout << (std::pair(int(zero), int(zero))) << std::endl; In contrast, static const int zero = 0; static const int zero_alias = 0; std::cout << (std::pair(int(zero), int(zero_alias))) << std::endl; compiles correctly (assuming that there is an appropriate overload for operator<<). Section 8.2[2] states that The ambiguity arising from the similarity between a function-style cast and a type-id can occur in different contexts. The ambiguity appears as a choice between a function-style cast expression and a declaration of a type. The resolution is that any construct that could possibly be a type-id in its syntactic context shall be considered a type-id. In this case, 8.2[2] should not apply, since the syntactic context of the parenthesized expression does not permit the production: cast-expression :: ( type-id ) cast-expression However, in the first code excerpt, where the parenthesized expression would not be a valid type-id (because of the redefinition of the parameter name), the syntax error is apparently being triggered before the ambiguity resolution decides that type-id is not possible. In the second code excerpt, the parenthesize expression could contain a valid type-id, but ambiguity resolution rejects that possibility. --- Bug report generated as a result of http://stackoverflow.com/questions/14403946/adding-parenthesis-to-a-constructor-call-causes-duplicate-parameter-error-in-xlc/14404900#14404900
[Bug c++/56037] Spurious syntax error triggered before ambiguity resolution of type-id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56037 --- Comment #1 from ricilake at gmail dot com 2013-01-18 20:23:27 UTC --- Created attachment 29214 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29214 Test cases as described in bug
[Bug c++/79192] New: Angle bracket following typename is treated as template argument delimiter even if the name is not a template name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79192
Bug ID: 79192
Summary: Angle bracket following typename is treated as
template argument delimiter even if the name is not a
template name
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ricilake at gmail dot com
Target Milestone: ---
Sample code:
#include
struct v {};
int main() {
std::cout << __VERSION__ << '\n' << (new v < new v) << '\n';
}
(Or, more simply):
int main() { return new int < new int; }
Standard reference: ยง14.2 paragraph 3:
After name lookup finds that a name is a template-name or that an operator-
function-id or a literal-operator-id refers to a set of overloaded functions
any member of which is a function template, if this is followed by a <, the <
is always taken as the delimiter of a template-argument-list and never as the
less-than operator.
In this case, however, the name is *not* a template-name, so I believe that the
< should be the less-than operator. Clang also believes this.
Initially ventilated on StackOverflow
http://stackoverflow.com/q/41786026/1566221 where the consensus appears to be
that it's a bug.
As mentioned in the SO post, I also tried it with function names ("&f < &f"),
and in that case GCC does distinguish between template names and non-template
names, so the behaviour of "new v < new v" seems doubly inconsistent.
[Bug c++/79192] Angle bracket following typename is treated as template argument delimiter even if the name is not a template name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79192
--- Comment #1 from ricilake at gmail dot com ---
Thanks to Johannes Schaub-litb (via SO), the problem appears to be at around
line 16781 of cp/parser.c:
/* There is no valid C++ program where a non-template type is
followed by a "<". That usually indicates that the user thought
that the type was a template. */
cp_parser_check_for_invalid_template_id (parser, type, none_type,
token->location);
I believe this comment (and the subsequent call to
cp_parser_check_for_invalid_template_id) is incorrect; the above program is
valid.
As Johannes points out, there are other valid C++ programs in which a less than
sign can follow a non-template type, such as the following, which also triggers
the same error: (condensed from Johannes'
http://coliru.stacked-crooked.com/a/f35c1aa5b3f9832d)
struct A { operator A(); };
void operator<(A (A::*)(), A);
int main() { &A::operator A < A(); }
