Re: ’ ] ' is displayed.
Thanks for the tip! 2023年12月24日(日) 23:35 Jonathan Wakely : > This mailing list is for automated emails from our bug database, not > for reporting bugs directly. > > See https://gcc.gnu.org/bugs/ for how to report bugs, thanks. > > >
Re: ’ ] ' is displayed.
This mailing list is for automated emails from our bug database, not for reporting bugs directly. See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
' ] ' is displayed.
/* sprintf()関数 */
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
/* if (output_len >= 80)
{
fprintf(stderr, "Output string overflowed by %d characters.\n"
"The variables x, y, z and a may have been corrupted:\n"
"x now contains %f, y %f, z %f, and a %f.\n",
output_len - 79, x, y, z, a);
} */
}
' ] ' is displayed.
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
’ ] ' is displayed.
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
[Bug debug/105389] New: variable displayed as available at -O1 and -O3 but as optimized out at -Og and with an incorrect value at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105389
Bug ID: 105389
Summary: variable displayed as available at -O1 and -O3 but as
optimized out at -Og and with an incorrect value at
-O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, variable l_43, defined within the scope of
function c, has wrong debug information definition that lead to optimized out
or incorrect value being shown at -Og and -O2 while it has always the correct
value with optimization levels -O1 and -O3.
At -Og the variable is marked as optimized out at line 6 when its value should
be 5 and it becomes available with its correct value only starting from line 9,
where it is assigned to 0 via pointer arithmetics. At -O2 the variable has a
wrong value at line 10 (the only one actually stepped), it should be 0 but the
value available during debugging is 5.
We provide a detailed analysis on x64 with a quick assessment of older gcc
versions.
$ cat a.c
int a ;
char b ;
void c() {
int l_43 = 5;
int *d = _43;
e: b++;
for (;
a != -8;
--a) *d = 0;
if (b) goto e;
}
int main() {
c();
}
GCC and GDB version (GCC commit id: 500d3f0a302):
gcc (GCC) 12.0.0 20211227 (experimental)
GNU gdb (GDB) 11.2
GDB trace at -Og:
$ gcc -Og -g a.c -o opt-g
$ gdb -q opt-g
Reading symbols from opt-g...
(gdb) b c
Breakpoint 1 at 0x400486: file a.c, line 3.
(gdb) r
Starting program: /tmp/opt-g
Breakpoint 1, c () at a.c:3
3 void c() {
(gdb) info loc
l_43 =
d =
(gdb) n
6 e: b++;
(gdb) info loc
l_43 =
d =
(gdb) n
7 for (;
(gdb) info loc
l_43 =
d =
(gdb) n
8 a != -8;
(gdb) info loc
l_43 =
d =
(gdb) n
9 --a) *d = 0;
(gdb) info loc
l_43 = 0
d =
(gdb) n
8 a != -8;
(gdb) info loc
l_43 =
d =
(gdb) n
9 --a) *d = 0;
(gdb) info loc
l_43 = 0
d =
GDB trace at -O2:
$ gcc -O2 -g a.c -o opt-2
$ gdb -q opt-2
Reading symbols from opt-2...
(gdb) b c
Breakpoint 1 at 0x4004a0: file a.c, line 10.
(gdb) r
Starting program: /tmp/opt-2
Breakpoint 1, c () at a.c:10
10 if (b) goto e;
(gdb) info loc
l_43 = 5
d =
e =
ASM at -Og:
00400486 :
400486: eb 18 jmp4004a0
400488: 83 e8 01sub$0x1,%eax
40048b: 89 05 9f 0b 20 00 mov%eax,0x200b9f(%rip)#
601030
400491: 8b 05 99 0b 20 00 mov0x200b99(%rip),%eax#
601030
400497: 83 f8 f8cmp$0xfff8,%eax
40049a: 75 ec jne400488
40049c: 84 d2 test %dl,%dl
40049e: 74 12 je 4004b2
4004a0: 0f b6 05 85 0b 20 00movzbl 0x200b85(%rip),%eax#
60102c
4004a7: 8d 50 01lea0x1(%rax),%edx
4004aa: 88 15 7c 0b 20 00 mov%dl,0x200b7c(%rip)#
60102c
4004b0: eb df jmp400491
4004b2: c3 retq
DWARF at -Og:
0x00ae: DW_TAG_variable
DW_AT_name("l_43")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x08)
DW_AT_type(0x0041 "int")
DW_AT_location(0x000e:
[0x00400488, 0x00400491): DW_OP_lit0,
DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
ASM and DWARF analysis at -Og:
>From DWARF information we can see how there is only a location range defined
for variable l_43 and it has value 0 associated with it.
The range includes the instructions associated with line 9 making the variable
available at line 9, but there is no location defined for the instructions
associated with line 6, thus making the variable marked as optimized out when
its value is 5.
For instance, at -O1 this information is correctly computed:
ASM at -O1:
00400486 :
400486: 0f b6 15 9f 0b 20 00movzbl 0x200b9f(%rip),%edx#
60102c
40048d: 8b 05 9d 0b 20 00 mov0x200b9d(%rip),%eax#
601030
400493: b9 00 00 00 00 mov$0x0,%ecx
400498: be 01 00 00 00 mov$0x1,%esi
40049d: 83 c2 01add$0x1,%edx
4004a0: 83 f8 f8cmp$0xfff8,%eax
4004a3: 74 0a je 4004af
4004a5: 83 e8 01sub$0x1,%eax
4004a8: 83 f8 f8cmp$0xfff8,%eax
4004ab: 75 f8 jne4004a5
4004ad: 89 f1
[Bug c++/54948] template unnecessarily displayed as "A< template-parameter-1-1 >" not "A"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104094 --- Comment #5 from Jonathan Wakely --- This continues to be annoying. Libstdc++ has loads of forward declarations of templates, e.g. in : // Forward declarations template struct is_reference; template struct is_function; template struct is_void; template struct remove_cv; template struct is_const; Which means we then get diagnostics containing: std::is_same<_U1, typename std::remove_cv< >::type&> I agree with Manu that this could just show "typename" here. We don't refer to the template-parameter-1-1 type again in the diagnostic, so why do we care about uniquely identifying it as 1-1? But why is it even using the name from the remove_cv declaration? That should not be appearing in the *use* of remove_cv here. I've filed that as PR 104094.
[Bug c++/98164] [C++20] The type displayed in compiler output cannot be reused as displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98164
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||mpolacek at gcc dot gnu.org
Last reconfirmed||2020-12-07
--- Comment #1 from Marek Polacek ---
Confirmed. Doesn't need the include:
struct s {};
template struct r {};
#ifdef FIX
constexpr auto P = r {};
#endif
constexpr auto S = s {};
constexpr auto R = r {};
void g () { using t = decltype (R); };
[Bug c++/98164] New: [C++20] The type displayed in compiler output cannot be reused as displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98164
Bug ID: 98164
Summary: [C++20] The type displayed in compiler output cannot
be reused as displayed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
When displaying the type of a class-type-nontype-template-argument (new with
C++20), these are shown either with parentheses '()' or with curly-brackets
'{}'.
Reusing the type as output (copy-pasting it or via automated parsing of
compiler messages), is only possible if curly-brackets '{}' are used, because
compiler considers '()' in templated types as function calls.
It would seem that the '()' and '{}' are used interchangeably, depending on
some circumstances in the source code.
The test (compile as g++ -std=c++20 -Wall):
#include
struct s {};
template struct r {};
#ifdef FIX
constexpr auto P = r {};
#endif
constexpr auto S = s {};
constexpr auto R = r {};
void g () { using t = decltype (R); };
static_assert (std::is_same_v , decltype (R)>);
// static_assert (std::is_same_v , decltype (R)>);
Here:
1. If FIX is not defined, the type of 't' is displayed using '()':
bug-11.cpp: In function ‘void g()’:
bug-11.cpp:12:20: warning: typedef ‘using t = const struct r’ locally
defined but not used [-Wunused-local-typedefs]
^^
||
12 | void g () { using t = decltype (R); };
|^
2. With -DFIX, the type is displayed using '{}' ("struct r")
bug-11.cpp: In function ‘void g()’:
bug-11.cpp:12:20: warning: typedef ‘using t = const struct r’ locally
defined but not used [-Wunused-local-typedefs]
^^
||
12 | void g () { using t = decltype (R); };
3. The last line can be un-commented to see how the compiler rejects 'const
struct r '.
Since this choice between '()' and '{}' seem (arbitrarily?) dependent on some
external factors (which?), would it be possible to make it always use '{}'?
This would simplify creation of parsing scripts and debugging of constexpr-only
code heavily using dependent types.
[Bug c/90477] New: negative line numbers should not be displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90477 Bug ID: 90477 Summary: negative line numbers should not be displayed Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Using godbolt trunk gcc shows negative numbers, I don't know if it is any better to put a ceiling, at least if the line number was stuck at 2147483646 that might be better than wrapping to negative. Although making line numbers 64bit might be a nicer solution. #pragma message "A1" #line 2147483647 #pragma message "A1" #1 with x86-64 gcc (trunk) :1:17: note: #pragma message: A1 1 | #pragma message "A1" | ^~~~ :-2147483648:17: note: #pragma message: A1 Compiler returned: 0
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #5 from Jonny Grant --- Created attachment 45247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45247=edit C example of this UTF8 not displaying
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #4 from Jonny Grant --- Clang has an appropriate message and displays the UTF8 okay. GCC just needs to catch up with clang on this one... #1 with x86-64 clang (trunk) :8:7: error: non-ASCII characters are not allowed outside of literals and identifiers st£ing buf; ^ :8:5: error: unknown type name 'st' st£ing buf; ^ :8:12: error: expected ';' at end of declaration st£ing buf; ^ ; :10:5: error: use of undeclared identifier 'buf' buf = "£" ^ 4 errors generated. Compiler returned: 1
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #3 from Jonny Grant --- ICC displays the UTF8 ok: #1 with x86-64 icc 19.0.1 (8): error: unrecognized token st£ing buf; ^ (8): error: identifier "st" is undefined st£ing buf; ^ (8): error: expected a ";" st£ing buf; ^ (10): error: identifier "buf" is undefined buf = "£" ^ (11): error: expected a ";" } ^ compilation aborted for (code 2) Compiler returned: 2
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #2 from Jonny Grant --- (In reply to Jonathan Wakely from comment #1) > (In reply to Jonny Grant from comment #0) > > Hello > > > > This is an typo in the word "string", just reporting as perhaps it could > > show £ correctly, as it does on line 10 error. > > But then you couldn't have two separate caret locations pointing to the two > invalid bytes, because it would only occupy a single column. You also assume > the terminal is capable of showing UTF-8 characters. Ok. I would suggest worth displaying the "st£ing" and say ‘st£ing’ was not a valid identifier (Latin letter, underscore, or non-digit character) as per C/C++ specs? Example expected output: $ g++ -Wall -o string string.cpp string.cpp: In function ‘int main()’: string.cpp:8:5: error: ‘st£ing’ is not a valid identifier as contains non-latin characters st£ing buf; ^~ string.cpp:8:5: note: suggested alternative: ‘string’ st£ing buf; ^~ string string.cpp:10:5: error: ‘buf’ was not declared in this scope buf = "£" ^~~
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #1 from Jonathan Wakely --- (In reply to Jonny Grant from comment #0) > Hello > > This is an typo in the word "string", just reporting as perhaps it could > show £ correctly, as it does on line 10 error. But then you couldn't have two separate caret locations pointing to the two invalid bytes, because it would only occupy a single column. You also assume the terminal is capable of showing UTF-8 characters. > Perhaps could also show the > stray bytes in hex as well? ie "0xF3C2" I don't see why that would that be an improvement.
[Bug c++/88507] New: utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
Bug ID: 88507
Summary: utf8 not displayed
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Hello
This is an typo in the word "string", just reporting as perhaps it could show £
correctly, as it does on line 10 error. Perhaps could also show the stray bytes
in hex as well? ie "0xF3C2"
$ g++ -Wall -o string string.cpp
string.cpp:8:7: error: stray ‘\302’ in program
st��ing buf;
^
string.cpp:8:8: error: stray ‘\243’ in program
st��ing buf;
^
string.cpp: In function ‘int main()’:
string.cpp:8:5: error: ‘st’ was not declared in this scope
st£ing buf;
^~
string.cpp:10:5: error: ‘buf2’ was not declared in this scope
buf2 = "£"
^~~~
// g++ -Wall -o string string.cpp
#include
using namespace std;
int main()
{
st£ing buf;
buf = "£"
}
[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- If you want precise call trace in the diagnostics, you need to use -g.
[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783 --- Comment #3 from Daniel Santos daniel.santos at pobox dot com --- (In reply to Jakub Jelinek from comment #2) If you want precise call trace in the diagnostics, you need to use -g. holy backtrace batman!
[Bug other/59783] New: inline expansion stack when attribute error/warning triggered is displayed incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783
Bug ID: 59783
Summary: inline expansion stack when attribute error/warning
triggered is displayed incorrectly
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.santos at pobox dot com
In C C11, __attribute__((error())) is a wonderful replacement for
_Static_assert() (e.g.,
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler.h#n316).
However, when used in nested __always_inline functions where parameters to the
function are treated as compiletime constants and tested via such a mechanism,
the compiler doesn't tell us the correct root cause of the problem.
static void inline __attribute__((always_inline)) validate_pair(int x, int y) {
extern void diedie() __attribute__((error(x + y = too many)));
if (x + y 32)
diedie();
}
static void inline __attribute__((always_inline)) a1(int x, int y) {
validate_pair(x, y);
/* do some stuff */
}
static void inline __attribute__((always_inline)) a2(int x, int y) {
validate_pair(x, y);
/* do some other stuff */
}
static void inline __attribute__((always_inline)) b(int x, int y) {
if (x 1)
a1(x, y);
else
a2(x, y);
}
int main(int argc, char *argv[]) {
b(4, 12);
b(5, 13);
b(6, 13);
b(28, 14);
b(27, 14);
b(2, 15);
return 0;
}
When built with -O1 or greater, it yields this output:
In function ‘validate_pair’,
inlined from ‘main’ at asdf.c:15:18:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
^
In function ‘validate_pair’,
inlined from ‘main’ at asdf.c:10:18:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
^
It is correct that these two errors were inlined from the function main, but
the line number given is the function that actually calls validate_pair(),
although the actual inline instantiation stack for the first error was main()
- b() - a1() - validate_pair() and for the second error main() - b() -
a1() - validate_pair(). The work-around is essentially to use a preprocessor
macro, although a lot of simplicity, type-safety, etc. are then lost.
Since we are working with compile-time constant values, what would be nice
(similar to what is requested for bug #41373) is to display the entire inline
function instantiation/expansion stack, e.g.:
In function ‘validate_pair’,
inlined from ‘a2’ at asdf.c:15:18:
inlined from ‘b’ at asdf.c:23:25:
inlined from ‘main’ at asdf.c:30:15:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
This way, we can trace it to the exact function call (or inline function
expansion) that caused the problem. Welcome to the new age of C
metaprogramming! (and thank you for helping to make it possible) This is an age
of compile-time data (if not types, like C++ metaprogramming). So if you
*really* wanted to be helpful, you could do something like this:
In function ‘validate_pair’,
inlined from ‘a2’ [with x=28, y=14] at asdf.c:15:18:
inlined from ‘b’ [with x=28, y=14] at asdf.c:23:25:
inlined from ‘main’ [with x=28, y=14] at asdf.c:30:15:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
diedie();
Now I realize that actually involves a lot as many data types can be treated as
compiletime constants, even structs and pointers to structs and functions, but
I didn't think it could hurt to throw it out there. Essentially, displaying
the constant parameters of an inlined function call like you do the template
parameters in a C++ templatized function or type.
See also: bug #41373
[Bug c++/54948] template unnecessarily displayed as A template-parameter-1-1 not AT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-20
12:03:29 UTC ---
There are several bugs in this case. The first one is that we consider that
the type of:
templatetypename struct A
is struct A template-parameter-1-1 . It would be nicer to print something
like struct Atypename or struct A. Clang never needs to print made up
names.
The second bug is that I think we record T when parsing, but later we drop it.
I wasn't able to find when we drop it. There is a lot going on between the
moment we parse T and the moment we parse {, so it is rather difficult to
figure out. Stepping in the parser is rather frustrating.
I am afraid that the only person that may know what is going or where to look
is Jason. There is lookup_template_class, but by the time we call it, we
already dropped T (or so it seems to me, maybe it is recorded somewhere else).
[Bug c++/54948] template unnecessarily displayed as A template-parameter-1-1 not AT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-20 12:06:10 UTC --- BTW, the parser may benefit by marking some functions with skip to help debugging. All the cp_lexer_peek_* are useless to step into.
[Bug c++/54948] template unnecessarily displayed as A template-parameter-1-1 not AT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-20 12:50:26 UTC --- Possibly related PR57014.
[Bug c++/54948] template unnecessarily displayed as A template-parameter-1-1 not AT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-19 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 16:39:45 UTC --- I think there are other bugs about printing template-parameter-1-1. I don't see why the pretty-printer may ever need to print such a thing.
[Bug c++/54948] New: template unnecessarily displayed as A template-parameter-1-1 not AT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948
Bug #: 54948
Summary: template unnecessarily displayed as A
template-parameter-1-1 not AT
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
templatetypename struct A;
templatetypename T struct A { A(Y); };
Aint a;
This invalid code produces:
tp.cc: In instantiation of 'struct Aint':
tp.cc:5:8: required from here
tp.cc:3:36: error: 'A template-parameter-1-1 ::Y' has incomplete type
templatetypename T struct A { A(Y); };
^
tp.cc:3:29: error: declaration of 'struct Aint'
templatetypename T struct A { A(Y); };
^
This is correct, but A template-parameter-1-1 ::Y is rather ugly.
At the point of the error the parameter has a name, so AT::Y could be shown
instead.
[Bug middle-end/51696] [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 14:32:59 UTC --- Author: aldyh Date: Wed Jan 4 14:32:54 2012 New Revision: 182876 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182876 Log: PR middle-end/51696 * trans-mem.c (diagnose_tm_1): Display indirect calls with no name correctly. Added: trunk/gcc/testsuite/gcc.dg/tm/pr51696.c Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/51696] [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-04 14:34:39 UTC --- fixed
[Bug middle-end/51696] [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-03 17:20:43 UTC --- Proposed, http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00130.html
[Bug middle-end/51696] [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||diagnostic, trans-mem Last reconfirmed||2011-12-30 Component|c |middle-end Ever Confirmed|0 |1 Severity|enhancement |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-30 23:42:50 UTC --- Confirmed.
[Bug c/51696] New: [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Bug #: 51696 Summary: [trans-mem] unsafe indirect function call in struct not properly displayed Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 26196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26196 Attached testcase With an unsafe indirect function call, the error message is not clear. I don't know if it can display the declaration. In the worst case, unsafe indirect function call within ‘transaction_safe’ function should be ok. $ ./gcc/xgcc -B./gcc/ -fgnu-tm -O0 testcase.i testcase.i: In function ‘func’: testcase.i:7:21: error: unsafe function call ‘Uf3c0’ within ‘transaction_safe’ function testcase.i:8:12: error: unsafe function call ‘compare.1’ within ‘transaction_safe’ function Patrick Marlier.
[Bug c++/47747] [trans-mem] unsafe virtual function not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747 torvald at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||torvald at gcc dot gnu.org Resolution||FIXED --- Comment #1 from torvald at gcc dot gnu.org 2011-11-21 22:31:14 UTC --- This got fixed in r181602 on trunk.
[Bug c++/47747] [trans-mem] unsafe virtual function not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.07 16:19:13 Ever Confirmed|0 |1 Severity|minor |enhancement
[Bug c++/47747] [trans-mem] unsafe virtual function not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug c++/47747] New: [trans-mem] unsafe virtual function not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747 Summary: [trans-mem] unsafe virtual function not properly displayed Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23348 testcase that shows the error If a virtual function is not annotated as transaction safe and called in a transaction safe function, gcc raises an unsafe function error but it doesn't print correctly the function name. $ g++ -fgnu-tm -S -O0 unsafe_virtual.i unsafe_virtual.i: In constructor ‘Building::Building(InputStream*)’: unsafe_virtual.i:17:30: error: unsafe function call ‘#‘obj_type_ref’ not supported by dump_decl#declaration error’ within ‘transaction_safe’ function Attached a testcase. Patrick Marlier.
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-04-04 18:12 --- The session from the report now looks like: $ gfortran-svn -g pr24790.f dan...@silence ~/pr $ gdb -q a.out (gdb) break sub_ Breakpoint 1 at 0x804855c: file pr24790.f, line 5. (gdb) break sqr_ Breakpoint 2 at 0x80485eb: file pr24790.f, line 13. (gdb) run Starting program: /home/daniel/pr/a.out Breakpoint 1, sub (a=(), n=10) at pr24790.f:5 5 subroutine sub(a,n) (gdb) p a $1 = () (gdb) p n $2 = 10 (gdb) cont Continuing. Breakpoint 2, sqr (m=1) at pr24790.f:14 14sqr = m * m (gdb) p m $3 = 1 Closing as fixed. Thanks, Jakub! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |RESOLVED Known to fail||4.3.3 Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #7 from jakub at gcc dot gnu dot org 2008-08-29 18:48 --- Subject: Bug 24790 Author: jakub Date: Fri Aug 29 18:47:19 2008 New Revision: 139777 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139777 Log: PR fortran/24790 * trans-decl.c (create_function_arglist): Set DECL_BY_REFERENCE on PARM_DECLs with pointer or reference type. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
Re: gcc bug WRT warning that should not be displayed
Mo DeJong wrote: long val2 = 1; /* incorrect warn when val2 is a long */ int c2 = ( ((long long) val2) ((long long)(-2147483647L - 1)) ); The result of the compare will always be false, so the warning is correct. The long variable val2 can not hold a value smaller than LONG_MIN. Adding casts to long long does not change this fact. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
gcc bug WRT warning that should not be displayed
Hello
Gcc 3.4.2 on WinXP seems to generate a warning that it should not.
$ gcc -v
Reading specs from C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
The following C code shows the problem.
int foo() {
long long val1 = 1; /* No warn when val1 is a long long */
int c1 = (
((long long) val1)
((long long)(-2147483647L - 1))
);
long val2 = 1; /* incorrect warn when val2 is a long */
int c2 = (
((long long) val2)
((long long)(-2147483647L - 1))
);
return (c1 || c2);
}
$ gcc -c test.c
test.c: In function `foo':
test.c:11: warning: comparison is always false due to limited range of
data type
Both of the tests in the code above should compile without a warning,
but the second one does not.
thanks much
Mo DeJong
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #6 from burnus at net-b dot de 2006-10-22 21:03 --- See http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01086.html for a preliminary patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24527] derived types not displayed correctly with gdb
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-14 14:47 --- The patch in http://sourceware.org/ml/gdb-patches/2005-11/msg00217.html implements this quite nicely AFAICT. I'll try and take care of the rest. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-29 17:58:09 |2006-10-14 14:47:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug fortran/24527] derived types not displayed correctly with gdb
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-14 15:15 --- This works with the patch I mentioned in comment #3. That patch is in the GDB source tree since 2006-02-24, so this is fixed in GDB 6.5. On the GCC side we seem to do the right thing for scalar components. For array components obviously we don't but there is a separate bug about that. So I'm calling this FIXED. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-17 16:48 --- I don't have time for this bug at least right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-06 02:12 --- Some of it can be fixed by using: /* In a RESULT_DECL or PARM_DECL, means that it is passed by invisible reference (and the TREE_TYPE is a pointer to the true type). */ #define DECL_BY_REFERENCE(NODE) (DECL_COMMON_CHECK (NODE)-common.private_flag) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #2 from woodzltc at sources dot redhat dot com 2005-11-15 02:26 --- Hi Andrew, (In reply to comment #1) Confirmed, DECL_ARG_TYPE should be the reference type and the DECL_TYPE should be the normal type. This might also fix the implicate bug too (I forgot the number). Do you means that you already had a fix for this? If so, would you please point me to a link of that patch? I am very keen to see how this is fixed. I believe that I can learn something from your patch. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
Re: [Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #2 from woodzltc at sources dot redhat dot com 2005-11-15 02:26 --- Hi Andrew, (In reply to comment #1) Confirmed, DECL_ARG_TYPE should be the reference type and the DECL_TYPE should be the normal type. This might also fix the implicate bug too (I forgot the number). Do you means that you already had a fix for this? If so, would you please point me to a link of that patch? I am very keen to see how this is fixed. I believe that I can learn something from your patch. Thanks. No, just an idea on how to fix it and how the C++ represents some of its arguments which are passed via a reference. -- Pinski
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-15 03:17 --- Subject: Re: arguments are displayed as reference or pointer to normal type in GDB --- Comment #2 from woodzltc at sources dot redhat dot com 2005-11-15 02:26 --- Hi Andrew, (In reply to comment #1) Confirmed, DECL_ARG_TYPE should be the reference type and the DECL_TYPE should be the normal type. This might also fix the implicate bug too (I forgot the number). Do you means that you already had a fix for this? If so, would you please point me to a link of that patch? I am very keen to see how this is fixed. I believe that I can learn something from your patch. Thanks. No, just an idea on how to fix it and how the C++ represents some of its arguments which are passed via a reference. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24790] New: arguments are displayed as reference or pointer to normal type in GDB
Here is a testcase: fmain.f: = dimension a(10) call sub(a,10) fsub.f: = subroutine sub(a,n) dimension a(n) do i = 1, n a(i) = sqr(i) end do return end subroutine function sqr(m) sqr = m * m end function build a binary: # gfortran -g -o fbase fmain.f fsub.f # gdb -q ./fbase Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) b sub_ Breakpoint 1 at 0x804876b: file fsub.f, line 21. (gdb) b sqr_ Breakpoint 2 at 0x80487c1: file fsub.f, line 30. (gdb) r Starting program: /root/DE/gdb-6.4/src/gdb/testsuite/gdb.fortran/fbase Test begin. Breakpoint 1, sub_ (a=0xbff5cf30, [EMAIL PROTECTED]) at fsub.f:21 21 do i = 1, n Current language: auto; currently fortran (gdb) p a $1 = (PTR TO - ( real*4 (0:-1))) 0xbff5cf30 (gdb) p n $2 = (REF TO - ( int4 )) @0x8048918: 10 (gdb) c Continuing. Breakpoint 2, sqr_ ([EMAIL PROTECTED]) at fsub.f:30 30tmp1 = m (gdb) p m $3 = (REF TO - ( int4 )) @0xbff5cf00: 1 (gdb) In the above debugging session, argument 'a' of sub is displayed as pointer of the normal type, 'n' of sub and 'm' of sqr are displayed as reference to normal type. -- Summary: arguments are displayed as reference or pointer to normal type in GDB Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: woodzltc at sources dot redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 15:22 --- Confirmed, DECL_ARG_TYPE should be the reference type and the DECL_TYPE should be the normal type. This might also fix the implicate bug too (I forgot the number). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 15:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24527] derived types not displayed correctly with gdb
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:24 --- Confirmed. This is a gdb bug as if I do: set lang c it works. Oh, I think there is a dup around somewhere too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-27 23:24:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug fortran/24527] derived types not displayed correctly with gdb
--- Comment #2 from woodzltc at sources dot redhat dot com 2005-10-28 04:39 --- Yes. I agree that it is more like a gdb bug. But I would rather say that it is an enhancement request for gdb, because GDB never says that it supports complete Fortran-95 syntax. The support for Fortrn 77 is also not deemed as complete. I coded a patch in gdb for that. The link is http://sourceware.org/ml/gdb-patches/2005-10/msg00208.html -- woodzltc at sources dot redhat dot com changed: What|Removed |Added CC||woodzltc at sources dot ||redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug fortran/24527] New: derived types not displayed correctly
This may be a gdb bug, but anyway... cat type.f90 program main type foo real :: a integer :: b end type foo type(foo) :: q q = foo(3.14, 42) print *,q end program main $ gfortran -g type.f90 $ gdb ./a.out GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) b type.f90:7 Breakpoint 1 at 0x8048624: file type.f90, line 7. (gdb) r Starting program: /home/ig25/Krempel/Gdb/a.out Breakpoint 1, MAIN__ () at type.f90:7 7 q = foo(3.14, 42) Current language: auto; currently fortran (gdb) p q $1 = Invalid F77 type code 3 in symbol table. (gdb) q The program is running. Exit anyway? (y or n) y -- Summary: derived types not displayed correctly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug fortran/23176] New: Warning messages incorrectly being displayed
I think that the warning messages should not be displayed - [dranta:~/tests/gfortran-D] dir% gfortran -g -c -fdefault-real-8 -fdefault-integer-8 -fdefault-double-8 arg.F cc1: warning: command line option -fdefault-real-8 is valid for F95 but not for C cc1: warning: command line option -fdefault-integer-8 is valid for F95 but not for C cc1: warning: command line option -fdefault-double-8 is valid for F95 but not for C [dranta:~/tests/gfortran-D] dir% cat arg.F program main stop end -- Summary: Warning messages incorrectly being displayed Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23176
[Bug fortran/23176] Warning messages incorrectly being displayed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-01 13:15 --- *** This bug has been marked as a duplicate of 18452 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23176
