[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name

[fuchedzhy at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176

--- Comment #10 from Gregory Fuchedzhy  ---
(In reply to f.hollerer from comment #8)
> To my understanding assert() uses __FILE__ and __LINE__. I would like to
> have a command line option which let __FILE__ expand to the last path
> component (the filename) instead of an invocation dependent full path of
> that file.

If __FILE_NAME__ is implemented would adding -D__FILE__=__FILE_NAME__ solve
your particular usecase?

[Bug tree-optimization/91812] [7 Regression] GCC ignores volatile modifier

[fuchedzhy at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91812

--- Comment #13 from Gregory Fuchedzhy  ---
(In reply to Richard Biener from comment #12)
> Fixed.
Thanks a lot, Richard!

[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name

[fuchedzhy at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176

--- Comment #5 from Gregory Fuchedzhy  ---
(In reply to Eric Gallager from comment #3)
> *** Bug 91998 has been marked as a duplicate of this bug. ***

Not exactly a duplicate, but related.
Clang implemented an additional __FILE_NAME__ macro.

See:
https://reviews.llvm.org/D61756
https://reviews.llvm.org/D17741

[Bug c/91998] New: Add a __FILE_NAME__ macro

[fuchedzhy at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91998

Bug ID: 91998
   Summary: Add a __FILE_NAME__ macro
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fuchedzhy at google dot com
  Target Milestone: ---

It would be handy to have macro similar to __FILE__ but expanding to source
*base* file name only.
It might be useful for application logs and asserts, especially on embedded
systems, where we don't want to do string searches in runtime and don't want to
store full paths (which might be very long) in the binary.

Clang added such macro recently, see:
https://reviews.llvm.org/D61756
https://reviews.llvm.org/D17741

[Bug c/91812] GCC ignores volatile modifier

[fuchedzhy at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91812

--- Comment #2 from Gregory Fuchedzhy  ---
(In reply to Eric Gallager from comment #1)
> If you declare ptr like this instead, the assembly comes out looking
> different:
> volatile unsigned int *volatile ptr;

Even seemingly unrelated code changes can hide this behavior. For example,
commenting out one of switch cases generates correct assembly.

[Bug c/91812] New: GCC ignores volatile modifier

[fuchedzhy at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91812

Bug ID: 91812
   Summary: GCC ignores volatile modifier
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fuchedzhy at google dot com
  Target Milestone: ---

GCC appears to ignore volatile modifier sometimes. C is probably wrong
component for the bug, but I'm not sure where else to put it.

$ arm-linux-gnueabi-gcc-8 -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/8/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv5te
--with-float=soft --disable-werror --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi
--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 

This is a minimal example I could come up with:

volatile unsigned register1;
volatile unsigned register2;

void busy_wait_for_register(int x) {
  volatile unsigned* ptr;
  switch(x) {
case 0x:
  ptr = 
  break;

case 0x:
  ptr = 
  break;

default:
  return;
  }
  while (*ptr) {}
}

If compiled with following command:
$ arm-linux-gnueabi-gcc-8 -mcpu=cortex-m7 -Os -c main.c

Produces following binary:
$ arm-linux-gnueabi-objdump -d main.o

main.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   f241 1211   movwr2, #4369   ; 0x
   4:   4b08ldr r3, [pc, #32]   ; (28
)
   6:   4290cmp r0, r2
   8:   447badd r3, pc
   a:   d004beq.n   16 
   c:   f242    movwr2, #8738   ; 0x
  10:   4290cmp r0, r2
  12:   d006beq.n   22 
  14:   4770bx  lr
  16:   4a05ldr r2, [pc, #20]   ; (2c
)
  18:   589bldr r3, [r3, r2]
  1a:   681bldr r3, [r3, #0]
  1c:   2b00cmp r3, #0
  1e:   d1fdbne.n   1c 
  20:   4770bx  lr
  22:   4a03ldr r2, [pc, #12]   ; (30
)
  24:   e7f8b.n 18 
  26:   bf00nop
  28:   001c.word   0x001c
...

Note that generated while loop instructions:
  1c:   2b00cmp r3, #0
  1e:   d1fdbne.n   1c 
never reload the register making this effectively an infinite loop.
I believe volatile keyword should have prevented that.