[Bug c++/97624] ICE: in dependent_type_p, at cp/pt.c:26515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97624 --- Comment #1 from Eugene --- Created attachment 49464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49464&action=edit Compiler output
[Bug c++/97624] New: ICE: in dependent_type_p, at cp/pt.c:26515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97624
Bug ID: 97624
Summary: ICE: in dependent_type_p, at cp/pt.c:26515
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene at hutorny dot in.ua
Target Milestone: ---
Created attachment 49463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49463&action=edit
Source file with minimal reproduceable code
C++ compiler fails on the following example:
template
struct Tag {
static constexpr auto tag = TAG;
T value;
};
template
void bar(Tagged&& ... tagged) {
const char* v[sizeof...(Tagged)] = {
[Tagged::tag] = tagged.value ...
};
}
using O = Tag<0>;
void foo() {
bar(O{"ICE"});
}
[Bug c++/88690] [7/8/9 Regression] c++17 internal compiler error: in output_constructor_regular_field, at varasm.c:5031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #10 from Eugene ---
(In reply to Jakub Jelinek from comment #8)
> Further reduced (-std=c++17):
> struct A { int a = 1; };
> struct B { int b = 0; };
> struct C { C () = delete; };
> struct D : public B, public C {};
> struct E : A { D f; } g{};
I think this particular example should be rejected by the compiler because
there is no means for constructing C;
The one below should compile indeed:
struct A { int a = 1; };
struct B { int b = 0; };
struct C { C() = default; C (const C&) = delete; };
struct D : public B, public C {};
struct E : A { D f; } g{};
[Bug c++/88690] internal compiler error: in output_constructor_regular_field, at varasm.c:5031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690 --- Comment #5 from Eugene --- Meanwhile I have found exact line that causing this issue: services.ii@35563: characteristic_inst(const characteristic_inst&) = delete; When commented out, compilation pass.
[Bug c++/88690] internal compiler error: in output_constructor_regular_field, at varasm.c:5031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690 --- Comment #2 from Eugene --- Created attachment 45339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45339&action=edit Output of arm-none-eabi-gcc.exe -v
[Bug c++/88690] internal compiler error: in output_constructor_regular_field, at varasm.c:5031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690 --- Comment #1 from Eugene --- Created attachment 45338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45338&action=edit Zipped prepocessed file causing internal error
[Bug c++/88690] New: internal compiler error: in output_constructor_regular_field, at varasm.c:5031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690 Bug ID: 88690 Summary: internal compiler error: in output_constructor_regular_field, at varasm.c:5031 Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene at hutorny dot in.ua Target Milestone: --- GCC version: gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update) OS Name: Microsoft Windows 7 Ultimate OS Version:6.1.7601 Service Pack 1 Build 7601 Command line: arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O3 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -Wshadow -Wlogical-op -Wfloat-equal -DDEBUG -I"E:\Projects\nrf52832-mdk\config" -I"E:\Projects\ags\src" -fabi-version=9 -fno-exceptions -fno-rtti -fno-use-cxa-atexit -fno-threadsafe-statics -std=c++17 -O5 -Wabi -Wctor-dtor-privacy -Wnoexcept -Weffc++ @../gcc.opt --save-temps -MMD -MP -MF"src/services.d" -MT"src/services.o" -c -o "src/services.o" "../src/services.cpp"
[Bug c++/80994] New: Misleading error message for missing template keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80994
Bug ID: 80994
Summary: Misleading error message for missing template keyword
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene at hutorny dot in.ua
Target Milestone: ---
The example below fails to compile with error
error: invalid operands of types '' and
'int' to binary 'operator<'
which seems to be misleading. A message like 'template keyword needed' would be
much more informative.
template
struct zoo {
template
int bar(char in);
};
template
class foo {
public:
foo();
inline int bar(char chr) {
return fos.bar<0>(chr); // must be: return fos.template
bar<0>(chr);
}
zoo fos;
};
int main() {
foo tar;
return tar.bar(' ');
}
[Bug c++/67245] New: static_assert on inline function gives an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67245
Bug ID: 67245
Summary: static_assert on inline function gives an error
Product: gcc
Version: 4.9.2
URL: http://stackoverflow.com/questions/32045025/static-ass
ert-on-inline-function-gives-error
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene at hutorny dot in.ua
Target Milestone: ---
Created attachment 36193
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36193&action=edit
code snippet
Consider the following example
typedef void (*foo)();
template
struct bar {
static_assert(f!=nullptr,"f == null!");
};
void baz() {}
inline void bax() { }
bar ok;
bar bad; // error: non-constant condition for static assertion
When compiled with (g++ -std=c++14) compilation fails with
error non-constant condition for static assertion,
blaming bax to be non-constant.
This example compiles well in clang++ 3.7 and VC++ 14.0
[Bug c++/64961] nested template implementation crossing namespace fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64961 --- Comment #3 from Eugene --- In the example method bar::Bar::Foo<1>::bar() is on the same access path and its specialization gives no error. Is there an explanation for this difference?
[Bug c++/64961] New: nested template implementation crossing namespace fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64961 Bug ID: 64961 Summary: nested template implementation crossing namespace fails with access error Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene at hutorny dot in.ua Created attachment 34686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34686&action=edit code sample illustrating the issue Consider a case: a template with protected nested structure (Foo<>::Fo) is defined in one namespace (foo), and instantiated in another namespace (bar) via inheritance. Specialization of nested templates methods fails with access error. Compare to specialization of a outer template's method placed in exactly the same scope and compiled with success.
[Bug c++/64261] false branch of conditional operator ?: evaluated in a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64261 --- Comment #2 from Eugene --- -Wall -pedantic -Os -g -std=c++0x
[Bug c++/64261] New: false branch of conditional operator ?: evaluated in a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64261 Bug ID: 64261 Summary: false branch of conditional operator ?: evaluated in a template constexpr Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene at hutorny dot in.ua Created attachment 34245 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34245&action=edit Code sample illustrating the problem When a conditional (ternary) operator is used in a constexpr function in a template, compiler evaluates both true and false branches, causing undesired side-effects, such as division by zero. Please refer to attached example
[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64052 --- Comment #4 from Eugene --- I am not arguing for the sample code to be compilable and functional. My expectation is a consistent compilation result regardless of the optimisation settings. If it fails with 'O0' should fail with 'Os' too.
[Bug c++/64073] Explicit duplicate template instantiation not reported as error when using 'using'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64073 --- Comment #1 from Eugene --- Created attachment 34117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34117&action=edit Code sample illustrating the problem
[Bug c++/64073] New: Explicit duplicate template instantiation not reported as error when using 'using'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64073 Bug ID: 64073 Summary: Explicit duplicate template instantiation not reported as error when using 'using' Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene at hutorny dot in.ua When derived template classes introduces a base member with using, such methods can be explicitly instantiated more than once with the same set of parameters. Please refer to attached sample
[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64052 Eugene changed: What|Removed |Added Version|4.7.2 |4.8.1 --- Comment #2 from Eugene --- As per https://packages.debian.org/unstable/devel/ avr-gcc 4.8.1 is the most recent available for debian This issue is reproducible on 4.8.1
[Bug c++/64053] asm labels to accept extra parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64053 --- Comment #1 from Eugene --- Created attachment 34098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34098&action=edit code sample for illustartion
[Bug c++/64053] New: asm labels to accept extra parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64053
Bug ID: 64053
Summary: asm labels to accept extra parameters
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene at hutorny dot in.ua
Host: Linux 2.6.32-5-686
Target: avr
Current syntax of asm labels accepts only a string literal
int foo asm ("myfoo");
This limits label generation to pre-processing time.
If asm label would accept constant expressions as asm statement does,
it would open possibilities for generating function labels with c++ templates
as attached example illustrates.
[Bug c++/64052] New: compilation error "local frame unavailable" appears for some optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64052
Bug ID: 64052
Summary: compilation error "local frame unavailable" appears
for some optimization levels
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene at hutorny dot in.ua
Host: Linux 2.6.32-5-686
Target: avr
Created attachment 34097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34097&action=edit
code sample illustrating the issue
Compilation success of the attached example depend on the optimization
settings: with optimize("O0") compilation fails with error _local frame
unavailable (naked function?)_ while with optimize("Os") it succeeds.
Expected behavior - optimization option has no effect on compilation success
avr-g++ (GCC) 4.7.2
Command line:
avr-g++ -Wall -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields
-fno-exceptions -mmcu=atmega16 -DF_CPU=100UL -MMD -MP
-MF"local_frame_test.d" -MT"local_frame_test.d" -c -o "local_frame_test.o"
"local_frame_test.cpp"
[Bug c/51568] Enum value is not extracted properly via a union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51568
--- Comment #4 from Eugene 2011-12-16 10:48:59
UTC ---
Enum can be packed to one byte with __attribute__((__packed__)) :
enum en { v0, v1, v2, v3, v4, v5, v6, v7 } __attribute__((__packed__));
[Bug c/51568] Enum value is not extracted properly via a union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51568 --- Comment #3 from Eugene 2011-12-15 19:44:34 UTC --- >On linux sizeof (struct rec) is 7, so how do you expect an unsigned (size = 4) to hold the entire value? Agree, that was my mistake. I misexpected the enum to fit one byte.
[Bug c/51568] New: Enum value is not extracted properly via a union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51568
Bug #: 51568
Summary: Enum value is not extracted properly via a union
Classification: Unclassified
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eug...@hutorny.in.ua
Target: ARM
Created attachment 26103
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26103
Test example
A wrong value is received when a value is assigned via union and read its
member.
Consider the following data structures:
enum en { v0, v1, v2, v3, v4, v5, v6, v7 };
struct rec {
unsigned short w;
unsigned char c;
enum en e;
} __attribute__((__packed__));
union un {
struct rec r;
unsigned v;
} __attribute__((__packed__));
void pass(unsigned v) {
union un u;
u.v = v;
printf("r.w=%X r.c=%d r.e=%d\n", u.r.w, u.r.c, u.r.e );
}
int main(int argc, char** argv) {
union un u;
u.r.c = '8';
u.r.e = v2;
u.r.w = 0xC5FF;
printf("r.w=%X r.c=%d r.e=%d\n", u.r.w, u.r.c, u.r.e );
pass(u.v);
return 0;
}
Sample above compiled with gcc (Debian 4.3.2-1.1) 4.3.2 prints the following:
r.w=C5FF r.c=56 r.e=2
r.w=C5FF r.c=56 r.e=34050
When compiled with arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 prints:
r.w=C5FF r.c=56 r.e=2
r.w=C5FF r.c=56 r.e=50434
