Re: Segmentation fault since 7fc49a5777943aab11e227136d00a836f28f12b2

[Marek Polacek via Gcc-bugs]

On Tue, Sep 15, 2020 at 10:41:31PM +0100, Nuno Gonçalves via Gcc-bugs wrote:
> Hi Jason et al,
> 
> After a bisect I found that the commit
> 7fc49a5777943aab11e227136d00a836f28f12b2 causes a segmentation fault
> during my compilation:

This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805

> sqlpp11/include/sqlpp11/where.h: In substitution of ‘template WhereRequired> template template
> using _new_statement_t = sqlpp::new_statement_t sqlpp::no_where_t, T> [with Check =
> sqlpp::consistent_t; T = sqlpp::where_t;
> Policies = Policies; bool WhereRequired = WhereRequired]’:
> sqlpp11/include/sqlpp11/where.h:320:99:   required from here
> sqlpp11/include/sqlpp11/where.h:320:99: internal compiler error:
> Segmentation fault
>   320 |   auto unconditionally() const ->
> _new_statement_t>
>   |
>^~
> 0xc9978f crash_signal
> ../../gcc/toplev.c:328
> 0x692b05 pop_nested_class()
> ../../gcc/cp/class.c:8184
> 0x7a3157 instantiate_template_1
> ../../gcc/cp/pt.c:20853
> 0x79e0b4 instantiate_template(tree_node*, tree_node*, int)
> ../../gcc/cp/pt.c:20908
> 0x79e0b4 instantiate_alias_template
> ../../gcc/cp/pt.c:20946
> 0x79e0b4 tsubst(tree_node*, tree_node*, int, tree_node*)
> ../../gcc/cp/pt.c:15147
> 0x7a451f lookup_template_class_1
> ../../gcc/cp/pt.c:9853
> 0x7a4bfc lookup_template_class(tree_node*, tree_node*, tree_node*,
> tree_node*, int, int)
> ../../gcc/cp/pt.c:10119
> 0x7c154d finish_template_type(tree_node*, tree_node*, int)
> ../../gcc/cp/semantics.c:3408
> 0x768b7d cp_parser_template_id
> ../../gcc/cp/parser.c:16739
> 0x768dec cp_parser_class_name
> ../../gcc/cp/parser.c:23713
> 0x765b21 cp_parser_qualifying_entity
> ../../gcc/cp/parser.c:6776
> 0x765b21 cp_parser_nested_name_specifier_opt
> ../../gcc/cp/parser.c:6458
> 0x76d126 cp_parser_simple_type_specifier
> ../../gcc/cp/parser.c:18134
> 0x753e0d cp_parser_type_specifier
> ../../gcc/cp/parser.c:17792
> 0x7673c9 cp_parser_type_specifier_seq
> ../../gcc/cp/parser.c:22402
> 0x761954 cp_parser_type_id_1
> ../../gcc/cp/parser.c:22219
> 0x7606ff cp_parser_trailing_type_id
> ../../gcc/cp/parser.c:22325
> 0x7606ff cp_parser_late_return_type_opt
> ../../gcc/cp/parser.c:22129
> 0x7606ff cp_parser_direct_declarator
> ../../gcc/cp/parser.c:21258
> 
> I hope this is enough since I am not experienced in GCC development.
> 
> Thanks,
> Nuno
> 

Marek

Re: Possible gcc bug

[Marek Polacek via Gcc-bugs]

On Wed, Jul 06, 2022 at 10:15:51AM +1000, Norman wrote:
> Hi all,
> 
> Consider this bit of code:
> 
> unsigned int d=1,e=2,f;
> 
>     if((d-e) < 0)
>     {
>     f=d-e;
>     printf("f=%i",f);
>     }
> 
> gcc  -Wall -DLinux -D_FILE_OFFSET_BITS=64 -c scroll.c
> 
> gcc compiles this without a whimper.
> 
> However the expression (d-e) < 0 always evaluates to false (0). gcc type
> casts (d-e) as unsigned.

You need to include -Wextra to get the warning.

Marek

Re: Bug in ignoring function call

[Marek Polacek via Gcc-bugs]

On Wed, Nov 20, 2024 at 09:43:46PM +0530, AKASH MISHRA via Gcc-bugs wrote:
> Hi Team,
> there is a bug , compiler not reporting error or warning while calling a
> function with parentheses.
> 
> For ex:
> 
> void func()
> {
> printf("Hi i am in func");
> }
> 
> main()
> {
> // call the func here without parentheses
> 
> func; // here even though we miss parentheses, no error reported , neither
> function got called
> }
> 
> Regards,
> Akash Mishra
> 

Not a bug; you need to use -Wall to get "warning: statement with no effect".

Also please don't email gcc-bugs directly, see .

Marek