[Bug c++/68052] No printf format warnings in C++ code for macro in system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68052
Trent Piepho changed:
What|Removed |Added
CC||xyzzy at speakeasy dot org
--- Comment #6 from Trent Piepho ---
It appears the same underlying problem can disable printf warnings via another
pattern:
$ mkdir -p syshdr_dir
$ cat < syshdr_dir/myprintf.h
#define SD_ERR "<3>"
EOF
$ cat < test-format-printf.c
#include
int main(void) {
printf(SD_ERR "%s", 3);
return 0;
}
EOF
The printf format error in the pasted string "<3>%s" appears to be attributed
to the macro SD_ERR, as it forms the start of the pasted string. Since that
macro is from a system header, the printf format error is attributed to the
system header, and no diagnostic is generated. Changing the call to printf(""
SD_ERR "%s", 3) will attributed the printf format error to the line containing
the printf() call and allow a diagnostic to be generated.
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #38 from xyzzy at speakeasy dot org 2007-02-27 19:36 --- (In reply to comment #37) now if there is a unwritten rule that m operands and variations of them cannot be copied anywhere, then it would be very desireable to have a asm constraint like m without this restriction this would resolve this and several other bugs also it would be very nice if such a dont copy restriction on m if it does exist could be documented Copying m operands onto the stack might not be such a great thing to wish for. Imagine if you used asm(movaps %xmm0, %0: =m(x[i])); If x[i] is only 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps wouldn't also write to x[i+1] to x[i+3] as intended. I know there is a plenty of asm code in ffmpeg that overwrites or overreads memory operands and will fail if gcc tried to move them onto the stack. There is also alignment. movaps requires an aligned address, and maybe you have chosen x and i in such a way that it will be aligned. But when gcc copies the value onto the stack, how is it supposed to know what alignment it needs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #36 from xyzzy at speakeasy dot org 2006-11-08 20:03 --- (In reply to comment #21) asm volatile( : =m (*(unsigned int*)(src + 0*stride)), =m (*(unsigned int*)(src + 1*stride)), =m (*(unsigned int*)(src + 2*stride)), =m (*(unsigned int*)(src + 3*stride)), =m (*(unsigned int*)(src + 4*stride)), =m (*(unsigned int*)(src + 5*stride)), =m (*(unsigned int*)(src + 6*stride)), =m (*(unsigned int*)(src + 7*stride)) ); (In reply to comment #26) it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail The example Martin gave has *8* operands. You can try every possible direct mapping of those 8 addresses to just 7 registers, but they will obviously all fail. Except with ia32 addressing modes it _can_ be done, and with only 4 registers. reg1 = src, reg2 = stride, reg3 = src+stride*3, reg4 = src+stride*6 Then the 8 memory operands are: (reg1), (reg1,reg2,1), (reg1,reg2,2), (reg3), (reg1,reg2,4), (reg3,reg2,2), (reg4), (reg3,reg2,4) When one considers all the addressing modes, there are not just 7 possible registers, but (I think) 261 possible addresses. There are not just 5040 possibilities as Michael said, but over 76 x 10^15 possible ways of assigning these addresses to 7 operands! Then each register can be loaded not just with an address but with some sub-expression too, like how I loaded reg2 with stride. Even for ia32, which makes up for its limited number of registers with complex addressing modes, finding a register allocation that satisfies an asm statement is not something that can always be done in reasonable time. If the number of operands = number of available registers it should be able to (but gcc doesn't) always find an allocation (_an_ allocation, not the best allocation). -- xyzzy at speakeasy dot org changed: What|Removed |Added CC||xyzzy at speakeasy dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
