[Bug c++/106743] New: Illegal assembly code with -march=skylake

2022-08-25 Thread stayprivate at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106743

Bug ID: 106743
   Summary: Illegal assembly code with -march=skylake
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stayprivate at gmail dot com
  Target Milestone: ---

#include 
#include 

#define swapw(__val)   
   \
({ 
 \
uint16_t __tmp = __val;
   \
__asm__("xchgb %b0, %h0" : "=q"(__tmp) : "0"(__tmp));  
  \
__tmp; 
   \
})


int main()
{
int value = rand();
int a = swapw(value);
std::cout << std::hex << "First value is " << value << " " << a << '\n';
}

Compile with gcc (gcc 12 on Ubuntu ), and also with trunk. As shown on
https://godbolt.org/z/oGn9WK6GE the assembler will generate the following
error:
: register type mismatch for `xchg'

This is only when using -march=skylake or above and using -O1 or above.

The code works in gcc-9/10/11.

[Bug lto/95190] Documentation for -Wstringop-overflow

2020-05-19 Thread stayprivate at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190

--- Comment #5 from Mario Charest  ---
On Tue, May 19, 2020 at 2:35 AM rguenth at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
>
> --- Comment #2 from Richard Biener  ---
> This is new behavior for warnings in GCC 10 and now how all other
> optimization
> options behave - the option state is fixed per function at compile-time and
> carried over to link-time.
>
> Indeed warning options are not mentioned in the docs, let me fix that.
>

Great! Thanks, may I suggest adding it the changes and portings web page.
This new behavior may required tweaking of build files.


> --
> You are receiving this mail because:
> You reported the bug.

[Bug lto/95190] Documentation for -Wstringop-overflow

2020-05-19 Thread stayprivate at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190

--- Comment #4 from Mario Charest  ---
On Mon, May 18, 2020 at 1:09 PM msebor at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
>
> Martin Sebor  changed:
>
>What|Removed |Added
>
> 
>Last reconfirmed||2020-05-18
>  Status|UNCONFIRMED |WAITING
>   Component|c++ |lto
>  Ever confirmed|0   |1
>  CC||marxin at gcc dot gnu.org
> ,
>||msebor at gcc dot gnu.org
>Keywords||documentation
>
> --- Comment #1 from Martin Sebor  ---
> Which part do you find surprising?  That the warning is issued during the
> LTO
> stage at all or that -Wno-stringop-overflow can be used during the LTO
> stage to
> suppress it?
>

Mostly the LTO stage. I got bitten because I assumed warning came from the
compiler. If the LTO stage would have handle #pragma diagnostic i would
have never noticed where it came from.


>
> During LTO the same compiler options should be implicitly enabled as during
> ordinary compilation, including warnings.  (This presents some challenges
> when
> the compilation was done with different options for different files.)
>

Most project with cmake using lto will required tweaking.  Typically
warning options are specified with add_compiler_options(). Now every
warning flags must also be passed to the linker, impossible to know which
flag has an effect on the LTO stage or not.


> It also means that all the same warnings should be expected to be
> implicitly
> enabled during LTO that were explicitly enabled during the compilation
> stage.
> I'd expect to see only "late" warnings during LTO, i.e., those that depend
> on
> optimization.  (I understand this doesn't work completely consistently yet
> but
> I believe that's the goal.)
>
> So this effect isn't specific to -Wstringop-overflow, but perhaps it would
> be
> worth mentioning under -flto?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/95190] New: Documentation for -Wstringop-overflow

2020-05-18 Thread stayprivate at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190

Bug ID: 95190
   Summary: Documentation for -Wstringop-overflow
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stayprivate at gmail dot com
  Target Milestone: ---

I'm compiling code with 10.1 for the first time. I'm getting a warning:

"writing 1 bytes into a region of size 0 -Wstringop-overflow=". Yet
-Wno-stringop-overflow is passed to the compiler.  I tried disabling the
warning with #pragma diagnostic, no luck there.

Then I realized the error came from the link stage. Surely related to lto. I
modified my cmake files to add the -Wno-stringop-overflow to the link command
line and the warning disappear.

I'm surprise by this behavior. I looked through the documentation and could not
find anything that mentionned this. Is this something that is worth improving
in  the documentation or do I just need to get smarter ;-)