[Bug target/54626] New: Unexpected consequences of __attribute__((optimize("-fno-PIC")))

[jepler at unpythonic dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54626

 Bug #: 54626
   Summary: Unexpected consequences of
__attribute__((optimize("-fno-PIC")))
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jep...@unpythonic.net


(I doubt I've selected the right component; please correct)

I ran across bug 54232 and it occurred to me to wonder whether it was possible
to manually mark a single function that uses no global data (and thus does not
need to use ebx as the GOT register) as "no PIC".

This has the unexpected side-effect of making the entire translation unit "no
PIC".

Source code:
extern int o();

int f() __attribute__((optimize("-fno-PIC")));
int f() { return o(); }
 g() { return o(); }

Compiler commandline:
gcc -m32 -fPIC -c ff.c

Expected behavior: when examined with 'objdump -d ff.o', function f contains no
call to get_pc_thunk.bx while g does.  Alternately, the __attribute__
declaration results in an error if this is totally nonsensical.

Actual behavior: both f and g are compiled without call to get_pc_thunk.bx

Tested on svn trunk r19144:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/jepler/gcc-dev/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/jepler/gcc-dev
--with-gmp=/usr/local/jepler/gcc-dev --with-mpc=/usr/local/jepler/gcc-dev
--with-mpfr=/usr/local/jepler/gcc-dev
Thread model: posix
gcc version 4.8.0 20120918 (experimental) (GCC)

[Bug c/42098] New: gcc does not honor alignment specification, gives different alignment than g++

[jepler at unpythonic dot net]

Given the declaration: typedef volatile double D __attribute__((aligned(16)));
gcc and g++ give different alignments (and thus differing offsets and sizes)
for structures that contain D.  Removal of the volatile qualifier changes the
alignment behavior.

$ g++ -m32 vs.c && ./a.out
$ gcc -m32 -Dvolatile= vs.c && ./a.out
$ gcc -m32 vs.c && ./a.out
a.out: vs.c:8: main: Assertion `__alignof__(S) == 8' failed.
Aborted

$ gcc -v 2>&1 | tail -1
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)


-- 
   Summary: gcc does not honor alignment specification, gives
different alignment than g++
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: jepler at unpythonic dot net
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098

[Bug c/42098] gcc does not honor alignment specification, gives different alignment than g++

[jepler at unpythonic dot net]

--- Comment #1 from jepler at unpythonic dot net  2009-11-18 20:23 ---
Created an attachment (id=19036)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19036&action=view)
test program to demonstrate the problem


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098

[Bug c/42098] gcc does not honor alignment specification, gives different alignment than g++

[jepler at unpythonic dot net]

--- Comment #2 from jepler at unpythonic dot net  2009-11-20 14:45 ---
(In reply to comment #0)
> Given the declaration: typedef volatile double D __attribute__((aligned(16)));
That should have been aligned(8)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098

[Bug c/110703] New: Incorrect "-Wfloat-conversion" diagnostic with _Generic

[jepler at unpythonic dot net via Gcc-bugs]

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

Bug ID: 110703
   Summary: Incorrect "-Wfloat-conversion" diagnostic with
_Generic
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jepler at unpythonic dot net
  Target Milestone: ---

When compiled with `gcc -Wfloat-conversion -c boo.c` the following code results
in a `-Wfloat-conversion` diagnostic across a range of gcc versions including
gcc version 12.2.0 (Debian 12.2.0-14) and godbolt "trunk" as of today
(https://godbolt.org/z/3K7sTTv1x)

```
#include 

#define tgsin(x) \
_Generic((x), \
double: sin((x)), \
float: sinf((x)) \
)

int f(double d) {
return tgsin(d) > 0;
}
```

The result is
```
$ gcc -Wfloat-conversion -c boo.c
boo.c: In function ‘f’:
boo.c:10:18: warning: conversion from ‘double’ to ‘float’ may change value
[-Wfloat-conversion]
   10 | return tgsin(d) > 0;
  |  ^
boo.c:6:25: note: in definition of macro ‘tgsin’
6 | float: sinf(x) \
  | ^
```

As far as I can tell, the diagnostic is spurious, because it applies to the
"float" case of _Generic, which is not the one that is actually chosen. That
is, inspecting the resulting object file `boo.o` there is a call to sin but not
to sinf.

This is prompted by https://github.com/v923z/micropython-ulab/pull/636 and
earlier
https://github.com/micropython/micropython/commit/f31f9a8b70db03cbcbcf39b493f959d0e284962a
-- it at first appeared to be related to -Os size optimization, but that's just
related to how glibc chooses to implement fpclassify, whether via _Generic or
not.

This may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193